RPi_Cam_Web_Interface
RPi_Cam_Web_Interface copied to clipboard
silvanmelchior
Raspberry Pi Zero crashes without a log entry
Hey,
I set up this interface on my RaspberryPi Zero W yesterday. It opens up just fine, I can see the live stream, take full res images, videos etc.
Problem: When starting a motion detection (internal or external), the pi completely freezes after 10-30 seconds. This then requires a hard restart by unplugging the power source.
Do you have any idea, why this could be happening? I tried both, internal and external detection mode - no difference.
The log file, which I am currently getting from the web interface via /cam/schedule.php > "Download Log", doesn't show anything about the crashes happen. Is there another log file with more info?
If this is performance related and the Pi Zero just can't record video while looking for motion, would it help to take photos instead of videos when motion is detected? I would prefer full res photos over video recording anyways, but haven't found a setting for this yet.
Greetings! :)
Edit. I just found, If I start via debug.sh, it throws out this
Watchdog detected problem. StoppingSIGINT/SIGTERM received, stopping
Another error I can see when recording in 30s splits is this:
Capturing with split of 30 seconds
Capturing started
Stopping video from timer
Capturing stopped
Add /var/www/cam/media/vi_0001_20191011_171422.mp4 to Box Queue at pos 0
Restarting next split of 30 seconds
mmal: mmal_vc_port_info_set: failed to set port info (2:0): EINVAL
mmal: mmal_vc_port_set_format: mmal_vc_port_info_set failed 0x67b280 (EINVAL)
mmal: mmal_connection_create: format not set on input port
mmal: mmal_connection_destroy_internal: connection vc.ril.camera:out:1/vc.ril.video_encode:in:0 could not be cleared
Error: Could not create connection camera -> video converter
Start boxing /var/www/cam/media/vi_0001_20191011_171422.h264 to /var/www/cam/media/vi_0001_20191011_171422.mp4 Queue pos 0
Finished boxing /var/www/cam/media/vi_0001_20191011_171422.mp4 from Box Queue at pos 0
Removed item from Box Queue
Most of my cameras are Pi Zeros and they run just fine with internal motion detection and full video recording. As much of the work is actually done by the GPU on the Pi the main CPU is not loaded all that much. This of course assumes that you are not running any other resource intense applications on the Pi at the same time,
First thing I would check out is how you are powering the Pi. It is important you have a stable 5V power source AND it is connected to the Pi by a low resistance cable. Many off the shelf USB cables actually have quite a high resistance and these can cause voltage drops along the cable when there are current surges which can occur with the camera. Make sure you use a short cable and that is of low resistance.
The watchdofg message indicates that there is a failure in the stream from the camera which can be caused by these power problems. Also double check the ribbon connection from the Pi to the camera. The connector at the Zero end is quite fragile and can sometimes get damaged and give a loose unstable connection. There is also a tiny ribbon connector on the camera module itself. Press that down to make sure it hasn't come loose,
I'm using the original raspberry pi power supply which never had problems running a Pi3 with Opencv in full load. So I assume that the power supply isn't a problem.
The pi itself is running the latest raspbian with nothing else installed. So no additional services.
The ribbon cable might be a thing. Ill double check that once I get home. I didn't know that the watchdog message suggests a streaming problem to the camera.
Thanks a bunch for the tips. I will report if the problem got solved. :)
Most of my cameras are Pi Zeros and they run just fine with internal motion detection and full video recording. As much of the work is actually done by the GPU on the Pi the main CPU is not loaded all that much. This of course assumes that you are not running any other resource intense applications on the Pi at the same time,
First thing I would check out is how you are powering the Pi. It is important you have a stable 5V power source AND it is connected to the Pi by a low resistance cable. Many off the shelf USB cables actually have quite a high resistance and these can cause voltage drops along the cable when there are current surges which can occur with the camera. Make sure you use a short cable and that is of low resistance.
The watchdofg message indicates that there is a failure in the stream from the camera which can be caused by these power problems. Also double check the ribbon connection from the Pi to the camera. The connector at the Zero end is quite fragile and can sometimes get damaged and give a loose unstable connection. There is also a tiny ribbon connector on the camera module itself. Press that down to make sure it hasn't come loose,
Hey,
I tried two different cables and power sources and also monitored the temperature in case it overheats (which is not the case).
I also tried a different (same model original) raspi camera and also another pi zero W with the same SD card. The problem persists, the pi keeps crashing.
I just whitnessed these lines in the command line in the moment the crash happened:
Message from syslogd@raspberrypi at Oct 13 15:53:42 ...
kernel:[ 573.821579] Internal error: Oops: 817 [#1] ARM
Message from syslogd@raspberrypi at Oct 13 15:53:42 ...
kernel:[ 573.894245] Process MP4Box (pid: 1104, stack limit = 0x0eaae8dd)
Message from syslogd@raspberrypi at Oct 13 15:53:42 ...
kernel:[ 573.896977] Stack: (0xd3501e30 to 0xd3502000)
Message from syslogd@raspberrypi at Oct 13 15:53:42 ...
kernel:[ 573.900554] 1e20: 00000000 d3501e 40 d2d48800 d2e3c8a0
Message from syslogd@raspberrypi at Oct 13 15:53:42 ...
kernel:[ 573.907422] 1e40: 00000055 006000c0 000b63f5 b63f5000 d3e52d88 d3e52d 88 00000000 00000000
Message from syslogd@raspberrypi at Oct 13 15:53:42 ...
kernel:[ 573.913803] 1e60: 00000000 00000000 d343a7d4 d2dd8378 00000000 f23f5d b4 d3501fb0 d2e03800
Message from syslogd@raspberrypi at Oct 13 15:53:42 ...
kernel:[ 573.919812] 1e80: 00000817 b63f5000 d2dd8340 d2dd8378 d3501ef4 d3501e a0 c06d60d8 c0142458
Message from syslogd@raspberrypi at Oct 13 15:53:42 ...
kernel:[ 573.924205] 1ea0: b63ec000 00000022 00000003 00000000 00000073 d2dd83 40 d3501f04 00000000
Message from syslogd@raspberrypi at Oct 13 15:53:42 ...
kernel:[ 573.928736] 1ec0: 00000800 00000000 000b63ec c09ee240 00000817 c09e90 28 c06d5db4 b63f5000
Message from syslogd@raspberrypi at Oct 13 15:53:42 ...
kernel:[ 573.933402] 1ee0: d3501fb0 00010892 d3501fac d3501ef8 c001abbc c06d5d c0 d3501f5c d3501f08
Message from syslogd@raspberrypi at Oct 13 15:53:42 ...
kernel:[ 573.938525] 1f00: c012d898 c005f78c 00000022 00000000 000b63ec d3501f 20 d3501f24 d3501f7c
Message from syslogd@raspberrypi at Oct 13 15:53:42 ...
kernel:[ 573.945241] 1f20: 00000000 d3501f24 d3501f24 f23f5db4 c09e9028 000000 22 00000003 00081000
Message from syslogd@raspberrypi at Oct 13 15:53:42 ...
kernel:[ 573.950453] 1f40: 00000000 c00091a4 d3500000 00000000 d3501f8c d3501f 60 c01465e0 c012d7dc
Message from syslogd@raspberrypi at Oct 13 15:53:42 ...
kernel:[ 573.957959] 1f60: 00000022 00000000 b6f9db44 c0009c7c ffffffff 00c538 7d 00c5387d 8bb4b139
Message from syslogd@raspberrypi at Oct 13 15:53:42 ...
kernel:[ 573.963385] 1f80: d3501fac f23f5db4 b6f9db44 20000010 ffffffff 00c538 7d 00c5387d 8bb4b139
Message from syslogd@raspberrypi at Oct 13 15:53:42 ...
kernel:[ 573.968867] 1fa0: 00000000 d3501fb0 c0009c84 c001ab78 b63f5000 b63bf0 0c 0000680e b3cd4ead
Message from syslogd@raspberrypi at Oct 13 15:53:42 ...
kernel:[ 573.974401] 1fc0: 2e489b1b 4b61e1bc 959b5572 ce73650b 5ab55e39 8bb4b1 39 00010892 00000000
Message from syslogd@raspberrypi at Oct 13 15:53:42 ...
kernel:[ 573.980122] 1fe0: 863cd482 bef5cb44 00000054 b6f9db44 20000010 ffffff ff 00000000 00000000
Message from syslogd@raspberrypi at Oct 13 15:53:42 ...
kernel:[ 574.024059] Code: e1a01005 e1a00007 ebff67cf e51b5034 (eaffff24)
Any idea about this?
Kernel crashes are not good but are normally indicative of something more fundamental at issue.
If possible start with a different SD card. Install latest buster raspbian on it then do the wiki install steps to get a totally clean system to check out.
Hi,
I got the same Problem with my Raspberry Pi Zero W as well...
Just installed buster freshly, but just to know; I am using a rather slow 32 GB Sandisk micro sd card - which card are you using?
Don't know if these kind of errors really come from a bad card... I hope it isn't but if I had to guess I'd say its a ram issue - but memtester checked all the ram for the last 24 hours and didn't find a single error... sooo.... maybe?
Cheers,
Late reply, but another pi zero fixed it for me. Same SD card, no changes, same installation. Old pi crashes, new pi is fine.
I use a variety of cards mainly Sandisk 8G,16G,32G. Some are fairly slow type 4 but I have not noticed any problems.
It might be worth checking the camera connector on the bad Pi zero. They are very fragile and prone to the plastic breaking and not making good contact. These can sometimes be repaired by using tape.
Late reply, but another pi zero fixed it for me. Same SD card, no changes, same installation. Old pi crashes, new pi is fine.
Hmm.. doesn't sound good, because both of my Zero W Pi'es are from a linux journal subscription :-( Don't think I have something like warranty on that...:-(
Hi, related issue on a Raspi Zero V1.3, the one without wifi, raspbian stretch. I get repeatedly unexpected reboots when activating motion detection with default settings. Preview works as expected.
As said earlier there is no fundamental problem with Pi Zero no wifi; most of my cameras are based on those.
It is strongly recommended to use the internal motion detection if not already doing so.
If it reboots all by itself then it would maybe suggest a powering problem. It is very important to get a good 5V at the Pi itself. There can be a significant voltage drop along some USB cables. Also it is worth checking the insertion of the ribbon cable from Pi to camera at both ends.
I have checked with my other PI Zero, this is without wifi, too. What should i say, it just worked. The power supply chain is a 2.4VA 12 Volts one connected to a regulated battery loading circuit set to 5 volts, the usb cable part is 10 cm long.
The both pi zeroes tested differ in that both were purchased month away from each other through a german online retail shop. Both are Pi Zero V1.3V PCB's, same Toshiba 16 GB SD card, the one rebooting has an GPIO connector soldered in, the one functioning properly is pristine on that.
Nevertheless, reproducing the issue using my regulated laboratory 50 Watts power supply is on the list. Will check with 5.2 Volts.
Although this is a fairly old issue, just for the record: I've experienced the same issue. The pi0 was rebooting when accessing the web interface. The problem seemed to origin from a 3m USB extension cable. Using a cheap USB voltage meter, I've measured the voltage going down to 4.12 V, with the pi0 booted. There are no issues with a shorter cable. The voltage then remains around 4.9 V.
Yes. Dodgy power is a common source of problems.
It can be a combination of the length of cable plus the gauge of wire used within the cable. I have even seen 1 metre cables which had an internal resistance of 1 Ohm. With even a Pi 0 plus camera that can cause 0.6V drop in voltage at the Pi and problems then follow. One can find USB cables where the gauge is specified but most do not.
It is possible to use long cables even greater than 3 metres providing the wire gauge is substantial. I often make up my own power usb cables using just dual core cable and withe right guage can get less than 0.1 Ohm even on long runs.
Original poster here. This Pi zero is still running to this day. Cable is around 2 meters.
The pi that I first had problems with fully died a bit later. So probably a faulty pi in my case?