Motion doesnt detect cam hangups

Question

motion 3.1.17 on kernel 2.4.21-243 I'm using a logitech quickcam, using the module quickcam, however this can be applied to any video devices i'm using (I have 3 in use, one usb webcam, one v4l device, one netcam). If the usb cam gets disconnected/re-connected, motion does not detect this, and when trying to connect to the motion stream you simply get connection refused. No more snapshots get generated. This is the same if the v4l device has a problem and won't serve any more images. The solution is to restart motion, which solves the problem. Is it possible for motion to detect a hang-up like this and either restart its own thread, or to die with an error (to syslog).

Environment

Motion version:	3.1.17
Libraries:	curl, xmlrpc, mysql
Server OS:	SuSE 9.0, kernel 2.4.21-243

-- AndyBrown - 03 Jan 2005

Answer

This is a known issue. Any contribution that addresses this is very welcome.

We are trying to improve it on the Network camera side with the new Netcam feature.

And someone wrote a patch that works with bttv devices but broke things with USB devices.

I have been thinking about adding a sort of watch dog into the main thread which does nothing but waiting for the children to terminate. I think we could implement it so that the parent thread kills its child when the child does not "pet the watchdog - some semaphore in the cnt structure - and restart it. This will close the videodevice and reopen it.

Answer

As a quick hack, I have an hourly cron job that kinda solves this problem (at least till more watchdog procedures go in the code). Script is as follows:

#!/bin/bash

#### Script checks for MOTION process, if not running then it runs. If it has too few processes, it restarts (cam disconnection)

## check first
pid=`ps axww |
         egrep '\['motion'\]|[ ]'/usr/local/bin/motion |
         awk '{ print $1 }'`


if [ "x$pid" = "x" ]; then
        /usr/local/bin/motion >/var/log/cam.log 2>&1 &
else
  if [ "x$1" != "x-q" ]; then
        pid_num=`/bin/ps ax | grep -v grep | grep /usr/local/bin/motion |wc -l`
        if test $pid_num -lt 6 ; then
                echo PROBLEM - less than 6 processes
                killall -9 motion
                sleep 5
                echo "Restarting motion....."
                /usr/local/bin/motion >/var/log/cam.log 2>&1 &
        fi
    echo motion running with pid $pid
  fi
fi

-- AndyBrown - 16 Apr 2005

Answer

OK, I'll answer my own question again, as it may be handy for somebody else out there. Since my USB cam hangs up quite frequently becuase of bad cabling (my bad!), I realised I can use the USB hotplug to restart motion. If your distro supports it: In /etc/hotplug/usb/ create file quickcam (thats the name of the kernel module) And in it i've put:

#!/bin/bash

/bin/killall -9 motion
sleep 1
/usr/local/bin/motion

I've also made a symlink: ln -s /etc/hotplug/usb/quickcam /etc/hotplug/usb/quickcam.usermap

That then restarts motion (with force in case the thread is stuck) to get around the USB cam hangup issue.

-- AndyBrown - 19 Jul 2005

Hi. My first post here. I have six DCS-900 network cameras on their own secluded subnet to a dedicated switch to my main server. Problem is, sometimes one camera can not be connected to. Restart of motion daemon fails because of the down camera. I too would like to see a watchdog like mechanism which would allow the remainder of the cameras to function even if one or more fail to respond or fail to connect. The real root problem here is why do they sometimes need to be power-cycled to get them out of their hung state. I know that this problem is not caused by or related to "motion", but must surely be a firmware problem within the DCS-900.

-- GregSwift - 29 Dec 2005

Which version of Motion are you running?

I actually implemented a fix for this situation for Network cameras only in Motion 3.2.4.

For USB cameras Motion will still fail to start but a missing USB camera is a situation you can handle normally. Netcams often are not available and Motion will handle this well now.

Eventually I will implement something similar for V4L devices but it was not as urgent as it was for Netcams.

-- KennethLavrsen - 29 Dec 2005