Hi,
Sorry to see you're having so much trouble.
sgn wrote:alas, no cambozola-streaming from the server. Just the copyright-message.
After a few seconds another message is printed over the copyright text, "Failed to connect", or something. Live stills fail as well, seems to a problem with zms.
There are a couple things worth trying here to isolate where the problem lies. I would get a terminal session up on your box, or another box on the network and do
Code: Select all
wget -s -S 'http://IP/cgi-bin/zms?mode=jpeg&monitor=2&scale=100&maxfps=15' > wget.log
or whatever path is valid for you. If that works then you know your web server is set up correctly. Then try using Mozilla or another browser that supports native streaming to access your streams without Cambozola (you may have to change your config if you've made it use it unconditionally). If the mode=jpeg&monitor=2&scale=100&maxfps=15 wget doesn't work then try using zms directly on the command line to make sure it has been compiled and installed correctly. So do something like
Code: Select all
export QUERY_STRING=mode=jpeg&monitor=2&scale=100&maxfps=15
<pathto>/zms > zms.log
where you should see some output, though most will be binary crud.
sgn wrote:Does apache need any cgi-config for zms to work?
I'm no apache expert so I don't know the details. It obviously needs to know where to look for cgi programs but I've never had to change that from the default settings so far.
sgn wrote:And should a 15 (640x480xYUV422@0.5 FPS) camera system consume 1GB RAM? With all cameras in record mode, that is?
The amount of memory, shared memory that is, used depends on the size and colour depth of your images multiplied by the buffer size you have set. So unless you've changed it in your case it will be 15 x 640 x 480 x 3 x 100. I think that comes to around 1.3Gb. If you aren't doing motion detection then you can easily set the ring buffer size to 25 or so instead of 100 which will knock your memory requirements down by 75%. You should restart your system after doing this to be on the safe side.
sgn wrote:Seems to be a memory leak somewhere, the amount of free memory gets lower and lower.
As far as I know there are no leaks. There are various threads around as to why the vagaries of shared memory appear to indicate there is a leak but this is because shared memory is not accounted for until accessed and as the slots in the ring buffer gradually get poked the total apears to go up, until it reaches a high water mark which is roughly what the calculated figure indicates it should be.
sgn wrote:Also, how can I prevent zm from stashing shit in syslog and friends? I want to prevent a self-made DoS.[/quote"]
You can compile the applications to output less or no syslog info. Search for dbg_level for instructions on how to do this. You can also logrotate the other logs to keep them small. They don't get very big anyway.
sgn wrote:Video generation also fails, ffmpeg reports "Incorrect framerate" i zmvideo.log. ZM tried to start fgfmpeg with -r 0.0
The rate it uses is calculated from the frame rate that an event was captured with. For some reason here it has calculated it as zero fps, without being able to see the frame data I can't say why. Also it's very difficult to give generic parameters that work for high and low frame rates so you will probably need to manually experiment with ffmpeg to see what works best for you and then add those parameters to the ZM config.
Hope that helps a bit.
Phil,