Motion - Bug Report 2010x 07x 25x 073203

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

Hi smile

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

BugReportForm edit

TopicTitle Connexion to non-streaming netcam lost after some time
BugStatus Resolved
AssignedBugTo
SubmittedBy F00tyNyupi
Topic revision: r2 - 28 Jul 2010, F00tyNyupi
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Please do not email Kenneth for support questions (read why). Use the Support Requests page or join the Mailing List.
This website only use harmless session cookies. See Cookie Policy for details. By using this website you accept the use of these cookies.