3 Axis cameras ,1 2100 and 2 210s = Crashes 210s
Question
I just upgraded to 3.2.4, because for some reason my old version wasn't loading more than 2 thread files, and I had just added a 2nd Axis 210 camera. Now a new problem has arisen. Whenever I fire up motion, the 210s are flooded with port 8- requests and in turn stop responding. I have to reboot them. Has anyone ran into this? The 2100 seems to work flawlessly, always has.
This is my config for the 210s
netcam_url http://[IP]/axis-cgi/jpg/image.cgi?resolution=640x480
target_dir /usr/cameras/lgh
jpeg_filename %F/%A-%I%p/%v-%M%S-%q
on_event_start /usr/local/bin/motion_notify/notify_motion_lgh.sh
framerate 8
Environment
Motion version: |
3.2.4 |
ffmpeg version: |
n/a |
Libraries: |
mysql |
Server OS: |
Debian Linux kernel 2.4.27-2-686 |
--
RossReed - 25 Jan 2006
Follow up
I don't understand what you mean with
flooded with port 8- requests .
Please could you attach your config files and write the output message of motion ?
To get a debug verbose messages from motion run motion with debug enable :
./motion -n -d 6
--
AngelCarpintero - 27 Jan 2006
Answer
Sorry about that, I meant port 80. Motion starts just fine, there is no error message. The problem is, once is starts, a netstat -an on the motion server shows that it has opened up many ( 20+ in number ) connections to the 2 AXIS 210 cameras, those cameras in turn crash from the flood of requests they get. See below for the 2 AXIS 210 thread files, and I have attached the motion.conf.
his is my config for the AXIS 210s
netcam_url http://[IP]/axis-cgi/jpg/image.cgi?resolution=640x480
target_dir /usr/cameras/lgh
jpeg_filename %F/%A-%I%p/%v-%M%S-%q
on_event_start /usr/local/bin/motion_notify/notify_motion_lgh.sh
framerate 8
This is what
motion -n -d 6
produces.
[0] Thread is from /etc/motion/trs_main.conf
[1] Thread started
[1] entered netcam_start()
[1] Camera thread starting...
[0] Thread is from /etc/motion/trs_mall.conf
[2] Thread started
[2] entered netcam_start()
[2] Camera thread starting...
[2] Received first header
[2] Received first header
[2] Received first header
[2] Received first header
[2] Received first header
[2] Non-streaming camera
[2] Received first header
[2] Content-length present
[2] expanding buffer from 0 to 4096 bytes
[2] expanding buffer from 4096 to 8192 bytes
[2] expanding buffer from 8192 to 12288 bytes
[2] expanding buffer from 12288 to 16384 bytes
[2] expanding buffer from 16384 to 20480 bytes
[2] expanding buffer from 20480 to 24576 bytes
[2] expanding buffer from 24576 to 28672 bytes
[2] expanding buffer from 28672 to 32768 bytes
[1] Received first header
[1] Received first header
[1] Received first header
[1] Non-streaming camera
[1] expanding buffer from 0 to 4096 bytes
[1] expanding buffer from 4096 to 8192 bytes
[2] Camera handler thread [3] started
[1] expanding buffer from 8192 to 12288 bytes
[1] expanding buffer from 12288 to 16384 bytes
[2] netcam_next called with no data in buffer
[2] vid_return_code 6
[1] expanding buffer from 16384 to 20480 bytes
[1] expanding buffer from 20480 to 24576 bytes
[1] expanding buffer from 24576 to 28672 bytes
[1] expanding buffer from 28672 to 32768 bytes
[1] expanding buffer from 32768 to 36864 bytes
[1] expanding buffer from 36864 to 40960 bytes
[1] expanding buffer from 40960 to 45056 bytes
[1] expanding buffer from 45056 to 49152 bytes
[1] netcam_next called with no data in buffer
[1] vid_return_code 6
[1] Camera handler thread [4] started
[2] Received first header
[2] Received first header
[2] Received first header
[2] Received first header
[2] Received first header
[2] Non-streaming camera
[2] Received first header
[2] Content-length present
[2] expanding buffer from 0 to 4096 bytes
[2] expanding buffer from 4096 to 8192 bytes
[2] expanding buffer from 8192 to 12288 bytes
[2] expanding buffer from 12288 to 16384 bytes
[2] expanding buffer from 16384 to 20480 bytes
[2] expanding buffer from 20480 to 24576 bytes
[2] expanding buffer from 24576 to 28672 bytes
[2] expanding buffer from 28672 to 32768 bytes
[2] Calculated frame time 117258.500000
[1] Received first header
[1] Received first header
[1] Received first header
[1] Non-streaming camera
[1] expanding buffer from 0 to 4096 bytes
[1] expanding buffer from 4096 to 8192 bytes
[1] expanding buffer from 8192 to 12288 bytes
[1] expanding buffer from 12288 to 16384 bytes
[1] expanding buffer from 16384 to 20480 bytes
[1] expanding buffer from 20480 to 24576 bytes
[1] expanding buffer from 24576 to 28672 bytes
[1] expanding buffer from 28672 to 32768 bytes
[1] expanding buffer from 32768 to 36864 bytes
[1] expanding buffer from 36864 to 40960 bytes
[1] expanding buffer from 40960 to 45056 bytes
[1] expanding buffer from 45056 to 49152 bytes
[1] Calculated frame time 124511.898438
[2] processing jpeg image - content length 29364
[1] processing jpeg image - content length 0
[2] Received first header
[2] Received first header
[2] Received first header
[2] Received first header
[2] Received first header
[2] Non-streaming camera
[2] Received first header
[2] Content-length present
[2] expanding buffer from 0 to 4096 bytes
[2] expanding buffer from 4096 to 8192 bytes
[2] expanding buffer from 8192 to 12288 bytes
[2] expanding buffer from 12288 to 16384 bytes
[2] expanding buffer from 16384 to 20480 bytes
[2] expanding buffer from 20480 to 24576 bytes
[2] expanding buffer from 24576 to 28672 bytes
[2] expanding buffer from 28672 to 32768 bytes
[2] Calculated frame time 126357.351562
Frame rate of 8 at high resolution and as single images. Sounds like you are fetching images faster than the camera can deliver.
--
KennethLavrsen - 29 Jan 2006
Answer
Kenneth, I have put the framerate at 2. After 45 seconds there are now 109 port 80 connections to the AXIS 210. Most in the TIME_WAIT state. The camera hasn't crashed yet. I feel it will. BUT on the other hand the AXIS 2100 only has 2 open connections, and never gets above that? I am totally confused.
Answer
It seems I have fixed the problem. The only way to stop the flood of connections to the AXIS 210s was to go to the camera itself and limit the Bandwith to 100kilobits/s. Anyone else seen this behavior?