RPi Cam Web Interface

[GammaScorpii]

Having problems with the latest update (6.2.23).

The problem is the camera stops recording and resets itself (as if I clicked Turn off camera off and on). At first it was seemingly random, but I was reliably causing this to happen at one stage by clicking into a different page (such as Download Video and Images), and then clicking back to go back to the main page while recording video simultaneously.

Anyone else having these problems or have any idea what it could be? E.g. Low voltage, camera cable coming loose? Could lots of wifi interference cause it?

This has only started happening since I updated to 6.2.23 from 6.2.19.

[btidey]

Having problems with the latest update (6.2.23).

The problem is the camera stops recording and resets itself (as if I clicked Turn off camera off and on). At first it was seemingly random, but I was reliably causing this to happen at one stage by clicking into a different page (such as Download Video and Images), and then clicking back to go back to the main page while recording video simultaneously.

Anyone else having these problems or have any idea what it could be? E.g. Low voltage, camera cable coming loose? Could lots of wifi interference cause it?

This has only started happening since I updated to 6.2.23 from 6.2.19.

I am not aware of any change that could have triggered this and I don't see a problem with all my cameras running latest version.

It is more likely to be one of the issues you mention but if you want to check out whether the change could be the cause on your system then I attach a zip containing just the executable

To replace then stop the camera running (./stop.sh in RPi_Cam folder) then replace the raspimjpeg file in /opt/vc/bin with the one in the zip. E.g move the replacement raspimjpeg to your home folder. Then

Code: Select all

sudo mv /opt/vc/bin/raspimjpeg ~/raspimjpeg.new
sudo mv ~/raspimjpeg /opt/vc/bin/raspimjpeg

The restart the camera ./start.sh in RPi_Cam folder.

You can revert it back to the current version by the same procedure but use the raspimjpeg.new

[Pangu]

The error during the update was caused by git thinking that a local file has been changed outside of its control and it won't do the merge because of that. Normally that should only happen if you have edited or changed one of the files in the install folder yourself but I have heard of cases where this has got triggered without any explicit changes having been made.

Hi, I have several RPi Cams running and I was never able to run ./update.sh successfully. I just tried again on a RPi2 running v6.2.7 and when I execute the update.sh command it says:

remote: Counting objects: 129, done.
remote: Total 129 (delta 89), reused 89 (delta 89), pack-reused 40
Empfange Objekte: 100% (129/129), 113.22 KiB | 0 bytes/s, Fertig.
Löse Unterschiede auf: 100% (97/97), abgeschlossen mit 21 lokalen Objekten.
Von https://github.com/silvanmelchior/RPi_Cam_Web_Interface
* branch master -> FETCH_HEAD
fae22c7..c4d19ec master -> origin/master
Aktualisiere fae22c7..c4d19ec
error: Your local changes to the following files would be overwritten by merge:
install.sh
remove.sh
start.sh
stop.sh
Please, commit your changes or stash them before you can merge.
Aborting

***************
*** ABORTED ***
***************

An error occurred. Exiting...

Code: Select all

cat ./update.txt

+++ readlink -f ./update.sh
++ dirname ~/downloads/RPi_Cam_Web_Interface/update.sh
+ cd ~/downloads/RPi_Cam_Web_Interface
+ color_red='tput setaf 1'
+ color_green='tput setaf 2'
+ color_reset='tput sgr0'
+ trap fn_abort 0
+ set -e
++ git ls-remote -h origin master
++ awk '{print $1}'
+ remote=c4d19ec98597a8e8792b46b2cac83ddb65e6b848
++ git rev-parse HEAD
+ local=fae22c72b41260d3e47ddbda7c294685c79b83d0
+ printf 'Local : %s\nRemote: %s\n' fae22c72b41260d3e47ddbda7c294685c79b83d0 c4d19ec98597a8e8792b46b2cac83ddb65e6b848
+ [[ fae22c72b41260d3e47ddbda7c294685c79b83d0 == c4d19ec98597a8e8792b46b2cac83ddb65e6b848 ]]
+ dialog --title 'Update message' --infobox 'Commits don'\''t match. We update.' 4 35
+ sleep 2
+ git pull origin master
+ fn_abort
+ tput setaf 1
+ echo '
***************
*** ABORTED ***
***************
'
+ echo 'An error occurred. Exiting...'
+ tput sgr0
+ exit 1

You bet I never have changed the content of the mentioned scripts. So why update.sh always fail? Is there any switch I can apply to the update.sh script so the update is forced?

[btidey]

Hi, I have several RPi Cams running and I was never able to run ./update.sh successfully. I just tried again on a RPi2 running v6.2.7 and when I execute the update.sh command it says:

You bet I never have changed the content of the mentioned scripts. So why update.sh always fail? Is there any switch I can apply to the update.sh script so the update is forced?

I don't know why github sometimes thinks content has changed even when apparently it hasn't.

There are git commands to force a resync but it is quite quick and easy when this happens is to delete the RPi folder, clone again and run ./install.sh .

update.sh actually runs install.sh after it has fetched the updates from github so the operations are effectively identical.

I'll look into seeing whether I can change the github commands in update.sh to avoid this situation.

Edit: It looks like replacing the line in update.sh
git pull origin master

with
git fetch origin master

may avoid this issue which I think is triggered by the install putting some extra files into the folder structure which the merge objects to.

[GammaScorpii]

Having problems with the latest update (6.2.23).

The problem is the camera stops recording and resets itself (as if I clicked Turn off camera off and on). At first it was seemingly random, but I was reliably causing this to happen at one stage by clicking into a different page (such as Download Video and Images), and then clicking back to go back to the main page while recording video simultaneously.

Anyone else having these problems or have any idea what it could be? E.g. Low voltage, camera cable coming loose? Could lots of wifi interference cause it?

This has only started happening since I updated to 6.2.23 from 6.2.19.

I am not aware of any change that could have triggered this and I don't see a problem with all my cameras running latest version.

It is more likely to be one of the issues you mention but if you want to check out whether the change could be the cause on your system then I attach a zip containing just the executable

To replace then stop the camera running (./stop.sh in RPi_Cam folder) then replace the raspimjpeg file in /opt/vc/bin with the one in the zip. E.g move the replacement raspimjpeg to your home folder. Then

Code: Select all

sudo mv /opt/vc/bin/raspimjpeg ~/raspimjpeg.new
sudo mv ~/raspimjpeg /opt/vc/bin/raspimjpeg

The restart the camera ./start.sh in RPi_Cam folder.

You can revert it back to the current version by the same procedure but use the raspimjpeg.new

I just downgraded to .19 and it's fixed again. If someone would like to try and recreate the problem, try switching your wifi channel to 13. This is my only guess right now, because I took it home and tried it on a different network and it was perfect, even with the latest version. On the network I'm using at the moment however, it 100% glitches out. For some reason 6.2.19 works fine.

[btidey]

I just downgraded to .19 and it's fixed again. If someone would like to try and recreate the problem, try switching your wifi channel to 13. This is my only guess right now, because I took it home and tried it on a different network and it was perfect, even with the latest version. On the network I'm using at the moment however, it 100% glitches out. For some reason 6.2.19 works fine.

Did you change just the raspimjpeg back to .19 to see it working on this network, or did you revert the whole thing back?

If its network related then it may be worth lowering bandwidth being used for the live preview to see if that affects things.

Do that by changing Camera Settings / Preview quality

Try say Quality = 7, Size = 256, Divider = 3

The preview size will change but the bandwidth being used will drop by 10 times.

[Pangu]

Hi, I have several RPi Cams running and I was never able to run ./update.sh successfully. I just tried again on a RPi2 running v6.2.7 and when I execute the update.sh command it says:

You bet I never have changed the content of the mentioned scripts. So why update.sh always fail? Is there any switch I can apply to the update.sh script so the update is forced?

I don't know why github sometimes thinks content has changed even when apparently it hasn't.

There are git commands to force a resync but it is quite quick and easy when this happens is to delete the RPi folder, clone again and run ./install.sh .

update.sh actually runs install.sh after it has fetched the updates from github so the operations are effectively identical.

I'll look into seeing whether I can change the github commands in update.sh to avoid this situation.

Edit: It looks like replacing the line in update.sh
git pull origin master

with
git fetch origin master

may avoid this issue which I think is triggered by the install putting some extra files into the folder structure which the merge objects to.

Hi btidey,

as already mentioned, the "update.sh" script ALWAYS failed on all my RPi Web installations. I tried what you suggested, I changed "git pull origin master" to "git fetch origin master" and afterwards I was able to run .update.sh successfully. Although in the following I did not realize that version information on the top header changed but nevertheless the update did succeed

[btidey]

Hi btidey,

as already mentioned, the "update.sh" script ALWAYS failed on all my RPi Web installations. I tried what you suggested, I changed "git pull origin master" to "git fetch origin master" and afterwards I was able to run .update.sh successfully. Although in the following I did not realize that version information on the top header changed but nevertheless the update did succeed

Thanks. It is now changed to 'fetch' on github as otherwise the change would itself get wiped out.

[jussi24]

Hello Robert, folks,

I'm afraid I missed more than half a year joining this forum. My cams worked like charm with v5.4.1. Now one has given up (an outdoor cam, perhaps too cold), so I have to reflash it. Looking at the newest threads I wonder what has changed. Reading 20+ forum pages here is no option, the fundamental eLinux.org pages may miss some new features/gimmick, too.
So I wonder if there's a changelog for the whole project? Would be the fastest way to get me up to date....

Thanks a lot!

[btidey]

Hello Robert, folks,

I'm afraid I missed more than half a year joining this forum. My cams worked like charm with v5.4.1. Now one has given up (an outdoor cam, perhaps too cold), so I have to reflash it. Looking at the newest threads I wonder what has changed. Reading 20+ forum pages here is no option, the fundamental eLinux.org pages may miss some new features/gimmick, too.
So I wonder if there's a changelog for the whole project? Would be the fastest way to get me up to date....

Thanks a lot!

If you go onto the github page https://github.com/silvanmelchior/RPi_Cam_Web_Interface and press the commits link then you will get a dated list of all the commits with a headline on the change made in each one.

[GammaScorpii]

I just downgraded to .19 and it's fixed again. If someone would like to try and recreate the problem, try switching your wifi channel to 13. This is my only guess right now, because I took it home and tried it on a different network and it was perfect, even with the latest version. On the network I'm using at the moment however, it 100% glitches out. For some reason 6.2.19 works fine.

Did you change just the raspimjpeg back to .19 to see it working on this network, or did you revert the whole thing back?

If its network related then it may be worth lowering bandwidth being used for the live preview to see if that affects things.

Do that by changing Camera Settings / Preview quality

Try say Quality = 7, Size = 256, Divider = 3

The preview size will change but the bandwidth being used will drop by 10 times.

Ok ignore what I said about the wifi channel, and about the latest update. I still have a problem it seems.

I turned on a camera and left it recording for about 20 minutes. After about 15 minutes it stopped by itself. At this point I can no longer record more than 5 seconds before the camera stops itself. Changing the preview size unfortunately did not fix it. I even reduced it to 2 and it still would only record about 5 seconds at a time.

I did a reboot and I still cannot record. The files that it's creating always show as "Busy" on the downloaded video and images page, and I can see that they are not being made into mp4s despite the fact that I have boxing mode set to "Background". I ran a few tests with the bitrate setting and I can see it is actually making some difference (see image below):



Does that look like a problem with the sd card? Or something else software related? I am recording to an xfs partition which is shared in samba.

If anyone can help me get to the bottom of this, I will love you forever.

[btidey]

Ok ignore what I said about the wifi channel, and about the latest update. I still have a problem it seems.

I turned on a camera and left it recording for about 20 minutes. After about 15 minutes it stopped by itself. At this point I can no longer record more than 5 seconds before the camera stops itself. Changing the preview size unfortunately did not fix it. I even reduced it to 2 and it still would only record about 5 seconds at a time.

I did a reboot and I still cannot record. The files that it's creating always show as "Busy" on the downloaded video and images page, and I can see that they are not being made into mp4s despite the fact that I have boxing mode set to "Background". I ran a few tests with the bitrate setting and I can see it is actually making some difference (see image below):

Does that look like a problem with the sd card? Or something else software related? I am recording to an xfs partition which is shared in samba.

If anyone can help me get to the bottom of this, I will love you forever.

The directory listing shows .h264 files but not .mp4 files. The recording process captures the files as raw compressed .h264 files and then subsequently submits them to a queue where the MP4Box process wraps them into a .mp4 format and renames them with a .mp4 final extension.

The web interface will show files as busy when there is no .mp4 file as it thinks the conversion could still be in progress.

First thing to check is that the Camera Setting MP4 Boxing mode is set to the normal 'background'. The off setting is for those who deliberately wish to get .h264 files to process themselves.

Second thing is to check the scheduler log which will show the capture events followed by the MP4 boxing events.

Third is to divide / simplify the configuration for diagnostic purposes. Get rid of any special shares and check whether local recording and boxing to the default local media folder on SD card is working OK.

Fourth when introducing any share make sure that user www-data has ownership / permission writes to still read and write the folder.

I would also check powering arrangements (supply and cable) to make sure the Pi + Camera is getting a solid > 4.75V at the Pi itself.

[GammaScorpii]

Ok ignore what I said about the wifi channel, and about the latest update. I still have a problem it seems.

I turned on a camera and left it recording for about 20 minutes. After about 15 minutes it stopped by itself. At this point I can no longer record more than 5 seconds before the camera stops itself. Changing the preview size unfortunately did not fix it. I even reduced it to 2 and it still would only record about 5 seconds at a time.

I did a reboot and I still cannot record. The files that it's creating always show as "Busy" on the downloaded video and images page, and I can see that they are not being made into mp4s despite the fact that I have boxing mode set to "Background". I ran a few tests with the bitrate setting and I can see it is actually making some difference (see image below):

Does that look like a problem with the sd card? Or something else software related? I am recording to an xfs partition which is shared in samba.

If anyone can help me get to the bottom of this, I will love you forever.

The directory listing shows .h264 files but not .mp4 files. The recording process captures the files as raw compressed .h264 files and then subsequently submits them to a queue where the MP4Box process wraps them into a .mp4 format and renames them with a .mp4 final extension.

The web interface will show files as busy when there is no .mp4 file as it thinks the conversion could still be in progress.

First thing to check is that the Camera Setting MP4 Boxing mode is set to the normal 'background'. The off setting is for those who deliberately wish to get .h264 files to process themselves.

Second thing is to check the scheduler log which will show the capture events followed by the MP4 boxing events.

Third is to divide / simplify the configuration for diagnostic purposes. Get rid of any special shares and check whether local recording and boxing to the default local media folder on SD card is working OK.

Fourth when introducing any share make sure that user www-data has ownership / permission writes to still read and write the folder.

I would also check powering arrangements (supply and cable) to make sure the Pi + Camera is getting a solid > 4.75V at the Pi itself.

Thanks for the advice. I've checked most of those things already. But since my last post I think I may have found the answer. Is anyone here running the latest rpi-update firmware by any chance? I ran it when I updated the web interface, and I first got the problem. So I rolled back to 3ffa1c624ae8b5f02a6aac764d407e8d3b5a09bb and everything seems ok for now...

[btidey]

Thanks for the advice. I've checked most of those things already. But since my last post I think I may have found the answer. Is anyone here running the latest rpi-update firmware by any chance? I ran it when I updated the web interface, and I first got the problem. So I rolled back to 3ffa1c624ae8b5f02a6aac764d407e8d3b5a09bb and everything seems ok for now...

Thanks for update.

As far as I can see that rollback kernel was to 4.4.33. (Nov 22 2016)

I have cameras running from latest Jessie release which use 4.4.38 (af9cb14d5053f89857225bd18d1df59a089c171e) ( Dec 15 2016)which are OK for me.

The latest kernel which rpi-update upgrades to is 4.4.43. (Jan 15 2017) I'll try that out to see how that goes.

Update: rpi-update to latest 4.4.43 (a12b699d642096023a2b3009bb88ca82ad0baef4) is working fine on a Pi 3

Update2: Also checking on Pi Zero (which should be same as A or B). I thought was Ok but it may have problems. So it could be latest kernel has problems on older architecture Pi.I don't have Pi2 based camera to check on that.

[GammaScorpii]

Thanks for the advice. I've checked most of those things already. But since my last post I think I may have found the answer. Is anyone here running the latest rpi-update firmware by any chance? I ran it when I updated the web interface, and I first got the problem. So I rolled back to 3ffa1c624ae8b5f02a6aac764d407e8d3b5a09bb and everything seems ok for now...

Thanks for update.

As far as I can see that rollback kernel was to 4.4.33. (Nov 22 2016)

I have cameras running from latest Jessie release which use 4.4.38 (af9cb14d5053f89857225bd18d1df59a089c171e) ( Dec 15 2016)which are OK for me.

The latest kernel which rpi-update upgrades to is 4.4.43. (Jan 15 2017) I'll try that out to see how that goes.

Update: rpi-update to latest 4.4.43 (a12b699d642096023a2b3009bb88ca82ad0baef4) is working fine on a Pi 3

Update2: Also checking on Pi Zero (which should be same as A or B). I thought was Ok but it may have problems. So it could be latest kernel has problems on older architecture Pi.I don't have Pi2 based camera to check on that.

All my cameras are Pi 2s. After several more tests it appears that either the latest (4.4.43) or possibly an update close to it was the problem for me.

[btidey]

All my cameras are Pi 2s. After several more tests it appears that either the latest (4.4.43) or possibly an update close to it was the problem for me.

My tests so far show that Pi Zero is OK up to 4.4.38 (af9cb14d5053f89857225bd18d1df59a089c171e) but is broken by an update on Dec 30th (87bf11faa6ccefb7969821bff8cbc44f72be7414)

New Pi2 are more like a Pi3 but older ones have a intermediate CPU.

The behaviour I am getting on Pi Zero with the Dec 30 update is that it will run for a bit but then the callbacks feeding the preview stop and the watchdog then times out and resets the system.

[rjhazeld]

I have recently installed this app with nginx on a Pi3 and a Pi Zero on both I have the app working fine except that when motion (External) is running I can't get the settings. The page opens but is blank.
I have been able to make changes to the schedule (dawn & Dusk plus space limit for purge). The log shows capture instructions from pipe followed by ca 1 and after capture complete ca 0 which seems to suggest the passing of calls between motion and the app are working.
The Pi Zero which was a clean install of the full Jessie via NOOBs on a 32gb sd card. The latest version of the app files was loaded yesterday. the install was to /var/www/cam. Any ideas on what may be stopping the motion settings displaying or how to find the cause would be appreciated.
Thanks.

[btidey]

I have recently installed this app with nginx on a Pi3 and a Pi Zero on both I have the app working fine except that when motion (External) is running I can't get the settings. The page opens but is blank.
I have been able to make changes to the schedule (dawn & Dusk plus space limit for purge). The log shows capture instructions from pipe followed by ca 1 and after capture complete ca 0 which seems to suggest the passing of calls between motion and the app are working.
The Pi Zero which was a clean install of the full Jessie via NOOBs on a 32gb sd card. The latest version of the app files was loaded yesterday. the install was to /var/www/cam. Any ideas on what may be stopping the motion settings displaying or how to find the cause would be appreciated.
Thanks.

The motion parameters page for external motion gets its data from a web api maintained by the motion process. If motion is not running then you get a message to that effect on the page but it sounds like you have it running but just get no data.

So it sounds like this the motion api is not being accessed successfully for some reason.

The set up for motion is in the /etc/motion/motion.conf file. When RPi_Cam is installed the motion.conf file should have these settings in to control the api.

Code: Select all

# TCP/IP port for the http server to listen on (default: 0 = disabled)
webcontrol_port 6642

# Restrict control connections to localhost only (default: on)
webcontrol_localhost on

# Output for http server, select off to choose raw text plain (default: on)
webcontrol_html_output off

These mean the api is accessed at port 6642, it sends plain text parameters back, and it can only be accessed from the raspberry pi itself.
Check those first.

If they look OK then you can test as follows.
1) Turn motion detection off.
2) Edit the motion.conf file (sudo nano /etc/motion/motion.conf file to have webcontrol_localhost on (This will allow external browsers to access it)
3) Turn motion detection on.
4) Try browsing to http://cameraip:6642/0/config/list (put your camerip in)

You should get back a text list of all the parameters in motion.conf. That is what the RPi Cam web pages use to display the parameters.

[rjhazeld]

Thanks for the quick and detailed reply.
I followed the steps suggested but did not find either webcontrol_localhost or webcontrol_html in the conf file in both cases 'web' was missed off i.e. control_localhost and control_html. Adding web at the start of each and restarting motion resolved the problem. I have checked in the installation folder and the motion.conf1 file there has the same omission so the GitHub version may need to be updated.
Thanks for your help.

[btidey]

Thanks for the quick and detailed reply.
I followed the steps suggested but did not find either webcontrol_localhost or webcontrol_html in the conf file in both cases 'web' was missed off i.e. control_localhost and control_html. Adding web at the start of each and restarting motion resolved the problem. I have checked in the installation folder and the motion.conf1 file there has the same omission so the GitHub version may need to be updated.
Thanks for your help.

Good to hear your system is working OK now.

I think the install works OK normally.

Originally motion did use the parameters without web in front and then an update changed the name. The install deliberately looks just for the control_port and changes the parameter value after it. So webcontrol_port XXXX gets changed to webcontrol_port 6642

Maybe what happened in your case was that you had an older version of motion installed that used control_port without the web prefix. The camera install would have updated motion but the old motion.conf was still there and then it would be left as control_port

It may be possible to change the install so that it deals with this. The reason I hadn't changed it was that motion has changed the name of its parameters and this method would work as long as the name ended with control_port.

[Arrebar]

I am preparing a home security camera system for someone. For this purpose I use a raspberry pi 3 with the original camera and display. To prevent the display to be on 24/7 I have installed a screensaver on the raspberry.

Upon motion detection, I want run a script that stops the screensaver. The script works when I use it from the commandline, but it does not work from the RPI cam web interface. The log shows the script is executed, however, nothing happens:

[2017/01/21 20:22:17] Start capture requested from Pipe
[2017/01/21 20:22:17] Send sy screen.sh
{2017/01/21 20:22:17} Executing macro /var/www/html/macros/screen.sh &
[2017/01/21 20:22:19] Send im

In the macros folder, ls -l will give -rwxrwxrwx 1 www-data www-data screen.sh

Does anyone work with the macros? Of does anyone have another idea how to call my script file upon motion detection.
Many thanks

[rjhazeld]

A bit odd since this was a clean install of a fresh download of Jessie onto a brand new card on two Pi a pi zero and a Pi 3b.

I found the install instructions on the elinux page a bit confusing with the instructions for Jessie Light and then some additional workarounds for Jessie. It seems that the ./install works for Jessie now so maybe an edit of that focusing on the new approach with a note that if motion settings aren't displayed when external motion is started to check that the HTTP Control settings are correct. The RPi_Cam_Web_Interface_Installer details could be put at the end of the section for reference. For most running, ./install and completing the dialogue box, will work fine.

It's a great piece of software in its own right and as a base from which custom pages can be created.

[Gary Littlemore]

I've just done a fresh install using Jessie Lite, I was on Wheesy before and now I'm not able to SSH on to the Pi. Anyone got any ideas why?

[rpdom]

I've just done a fresh install using Jessie Lite, I was on Wheesy before and now I'm not able to SSH on to the Pi. Anyone got any ideas why?

SSH isn't enabled by default on the latest Raspbian for security reasons. You can enable it by creating a file in the /boot partition called "ssh" (with no extension), then rebooting.

[Max1968]

Hi,

I'm using this for several cams around the house for ~2 years now, and i really like it. About 3 months ago i changed from external motion to internal motion detection and "outsourced" the boxing to a NAS where I stored the videos anyway in order to reduce load on the pi's.

However recently some of my cameras are "loosing" events, and I found the following entries in some of my cameras' logs:

Entrance Camera:

Code: Select all

[2017/01/23 10:05:34] Scheduler loop is started
{2017/01/23 10:05:34} DEBUG 3
[2017/01/23 10:05:35] New period detected 0
[2017/01/23 10:05:35] Scheduled management tasks. Next at 1485165935
{2017/01/23 10:06:25} Watchdog detected problem. Stopping{2017/01/23 10:06:26} SIGINT/SIGTERM received, stopping
{2017/01/23 10:06:31} RaspiMJPEG Version 5.6.9
{2017/01/23 10:06:31} recommended video buffers 1
{2017/01/23 10:06:31} h264 buffers set to recommended 1
{2017/01/23 10:06:31} Set up internal detect width=82 height=61
{2017/01/23 10:06:31} Opening FIFO 0 /var/www/FIFO 7
{2017/01/23 10:06:31} MJPEG streaming, ready to receive commands
{2017/01/23 10:06:31} send smd 9
{2017/01/23 10:06:31} Starting command loop
[2017/01/23 10:06:31] Reload parameters command requested
[2017/01/23 10:06:31] Scheduler loop is started
{2017/01/23 10:06:31} DEBUG 3
[2017/01/23 10:06:32] New period detected 0
[2017/01/23 10:06:32] Scheduled management tasks. Next at 1485165992
{2017/01/23 10:07:16} Watchdog detected problem. Stopping{2017/01/23 10:07:16} SIGINT/SIGTERM received, stopping
{2017/01/23 10:07:21} RaspiMJPEG Version 5.6.9
{2017/01/23 10:07:21} recommended video buffers 1
{2017/01/23 10:07:21} h264 buffers set to recommended 1
{2017/01/23 10:07:22} Set up internal detect width=82 height=61
{2017/01/23 10:07:22} Opening FIFO 0 /var/www/FIFO 7
{2017/01/23 10:07:22} MJPEG streaming, ready to receive commands
{2017/01/23 10:07:22} send smd 9
{2017/01/23 10:07:22} Starting command loop
[2017/01/23 10:07:22] Reload parameters command requested
[2017/01/23 10:07:22] Scheduler loop is started
{2017/01/23 10:07:22} DEBUG 3
[2017/01/23 10:07:23] New period detected 0
[2017/01/23 10:07:23] Scheduled management tasks. Next at 1485166043
{2017/01/23 10:07:44} Watchdog detected problem. Stopping{2017/01/23 10:07:44} SIGINT/SIGTERM received, stopping
{2017/01/23 10:07:49} RaspiMJPEG Version 5.6.9
{2017/01/23 10:07:50} recommended video buffers 1
{2017/01/23 10:07:50} h264 buffers set to recommended 1
{2017/01/23 10:07:50} Set up internal detect width=82 height=61
{2017/01/23 10:07:50} Opening FIFO 0 /var/www/FIFO 7
{2017/01/23 10:07:50} MJPEG streaming, ready to receive commands
{2017/01/23 10:07:50} send smd 9
{2017/01/23 10:07:50} Starting command loop
[2017/01/23 10:07:50] Reload parameters command requested
[2017/01/23 10:07:50] Scheduler loop is started
{2017/01/23 10:07:50} DEBUG 3
[2017/01/23 10:07:51] New period detected 0
[2017/01/23 10:07:51] Scheduled management tasks. Next at 1485166071

Backdoor Camera:

Code: Select all

{2017/01/23 10:01:36} Starting command loop
[2017/01/23 10:01:36] Reload parameters command requested
[2017/01/23 10:01:36] Scheduler loop is started
{2017/01/23 10:01:36} DEBUG 3
[2017/01/23 10:01:37] New period detected 0
[2017/01/23 10:01:37] Scheduled management tasks. Next at 1485165697
{2017/01/23 10:02:05} Watchdog detected problem. Stopping{2017/01/23 10:02:05} SIGINT/SIGTERM received, stopping
{2017/01/23 10:02:10} RaspiMJPEG Version 5.6.9
{2017/01/23 10:02:10} recommended video buffers 1
{2017/01/23 10:02:10} h264 buffers set to recommended 1
{2017/01/23 10:02:11} Set up internal detect width=82 height=61
{2017/01/23 10:02:11} Opening FIFO 0 /var/www/FIFO 7
{2017/01/23 10:02:11} MJPEG streaming, ready to receive commands
{2017/01/23 10:02:11} send smd 9
{2017/01/23 10:02:11} Starting command loop
[2017/01/23 10:02:11] Reload parameters command requested
[2017/01/23 10:02:11] Scheduler loop is started
{2017/01/23 10:02:11} DEBUG 3
[2017/01/23 10:02:12] New period detected 0
[2017/01/23 10:02:12] Scheduled management tasks. Next at 1485165732
{2017/01/23 10:05:04} Watchdog detected problem. Stopping{2017/01/23 10:05:04} SIGINT/SIGTERM received, stopping
{2017/01/23 10:05:09} RaspiMJPEG Version 5.6.9
{2017/01/23 10:05:09} recommended video buffers 1
{2017/01/23 10:05:09} h264 buffers set to recommended 1
{2017/01/23 10:05:09} Set up internal detect width=82 height=61
{2017/01/23 10:05:09} Opening FIFO 0 /var/www/FIFO 7
{2017/01/23 10:05:09} MJPEG streaming, ready to receive commands
{2017/01/23 10:05:09} send smd 9
{2017/01/23 10:05:09} Starting command loop
[2017/01/23 10:05:09] Reload parameters command requested
[2017/01/23 10:05:09] Scheduler loop is started
{2017/01/23 10:05:10} DEBUG 3
[2017/01/23 10:05:10] New period detected 0
[2017/01/23 10:05:10] Scheduled management tasks. Next at 1485165910
{2017/01/23 10:06:49} Watchdog detected problem. Stopping{2017/01/23 10:06:49} SIGINT/SIGTERM received, stopping
{2017/01/23 10:06:54} RaspiMJPEG Version 5.6.9
{2017/01/23 10:06:54} recommended video buffers 1
{2017/01/23 10:06:54} h264 buffers set to recommended 1
{2017/01/23 10:06:54} Set up internal detect width=82 height=61
{2017/01/23 10:06:55} Opening FIFO 0 /var/www/FIFO 7
{2017/01/23 10:06:55} MJPEG streaming, ready to receive commands
{2017/01/23 10:06:55} send smd 9
{2017/01/23 10:06:55} Starting command loop
[2017/01/23 10:06:55] Reload parameters command requested
[2017/01/23 10:06:55] Scheduler loop is started
{2017/01/23 10:06:55} DEBUG 3
[2017/01/23 10:06:56] New period detected 0
[2017/01/23 10:06:56] Scheduled management tasks. Next at 1485166016

Terrace Camera:

Code: Select all

{2017/01/23 10:06:01} send smd 9
{2017/01/23 10:06:01} Starting command loop
[2017/01/23 10:06:01] Reload parameters command requested
[2017/01/23 10:06:01] Scheduler loop is started
[2017/01/23 10:06:02] New period detected 0
[2017/01/23 10:06:02] Scheduled management tasks. Next at 1485165962
{2017/01/23 10:07:40} Watchdog detected problem. Stopping{2017/01/23 10:07:41} SIGINT/SIGTERM received, stopping
{2017/01/23 10:07:46} RaspiMJPEG Version 5.6.9
{2017/01/23 10:07:46} recommended video buffers 1
{2017/01/23 10:07:46} h264 buffers set to recommended 1
{2017/01/23 10:07:46} Set up internal detect width=82 height=61
{2017/01/23 10:07:46} Opening FIFO 0 /var/www/FIFO 7
{2017/01/23 10:07:46} MJPEG streaming, ready to receive commands
{2017/01/23 10:07:46} send smd 9
{2017/01/23 10:07:46} Starting command loop
[2017/01/23 10:07:46] Reload parameters command requested
[2017/01/23 10:07:46] Scheduler loop is started
{2017/01/23 10:07:46} DEBUG 3
[2017/01/23 10:07:47] New period detected 0
[2017/01/23 10:07:47] Scheduled management tasks. Next at 1485166067
{2017/01/23 10:08:50} Watchdog detected problem. Stopping{2017/01/23 10:08:50} SIGINT/SIGTERM received, stopping
{2017/01/23 10:08:56} RaspiMJPEG Version 5.6.9
{2017/01/23 10:08:56} recommended video buffers 1
{2017/01/23 10:08:56} h264 buffers set to recommended 1
{2017/01/23 10:08:56} Set up internal detect width=82 height=61
{2017/01/23 10:08:56} Opening FIFO 0 /var/www/FIFO 7
{2017/01/23 10:08:56} MJPEG streaming, ready to receive commands
{2017/01/23 10:08:56} send smd 9
{2017/01/23 10:08:56} Starting command loop
[2017/01/23 10:08:56] Reload parameters command requested
[2017/01/23 10:08:56] Scheduler loop is started
{2017/01/23 10:08:56} DEBUG 3
[2017/01/23 10:08:57] New period detected 0
[2017/01/23 10:08:57] Scheduled management tasks. Next at 1485166137
{2017/01/23 10:09:15} Watchdog detected problem. Stopping{2017/01/23 10:09:15} SIGINT/SIGTERM received, stopping
{2017/01/23 10:09:20} RaspiMJPEG Version 5.6.9
{2017/01/23 10:09:21} recommended video buffers 1
{2017/01/23 10:09:21} h264 buffers set to recommended 1
{2017/01/23 10:09:21} Set up internal detect width=82 height=61
{2017/01/23 10:09:21} Opening FIFO 0 /var/www/FIFO 7
{2017/01/23 10:09:21} MJPEG streaming, ready to receive commands
{2017/01/23 10:09:21} send smd 9
{2017/01/23 10:09:21} Starting command loop
[2017/01/23 10:09:21] Reload parameters command requested
[2017/01/23 10:09:21] Scheduler loop is started
{2017/01/23 10:09:21} DEBUG 3
[2017/01/23 10:09:22] New period detected 0
[2017/01/23 10:09:22] Scheduled management tasks. Next at 1485166162

As you can see, all these are restarted by watchdog almost every minute. The cameras mounted in the nestboxes dont have these issues, unfortunately I dont have exact temperature/moisture data for all my cameras, but for sure these are mounted in a unfriendly environment. They are protected from rain as they are underneath a ceiling, but for sure they are facing low temperature (it is -13° outside right now) and there might even be some moisture sometimes. Might this be the reason or is there anything else I can check to figure out the root cause ?

I wanted to mount these inside anyway and just expose the camera lens to the outside, but didnt have time yet to do this - So this might move this up my todo list if it is the reason