@ Bob: Thank you, that's a lot to digest, part of it may be too much of an investment for me but some seem feasible.
When you say "run out of disk space" you mean really your disk is full or your writing speeds doesn't match the arrival of images, I'm confused by all the VNC/RAID0 part.
As for the 1fps, it's an option in the motion.conf:
# Minimum time in seconds between capturing picture frames from the camera.
# Default: 0 = disabled - the capture rate is given by the camera framerate.
# This option is used when you want to capture images at a rate lower than 2 per second.
A few thoughts.
- One of my boxes (P4D 3400 SuSE 11.4) runs 3 USB cameras at 5FPS with mjpeg-streamer. It has 4 motion threads though (the 4th being a remote mjpeg-streamer. The only time I get zero length files is if I run out of disk space. Than can happen on a windy day (when the trees and clouds move a lot) Since this runs on a single USB controller the hardware loading at the higher FPS wouldn't be far from yours. The same box is also a remote VNC/XFCE4 thing, so it gets a caning in general use. (My image writes are to a RAID0 NFS store and I don't create mpg's on the fly)
- In terms of isolating the fault it might be worth running the mjpeg-streamer in test picture mode, add more instances and so on. If you think it might be motion related you'd have to find a way to make the test picture change to force a movement detect.
- You can also have mjpeg-streamer write files directly. ie not be polled by motion. This will help with debugging hardware etc problems and give you a guide as to what part of the app software may be the culprit.
- I'd expect that 8 mjpeg-streamer instances make for a asynchronous load on the USB systems. What I am getting at here is the hang point may correspond to a max bus utilisation event. Mind you I have no idea really how to make it all synchronous or round robin apart from modifying/writing code.
- It may be worth looking into the difference between stream and snapshot netcam modes. My thinking on this is if motion is being overrun, "stream" has a higher probability of causing a failure than "snapshot". I think too that snapshot mode may help link speed and latency issues with over the wire. (My post on the grey blind issue for example)
- I assume you are checking syslog? Not sure about Ubuntu but one of the console screens on SuSE is set to see something like a continuous tail of dmesg output. The plus here is that if it doesn't get to write the log to hard disk it may still be visible on the screen.
- I note that mjpeg-streamer source code has a debugging mode. Have never looked into its use though.
How do you get/use 1FPS BTW? The minimum frame rate in motion is 2FPS. Is that ignored for a netcam stream?
On 30/10/12 01:27, corentin barbu wrote:
I'm using motion with mjpeg-streamer to record snapshots + motion pictures from 8 cameras on usb ports of a same computer (ubuntu 12.04 core 2 duo, 4Gb). It freezes completely the computer every once in a while (no X interaction possible, no ssh connection possible). It's quite cleat this happens only when handling the video recording system.
Using atop did not allow me to see any processus becoming wild. Memtest was ok with 7 runs. The only problem I see is that images saved by motion at the time of the freeze (last 30s, at 1fps) are of size 0, impossible to read.
Has anybody experimented this kind of problem?
Do you have ideas to investigate? A replacement of mjpeg-streamer to stream efficiently to motion in the same computer to test if the problems comes from it?
The Windows 8 Center - In partnership with Sourceforge
Your idea - your app - 30 days.
Motion-user mailing list