Video Drops/Cam Freeze

[EQNish]

Been using OpenMiko for almost a year on about 12 cams, I like the project, love the RTSP and no Cloud feature, but my Cams Lock/freeze and/or stop sending video. In order to fix I have to reboot/remove power, any ideas what to tweak to fix this? where should I start?

[nosoop]

If this is happening every 15 minutes, it's likely because of wpa_supplicant being SIGHUP'd due to logrotate.

My workaround was to disable logging on wpa_supplicant by creating an overlay with the following changes applied:

--- /etc/init.d/S35wifi
+++ /etc/init.d/S35wifi
@@ -31,7 +31,7 @@
        # https://stackoverflow.com/questions/1251999/how-can-i-replace-a-newline-n-using-sed
        sed -i ':a;N;$!ba;s/\r//g' "$CONFIGPATH/wpa_supplicant.conf"

-       wpa_supplicant -Dnl80211 -i wlan0 -c "$CONFIGPATH/wpa_supplicant.conf" -B -d -f /var/log/wpa_supplicant.log
+       wpa_supplicant -Dnl80211 -i wlan0 -c "$CONFIGPATH/wpa_supplicant.conf" -B -d

        HOSTNAME=`cat /etc/hostname`

--- /etc/logrotate.conf
+++ /etc/logrotate.conf
@@ -24,7 +24,7 @@
     rotate 2
     size 10k
     missingok
-    postrotate
-            /usr/bin/killall -SIGHUP wpa_supplicant
-    endscript
 }

You will need to set something up to ensure /etc/logrotate.conf has permissions set to u=rw,go=r after the overlay is applied, as logrotate is picky about that. I opted for creating /etc/init.d/S90fix_logrotate to fix those permissions on startup:

#!/bin/sh

# Fix permissions on logrotate
if [[ -f "/etc/logrotate.conf" ]]; then
  chmod u=rw,go=r "/etc/logrotate.conf"
fi

---

If you want to preserve logging behavior, this change also appears to work (/etc/init.d/S35wifi is unmodified in this case, but you will need to fix permissions on the logrotate config as before):

--- /etc/logrotate.conf
+++ /etc/logrotate.conf
@@ -24,7 +24,7 @@
     rotate 2
     size 10k
     missingok
-    postrotate
-            /usr/bin/killall -SIGHUP wpa_supplicant
-    endscript
+    copytruncate
 }

[martinbutt]

This could be the root cause of the issue that is causing the cameras to stop working suddenly when the filesystem becomes corrupted. I've created some branches to remove logging completely here and here. As my PRs are not being merged in this project, I decided to merge together all of my changes from the last six months and release them for testing. This should address the issue that it stops working after a while. Testing is appreciated, and you can file an issue in that repo if you have any problems.

[bill-mcgonigle]

my Cams Lock/freeze and/or stop sending video

@EQNish also see if your v4l2rtspserver is crashing (can you ssh in?). I use a script to check mine and restart it. Not sure why it dies - RAM on my camera might be imperfect (vi isn't even stable, though nano is, for instance). Cheap computers. :)

[KentBrockman]

I'm getting this issue as well (sometimes a few others) "this issue" being the RTSP stream dies after sometime. Seems I can't even get it started up:

# /etc/init.d/S60camera restart
killall: v4l2rtspserver: no process killed
killall: ffmpeg: no process killed
Adding necessary camera modules
root: Determined image sensor model as jxf23
insmod: can't insert '/driver/sensor_jxf23.ko': File exists
c
c
c
c
c
Audio is set to disabled in openmiko.conf. Skipping starting ffmpeg
Setting up 4 v4l2loopback device(s)
root: Starting video frame capture process
root: Starting v4l2rtspserver
VIDIOC_REQBUFS: Inappropriate ioctl for device
VIDIOC_STREAMOFF: Inappropriate ioctl for device
VIDIOC_REQBUFS: Inappropriate ioctl for device
VIDIOC_REQBUFS: Inappropriate ioctl for device
VIDIOC_STREAMOFF: Inappropriate ioctl for device
VIDIOC_REQBUFS: Inappropriate ioctl for device
VIDIOC_STREAMOFF: Bad file descriptor
VIDIOC_REQBUFS: Bad file descriptor
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc

This is on v0.0.40. MJPEG seems to work fine however. Rebooting the camera sometimes brings things back up.