RPi Cam Web Interface

[spex357]

I had a faultest install, rebooted, and opened a webpage
[url=https://flic.kr/p/F69sJ4][img]http ... .jpg[/img]
I shutdown, rechecked my connections, raspi-config, re-enabled the Camera, rebooted and RPi_Cam was running 100%
It's now been down the garden testing the Pi3's wireless range, it would have gone further providing it wasn't on the ground, but my Iphone which I was using to focus the manual lens lost connection to the Network. The shot was taken with 800mm of Nikon glass, handheld. How many amps can I safely use into the Pi? my travel pack is only 5v 2amp, two servo's and numerous Ir leds, would probably be better on a seperate pack?
[url][url=https://flic.kr/p/Eh3EKq][/url

[wingers]

The difference was that raspimjpeg had an extra timeout built in so that if it didn't get a call back from the camera within 5 seconds then it would timeout. Previously it hung up altogether if callbacks stopped.

I don't know why your system is sensitive to that. What I have done is add a parameter to /etc/raspimjpeg (callback_timeout)
By default this is now 30 instead of the 5 that was hard coded. Also if set to 0 then no timeout is applied and behaviour should be the same before timeout logic was added.

Hi
Okay, I have had some time this weekend to play about with this and try and find why it is crashing

It is definitely not a hardware/connection issue as if I stop the schedule so I am just streaming the camera and not actually capturing any images it works perfectly fine for hours on end (even with latest raspimjpeg)

If I then turn on schedule so it is capturing on motion again then it crashes randomly with error I gave earlier and I have to do a stop and start command to get it running again

I have also noticed it only crashes when it is actually capturing images - i.e. when motion has been detected

Basically this camera is in a hedgehog box capturing them coming for food etc each night - so during day when nothing happening it runs fine - only ever crashes at night when it is capturing hedgehog feeding

So therefore I am assuming it must be down to the settings I am using for RPI_Cam_Web? basically all is set to default other than threshold and noise level for motion - and in the scheduler I have following:-

Motion start = tl 20 Motion stop = tl 0 Period Start = md 0;em auto;md 1

Daymode is set to All Day

Please can you suggest what might cause the issue I am having and suggest how I can fix it - or help you diagnose the cause so it can be fixed in future updates?

Hi

Update on my crashing problems - since posting the message above 7 days ago my camera has been running perfectly fine just streaming the video without a single crash, error or reboot needed - so think this proves quite well that it is not a power or cable issue of any time

The problems only start when I have the schedule run as per post above so it does motion detected time lapses - so it must be a software issue or a settings issue

Would really appreciate a response and ideas to get this sorted??

[miraaz]

Although I changed the media location for the recordings in /etc/raspimjpeg (image_path, lapse_path, video_path and media_path) to a mounted USB memory stick, images are still put in the standard directory and preview is still pointing to the original directory too... How can I change this?

anybody?

New installer update makes what you want. Coming soon

[btidey]

Hi

Update on my crashing problems - since posting the message above 7 days ago my camera has been running perfectly fine just streaming the video without a single crash, error or reboot needed - so think this proves quite well that it is not a power or cable issue of any time

The problems only start when I have the schedule run as per post above so it does motion detected time lapses - so it must be a software issue or a settings issue

Would really appreciate a response and ideas to get this sorted??

Have you tried adjusting the capture timeout in the latest version. In particular setting the timeout to 0 to disable it? The reason for checking this is because you said the previous software did not suffer the problem reported and adding the timeout was the only change.

What I have done is add a parameter to /etc/raspimjpeg (callback_timeout)
By default this is now 30 instead of the 5 that was hard coded. Also if set to 0 then no timeout is applied and behaviour should be the same before timeout logic was added.

Using motion detect to turn on / off time-lapse recordings is a bit unusual so it is possible that there is some issue with that and unconnected with the capture timeout. To be investigated. In the meantime have you considered using 1 fps video instead?

Edit: Checking back on your original posts I see you are using tl 20. That doesn't matter but the 20 is having no effect. tl 1 (or any non zero value) turns time lapse on, tl 0 turns it off. tv n is used to set the time lapse interval, e.g. tv 20 would set it to 2 seconds.

Checking the log file I see most of the images are 3 seconds apart (consistent with default interval). However, every now and again there is a much longer interval up to 8 seconds. This is very strange as the time lapse interval should be very consistent (to within 0.1 second). It suggests that something else is getting in and blocking the raspimjpeg process and that could be what is triggering your problem. Possibilities would be networking / wifi issues, slowness of storing of the image file data, or other software processes running.

[wingers]

Have you tried adjusting the capture timeout in the latest version. In particular setting the timeout to 0 to disable it? The reason for checking this is because you said the previous software did not suffer the problem reported and adding the timeout was the only change.

Thank you very much for your response - I will give all these points a try and let you know how I get on

As for adjusting the capture timeout - where do I change this? as couldn't see it anywhere in the interface unless I am missing something?

[btidey]

Have you tried adjusting the capture timeout in the latest version. In particular setting the timeout to 0 to disable it? The reason for checking this is because you said the previous software did not suffer the problem reported and adding the timeout was the only change.

Thank you very much for your response - I will give all these points a try and let you know how I get on

As for adjusting the capture timeout - where do I change this? as couldn't see it anywhere in the interface unless I am missing something?

There is no user interface to change the timeout. It is a config variable called callback_timeout.

You should find this in /etc/raspimjpeg

Code: Select all

callback_timeout 30

You can edit this with sudo nano /etc/raspimjpeg Change it to 0 to disable it and make it behave like before the change. You need to stop and start the camera software for the change to take effect.

[miraaz]

I have strange issue.

1.
"Camera Settings"
Motion detect mode : External

2.
"Edit motion settings"
Motion not running. Put in detection state
(ok that is normal)

3.
Ok i enable: "Motion detection start"

4.
"Edit motion settings"
Only 4 buttons and thats all! What is that? Where is bug?
Pressing "Show all" and "Show less" not helps also.

[btidey]

I have strange issue.

1.
"Camera Settings"
Motion detect mode : External

2.
"Edit motion settings"
Motion not running. Put in detection state
(ok that is normal)

3.
Ok i enable: "Motion detection start"

4.
"Edit motion settings"
Only 4 buttons and thats all! What is that? Where is bug?
Pressing "Show all" and "Show less" not helps also.

When Jessie was introduced the version of the motion program that got fetched changed. There were quite a lot of changes to the parameter names. The old motion.conf.1 file in the installer is not a good starting point for creating the right /etc/motion.conf file. I think the RPi_Cam_Web_Interface_Installer.sh method is still doing this so you end up with external motion not running properly and responding to its API to display variables.

The ./install.sh method takes a different approach. It does not use the motion.conf.1 file at all. Instead it starts directly from the 'correct' default /etc/motion.conf file installed when motion is first installed and then edits in place just the few config variables that need to be changed during an install. That way any future changes to the names in the motion.conf file are easier to handle.

If the original default motion.conf file has been overwritten then one must purge motion completely in order to get it to install a default again.

[miraaz]

Ok tnx. Now i know what needed todo. I try fix old installer also....

[quavoce]

Just a quick thought - should we be including "sudo rpi-update" as part of the installation process when dom recommends against it?

viewtopic.php?p=145974#p145974

rpi-update gets you the latest experimental firmware. It is usually fine, but occasionally may have regressions.
You should run rpi-update regularly if you want to help with testing, and are happy to encounter bugs and submit bug reports.
You might want want to run rpi-udpate if you are having a specific issue that a forum post, or commit messages on guithub suggests has been recently fixed.

The changes from rpi-updates will appear with an apt-get update eventually, if there are no reports of regressions from the rpi-update testers. Most users should just use this.

[miraaz]

Just a quick thought - should we be including "sudo rpi-update" as part of the installation process when dom recommends against it?

viewtopic.php?p=145974#p145974

rpi-update gets you the latest experimental firmware. It is usually fine, but occasionally may have regressions.
You should run rpi-update regularly if you want to help with testing, and are happy to encounter bugs and submit bug reports.
You might want want to run rpi-udpate if you are having a specific issue that a forum post, or commit messages on guithub suggests has been recently fixed.

The changes from rpi-updates will appear with an apt-get update eventually, if there are no reports of regressions from the rpi-update testers. Most users should just use this.

Quik answer is No! That is free world and every user know himself hi want or not want upgrade his operating system.

[btidey]

Just a quick thought - should we be including "sudo rpi-update" as part of the installation process when dom recommends against it?

The rpi-update was originally included in the wiki instructions as the MMAL software was being improved and it needed the update to benefit from some items. E.g. Annotation v3 was originally only available via rpi-update.

I am not currently aware of any features used not available on the standard distribution so there is no current need for an rpi-update. I have amended wiki wording on this.

[jarrah31]

Hi Bob,

What is the difference between "cam_pic_new.php" and "cam_pic.php" please?

I'm liaising with the developer of "IP Cam View Pro" because his latest version that uses "cam_pic_new.php" isn't quite working right, yet I notice that the code to embed a stream in your own webpage uses cam_pic.php instead.

Should the developer use cam_pic.php?

Thanks.

[btidey]

Hi Bob,

What is the difference between "cam_pic_new.php" and "cam_pic.php" please?

I'm liaising with the developer of "IP Cam View Pro" because his latest version that uses "cam_pic_new.php" isn't quite working right, yet I notice that the code to embed a stream in your own webpage uses cam_pic.php instead.

Should the developer use cam_pic.php?

Thanks.

cam_pic.php is the original preview fetch support. It is used when in default stream mode to fetch the next in a sequence of jpeg images to display as the preview. It is called for each new image.

cam_pic_new.php performs the same function but in mjpeg stream mode. It is called once at the start of showing the live data and then continuously feeds the image data down to the preview.

The software defaults to cam_pic.php but it is good to switch to mjpeg stream mode where possible as this is a bit smoother. The reason why there is a choice is that not all browser / OS combinations support the mjpeg mode.

[jarrah31]

Hi Bob,

What is the difference between "cam_pic_new.php" and "cam_pic.php" please?

I'm liaising with the developer of "IP Cam View Pro" because his latest version that uses "cam_pic_new.php" isn't quite working right, yet I notice that the code to embed a stream in your own webpage uses cam_pic.php instead.

Should the developer use cam_pic.php?

Thanks.

cam_pic.php is the original preview fetch support. It is used when in default stream mode to fetch the next in a sequence of jpeg images to display as the preview. It is called for each new image.

cam_pic_new.php performs the same function but in mjpeg stream mode. It is called once at the start of showing the live data and then continuously feeds the image data down to the preview.

The software defaults to cam_pic.php but it is good to switch to mjpeg stream mode where possible as this is a bit smoother. The reason why there is a choice is that not all browser / OS combinations support the mjpeg mode.

Thank you!

[errikos]

Hello!
Is there any easy way or ready image to install Rpi Cam Web Interface in debian Jessie for Rpi 3 ;

[btidey]

Hello!
Is there any easy way or ready image to install Rpi Cam Web Interface in debian Jessie for Rpi 3 ;

Do you mean raspbian (debian) Jessie, or some other debian version.

Assuming rasbian then it is a pretty easy 4 step process if you follow the wiki instructions
http://elinux.org/RPi-Cam-Web-Interface

When you run ./install.sh as step 4 then to start with just leave everything at default

[erwang01]

Hi,

I was wondering what the purpose for the www and www-src folder within RPi_Cam_Web_Interface is for. All of the server items are in /var/www right?

Thanks,
erwang01

[btidey]

Hi,

I was wondering what the purpose for the www and www-src folder within RPi_Cam_Web_Interface is for. All of the server items are in /var/www right?

Thanks,
erwang01

Yes. the ww-src folder is a historical curiosity used in the original development I believe but no longer used or relevant. I may remove it to avoid confusion.

[erwang01]

Hi,

I was wondering what the purpose for the www and www-src folder within RPi_Cam_Web_Interface is for. All of the server items are in /var/www right?

Thanks,
erwang01

Yes. the ww-src folder is a historical curiosity used in the original development I believe but no longer used or relevant. I may remove it to avoid confusion.

Thanks btidey,

How about the www folder?

[btidey]

How about the www folder?

The RPiCam folder downloaded during git is just used to install. It does not contain any operational items after an install has been done and can be deleted if required. It does help to leave it if you want to re-install to change settings or to do upgrades.

The www folder in RpiCam is copied to the web install folder during the install (e.g. /var/www).

The bin folder contains the main executable raspimjpeg which is copied to /opt/vc/bin

The etc folder contains various config files used during the install and edited / moved into their operational positions.

[359]

Having a frustrating time today, for some reason motion is fouled up. Has been fine for months, no issues.

Today, RPi Cam interface is working fine, if I use internal motion, all is well. Just external. I'd like to use motion for some quirks. Any ideas what to check? I click begin motion detection start and the display freezes, clock on cam output hangs and that's it, need to reboot. Have waited up to 5 mins. Have removed RPi cam with script ./remove.sh, deleted var/www/ then purge removed motion, cloned to RPi folder, new install and still same. On Wheezy. Considering chucking towel in, grabbing Jessie and trying that!

Any pointers welcomed, not sure what other details to give at this point

edit: If I visit http://localhost/cam_pic.php as suggested in troubleshooter section, I get the picture of when I pressed start motion, no updates to it if this helps

edit 2: if I do ps -e | grep motion, I get: 11610 ? 00:00:00 motion

Not sure what the ? in that means

edit 3 (gah!) ok, I copied the motion.conf.1 file from RPi cam clone folder to /etc/motion/, rebooted and now it works. Am I missing something here, does the installer not do this? Anyways, lesson learned, all ok now

edit 4: I don't know hehe, motion runs but no setting on the edit motion settings page. ??

[btidey]

Having a frustrating time today, for some reason motion is fouled up. Has been fine for months, no issues.

Today, RPi Cam interface is working fine, if I use internal motion, all is well. Just external. I'd like to use motion for some quirks. Any ideas what to check? I click begin motion detection start and the display freezes, clock on cam output hangs and that's it, need to reboot. Have waited up to 5 mins. Have removed RPi cam with script ./remove.sh, deleted var/www/ then purge removed motion, cloned to RPi folder, new install and still same. On Wheezy. Considering chucking towel in, grabbing Jessie and trying that!

Any pointers welcomed, not sure what other details to give at this point

edit: If I visit http://localhost/cam_pic.php as suggested in troubleshooter section, I get the picture of when I pressed start motion, no updates to it if this helps

edit 2: if I do ps -e | grep motion, I get: 11610 ? 00:00:00 motion

Not sure what the ? in that means

edit 3 (gah!) ok, I copied the motion.conf.1 file from RPi cam clone folder to /etc/motion/, rebooted and now it works. Am I missing something here, does the installer not do this? Anyways, lesson learned, all ok now

edit 4: I don't know hehe, motion runs but no setting on the edit motion settings page. ??

Sounds like something went wrong during install on motion.conf file. This changed quite a lot between wheezy and Jessie as motion changed a lot of the parameter names around. The install.sh gets around this by editing the default motion.conf in place instead of copying one from the installer. I normally install on Jessie now but last time I checked it worked OK on wheezy.

It does rely on starting from the normal default motion.conf. If this is mucked up by copying another one in then things may not work. For wheezy it is probably Ok to copy the installer one in AND then re-run the installer.

What extra bits of external motion do you use? One can replace most stuff with macros.

[359]

Just tried that, no luck again. It's all good, will have to get with the times tomorrow with Jessie.

Regarding motion, most useful feature I'd miss is the mask.pgm feature, have a road in shot and I blank that out easily. Not sure this can be done with internal motion?

Also on capture end, motion uploads to nas. Haven't looked at macros as this method works 100%

Thanks for the advice, reinstall time

[btidey]

Just tried that, no luck again. It's all good, will have to get with the times tomorrow with Jessie.

Regarding motion, most useful feature I'd miss is the mask.pgm feature, have a road in shot and I blank that out easily. Not sure this can be done with internal motion?

Also on capture end, motion uploads to nas. Haven't looked at macros as this method works 100%

Thanks for the advice, reinstall time

Yes. Internal motion supports mask image. I use that all the time. It needs to be the size of the vector size which is roughly 1/16. The value gets logged when camera starts or size is changed. e.g.
Set up internal detect width=82 height=61
end_box macro can be used to upload to nas. This will work for both motion and manually triggered captures.