BUG: Connexion to non-streaming netcam lost after some time

Hi

I work with an camera outputting only still JPG pictures. For a reason that I ignore, that's their version of "MJPEG".

So I use a framerate of 1 with an url like: netcam_url http://110.10.10.244/jpg/image.jpg

Motion works very well with it at first, but, after some time, completely loses the connection, and never gets it back.

I suspect this camera of being able to send invalid (or empty / 0 byte) images at random times. Could this be a cause ?

I will investigate further with more debug, but may be this is something that has already been corrected in SVN for instance ?

I use the debian squeeze package available via APT (3.2.12).

Relevant part of the logfile
[... normal image capture ...]
[2] Received first header ('')
[2] Calculated frame time 600622.625000
[2] netcam_init_jpeg: ***new pic delay successful***
[2] netcam_read_html_jpeg disconnecting netcam since keep-alive not set.
[2] netcam_connect, disconnecting netcam since keep-alive not set.
[2] netcam_connect with no keepalive, new socket created fd 6
[2] netcam_init_jpeg: jpeg_error 0
[2] netcam_image_conv: jpeg_error 0
[0] DEBUG-2 threads_running 3 motion_threads_running 2 , finish 0
[2] netcam_proc_jpeg: processing jpeg image - content length 0
[2] Received first header ('HTTP/1.0 200 OK')
[2] Received first header ('Date: Sat, 24 Jul 2010 21:04:35 GMT')
[2] Received first header ('Server: Boa/0.94.14rc21')
[2] Received first header ('Accept-Ranges: bytes')
[2] Received first header ('Connection: close')
[2] Found Conn:close header ('Connection: close')
[2] Received first header ('Content-type: image/jpeg')
[2] Non-streaming camera (keep-alive not set)
[2] Received first header ('')
[2] Calculated frame time 600015.375000
[2] netcam_init_jpeg: ***new pic delay successful***
[2] netcam_read_html_jpeg disconnecting netcam since keep-alive not set.
[2] netcam_connect, disconnecting netcam since keep-alive not set.
[2] netcam_connect with no keepalive, new socket created fd 6
[2] netcam_init_jpeg: jpeg_error 0
[2] netcam_image_conv: jpeg_error 0
[2] Received first header ('HTTP/1.0 200 OK')
[2] Received first header ('Date: Sat, 24 Jul 2010 20:04:36 GMT')
[2] Received first header ('Server: Boa/0.94.14rc21')
[2] Received first header ('Accept-Ranges: bytes')
[2] Received first header ('Connection: close')
[2] Found Conn:close header ('Connection: close')
[2] Received first header ('Content-type: image/jpeg')
[2] Non-streaming camera (keep-alive not set)
[2] Received first header ('')
[2] Calculated frame time 565898.062500
[2] netcam_read_html_jpeg disconnecting netcam since keep-alive not set.
[2] netcam_next called with no data in buffer
[2] vid_return_code 6
[0] DEBUG-2 threads_running 3 motion_threads_running 2 , finish 0
[2] netcam_next called with no data in buffer
[2] vid_return_code 6
[2] netcam_next called with no data in buffer
[2] vid_return_code 6
[2] netcam_next called with no data in buffer
[2] vid_return_code 6
[... gray frame with connexion lost, this message loops...]

Environment

Motion version:	3.2.12
ffmpeg version:
Shared libraries:	ffmpeg, mysql, postgresql
Server OS:	Debian Squeeze

-- F00tyNyupi - 25 Jul 2010

Follow up

I think I found a solution:

In http://www.lavrsen.dk/svn/motion/branches/3.2/netcam.c , in netcam_next, just invert the two following if () { }.

In fact, in my case, no data is in the buffer. But, if there's no data, the capture thread won't be signalled and then won't capture anything, which leads to a loop.

What do you think ?

This has been stable for a few hours, but please review carefully before applying to the 3.2 branch.

This corrects my situation (non-streaming camera, with sometimes an empty frame (0 bytes)).

   if (!netcam->latest->used) {
        if (debug_level) 
            motion_log(LOG_INFO, 0, "netcam_next called with no data in buffer");
        
        return NETCAM_NOTHING_NEW_ERROR;
    }

    /*
     * If we are controlling a non-streaming camera, we synchronize the
     * motion main-loop with the camera-handling thread through a signal,
     * together with a flag to say "start your next capture".
     */
    if (!netcam->caps.streaming) {
        pthread_mutex_lock(&netcam->mutex);
        netcam->start_capture = 1;
        pthread_cond_signal(&netcam->cap_cond);
        pthread_mutex_unlock(&netcam->mutex);
    }

-- F00tyNyupi - 28 Jul 2010

Fix record