BUG: IP cam connection lost and never reconnect

Since I have changed some config in my wireless setting, my IPcam (Dlink 2100+) sometimes disconnect and reconnect to the wireless network. Motion detects the camera is not responding and put the gray screen connection lost.

After that, it seldoms reconnect to the ipcam.

I have experienced it and then I had the idea to use a wget on the image url. It can retrieve the image. Pinging the ipcam also works.

I was using 3.2.6 , then i saw this was fixed in 3.2.7, so I installed the new version with the ubuntu drapper drake debian package, but the problem is still there.

Linux is ubuntu 6 LTS, motion 3.2.6 was installed with ubuntu then migrated with the package found in the download section.(motion_3.2.7-0.ubuntu.dapper_i386.deb) From the console output, it seems it may the reconnection doesn't happen anymore for some reasons.

lbaltha@lbaltha-desktop:~/motion3.2.7$ sudo motion -n
[0] Processing thread 0 - config file /etc/motion/motion.conf
[0] Unknown config option "minimum_gap"
[0] Processing config file /etc/motion/cam_papa.conf
[0] Unknown config option "minimum_gap"
[0] Processing config file /etc/motion/cam_ip.conf
[0] Unknown config option "minimum_gap"
[0] Thread 1 is from /etc/motion/cam_papa.conf
[0] Thread 2 is from /etc/motion/cam_ip.conf
[1] Thread started
[2] Thread started
[0] motion-httpd/3.2.7 running, accepting connections
[0] motion-httpd: waiting for data on port TCP 8080
[1] Started stream webcam server in port 8081
[2] Started stream webcam server in port 8085
[2] timeout on connect()
[2] re-opening camera (non-streaming)
[2] camera re-connected

*****CAMERA STILL WORKS HERE!

[2] Video signal lost - Adding grey image


***Never reconnects anymore

[0] httpd - Finishing: Success
[0] httpd Closing
[1] Thread exiting
[2] netcam camera handler: finish set, exiting

Environment

Motion version:	3.2.7
ffmpeg version:
Shared libraries:	ffmpeg, mysql, postgresql
Server OS:	ubuntu drapper drake 2.6.15-27-386

-- LaurentBalthasar - 18 Dec 2006

Follow up

Please upgrade to 3.2.9 and try to reproduce it again.

Thanks!

-- AngelCarpintero - 19 Nov 2007

---

Same problem here. No reconnect while wireless-camera is available again. I have to restart motion completely to connect to the camera.

Version: 3.2.9 -> downloaded and installed feb. 2008

-- DavidS - 13 Feb 2008

---

Please you should try to run motion in debug mode but don't use 3.2.9 because bug won't be fixed there , get motion-3.2.10 from svn :

mkdir motion
cd motion
svn co http://www.lavrsen.dk/svn/motion/branches/3.2.10/ .

./configure ; make ; make install 

And run /usr/local/bin/motion -n -d 7

-- AngelCarpintero - 20 Feb 2008

---

I have a RaspberryPi with 3.2.12 and 3 D-Link 930Ls. Recently they all started to get disconnects. Motion never reconnects. I have to restart motion. I am not sure why this started happening. The cameras all respond quickly. I have power cycled everything: routers, cameras, motion server. One camera is right next to the WiFi access point with 100% strength.

So this problem still exists. -d 5 log below. The thread appears to get stuck and never tries to reconnect and get a new picture. When exit is called, it does not respond.

Also, I cannot get the keep-alive config setting to work.

:
[2] Non-streaming camera (keep-alive not set)
[2] Content-length present
[2] Non-streaming camera (keep-alive not set)
[2] Content-length present
[2] Non-streaming camera (keep-alive not set)
[2] Content-length present
[2] netcam_init_jpeg: no new pic, no signal rcvd
[2] netcam_init_jpeg: no new pic, no signal rcvd
[2] netcam_init_jpeg: no new pic, no signal rcvd
[2] netcam_init_jpeg: no new pic, no signal rcvd
[2] netcam_init_jpeg: no new pic, no signal rcvd
[2] netcam_init_jpeg: no new pic, no signal rcvd
[2] netcam_init_jpeg: no new pic, no signal rcvd
[2] netcam_init_jpeg: no new pic, no signal rcvd
[2] netcam_init_jpeg: no new pic, no signal rcvd
[2] netcam_init_jpeg: no new pic, no signal rcvd
[2] netcam_init_jpeg: no new pic, no signal rcvd
[2] netcam_init_jpeg: no new pic, no signal rcvd
[2] netcam_init_jpeg: no new pic, no signal rcvd
[2] Thread exiting
[2] Calling vid_close() from motion_cleanup
[2] vid_close: calling netcam_cleanup
[0] httpd - Finishing
[0] httpd Closing
[0] httpd thread exit
[2] No response from camera handler - it must have already died
[0] Motion terminating

Here is a restart of a stuck thread. Looks like the Camera handler is getting stuck and the watchdog timeout is not detecting it.

[3] netcam_init_jpeg: no new pic, no signal rcvd
[3] netcam_proc_jpeg: ret 6
[3] netcam_proc_jpeg: processing jpeg image - content length 26602
[0] httpd restart thread 3
[0] httpd - Read from client
[3] netcam_init_jpeg: no new pic, no signal rcvd
[3] netcam_proc_jpeg: ret 6
[3] Thread exiting
[3] Calling vid_close() from motion_cleanup
[3] vid_close: calling netcam_cleanup
[3] No response from camera handler - it must have already died
[0] Motion thread 3 restart
[3] Thread 3 started
[3] entered netcam_start()
[3] Camera thread starting...
[3] netcam_start: Netcam_http parameter 'keep-alive' converts to flags: HTTP1.0:0 HTTP1.1: 0 Keep-Alive OFF.
[3] netcam_start: now calling netcam_setup_html()
[3] netcam_setup_html: Netcam has flags: HTTP1.0: 0 HTTP1.1: 0 Keep-Alive OFF.
[3] Camera connect string is ''GET /image/jpeg.cgi HTTP/1.0
[3] End of camera connect string.
[3] netcam_setup_html: about to try to connect, time #0
[3] netcam_connect, disconnecting netcam since keep-alive not set.
[3] netcam_connect with no keepalive, new socket created fd 6
[3] Received first header ('HTTP/1.0 200 OK')
[3] Received first header ('Server: alphapd')
[3] Received first header ('Date: Tue Jun 28 14:10:39 2016')
[3] Received first header ('Pragma: no-cache')
[3] Received first header ('Cache-Control: no-cache')
[3] Received first header ('Content-type: image/jpeg')
[3] Non-streaming camera (keep-alive not set)
[3] Received first header ('Content-length: 28786')
[3] Content-length present
[3] Received first header ('')
[3] netcam_setup_html: connected, going on to read image.
[3] expanding buffer from 0 to 4096 bytes
[3] expanding buffer from 4096 to 8192 bytes
[3] expanding buffer from 8192 to 12288 bytes
[3] expanding buffer from 12288 to 16384 bytes
[3] expanding buffer from 16384 to 20480 bytes
[3] expanding buffer from 20480 to 24576 bytes
[3] expanding buffer from 24576 to 28672 bytes
[3] expanding buffer from 28672 to 32768 bytes
[3] netcam_read_html_jpeg disconnecting netcam since keep-alive not set.
[3] netcam_get_dimensions: JFIF_marker NOT PRESENT ret 0
[3] Resizing pre_capture buffer to 1 items
[3] Camera handler thread [5]  started
[3] netcam_connect, disconnecting netcam since keep-alive not set.
[3] netcam_connect with no keepalive, new socket created fd 6
[3] netcam_next called with no data in buffer
[3] Received first header ('HTTP/1.0 200 OK')
[3] Received first header ('Server: alphapd')
[3] Received first header ('Date: Tue Jun 28 14:10:40 2016')
[3] Received first header ('Pragma: no-cache')
[3] Received first header ('Cache-Control: no-cache')
[3] Received first header ('Content-type: image/jpeg')
[3] Non-streaming camera (keep-alive not set)
[3] Received first header ('Content-length: 28681')
[3] Content-length present
[3] Received first header ('')
[3] expanding buffer from 0 to 4096 bytes
[3] expanding buffer from 4096 to 8192 bytes
[3] expanding buffer from 8192 to 12288 bytes
[3] expanding buffer from 12288 to 16384 bytes
[3] expanding buffer from 16384 to 20480 bytes
[3] expanding buffer from 20480 to 24576 bytes
[3] expanding buffer from 24576 to 28672 bytes
[3] expanding buffer from 28672 to 32768 bytes
[3] Calculated frame time 458164.093750
[3] netcam_read_html_jpeg disconnecting netcam since keep-alive not set.
[3] Resizing pre_capture buffer to 3 items
[3] netcam_connect, disconnecting netcam since keep-alive not set.
[3] netcam_proc_jpeg: processing jpeg image - content length 28681
[3] netcam_connect with no keepalive, new socket created fd 5
[3] Video signal re-acquired
[3] Received first header ('HTTP/1.0 200 OK')
[3] Received first header ('Server: alphapd')
[3] Received first header ('Date: Tue Jun 28 14:10:40 2016')
[3] Received first header ('Pragma: no-cache')
[3] Received first header ('Cache-Control: no-cache')
[3] Received first header ('Content-type: image/jpeg')
[3] Non-streaming camera (keep-alive not set)
[3] Received first header ('Content-length: 28773')
[3] Content-length present
[3] Received first header ('')
[3] expanding buffer from 0 to 4096 bytes
[3] expanding buffer from 4096 to 8192 bytes
[3] expanding buffer from 8192 to 12288 bytes
[3] expanding buffer from 12288 to 16384 bytes
[3] expanding buffer from 16384 to 20480 bytes
[3] expanding buffer from 20480 to 24576 bytes
[3] expanding buffer from 24576 to 28672 bytes
[3] expanding buffer from 28672 to 32768 bytes
[3] Calculated frame time 466005.687500
[3] netcam_read_html_jpeg disconnecting netcam since keep-alive not set.
[3] netcam_proc_jpeg: processing jpeg image - content length 28773
[3] netcam_connect, disconnecting netcam since keep-alive not set.
[3] netcam_connect with no keepalive, new socket created fd 5
[3] Received first header ('HTTP/1.0 200 OK')
[3] Received first header ('Server: alphapd')
[3] Received first header ('Date: Tue Jun 28 14:10:41 2016')
[3] Received first header ('Pragma: no-cache')
[3] Received first header ('Cache-Control: no-cache')
[3] Received first header ('Content-type: image/jpeg')
[3] Non-streaming camera (keep-alive not set)
[3] Received first header ('Content-length: 28681')
[3] Content-length present
[3] Received first header ('')
[3] Calculated frame time 474250.906250
[3] netcam_read_html_jpeg disconnecting netcam since keep-alive not set.
[3] netcam_connect, disconnecting netcam since keep-alive not set.

-- PhilipWalden - 28 Jun 2016

---

As I have monitored my situation, I believe there might have been a RaspberryPi upgrade that moved me to version 3.2.12, which has caused the sudden appearance of the camera drop out problems.

I have discovered that the framerate was set to 100, not 2 as I recall previously. Re-setting framerate back to 2, has improved the situation, but cameras keep dropping out throughout the day on a less frequent basis as determined by monitoring the log a -d 5 level looking for "netcam_init_jpeg: no new pic" records. When I tried a -d 9 level of logging, looking for a deeper understanding, the drop outs stopped! There were occasional "netcam_init_jpeg: no new pic" records, but they never blossomed into permanent drop outs. So I suspect there is a timing problem in the camera handler threads, wherein they can go into a permanent loop and not recover if the netcam is queried too quickly.

As a temporary work-around I am changing minimum_frame_time settings to 2, which seems to have the same effect as -d 9 slowing down the processing rate. This has helped, but during actual motion events, I am losing the 2 fps resolution I used to get. I still get a few camera drop out every hour at 0.5 FPS.

So, it really does appear that there is a timing or race condition in the camera handler thread that can put it into an unrecoverable loop where it will stop requesting new images and just dish up "no new pic" errors. Maybe the camera thread just dies and its respective motion thread thinks there is "no new pic".

The interesting thing is that the camera with the highest quality WiFI connection appears to have greatest chance of dropping out.

-- PhilipWalden - 29 Jun 2016

Answer