Streaming - Live is fine, Events do not work

[endeitz]

I am using Firefox 1.0Pre to manage ZM. When I bring up a monitor, the video streams at 5 fps, just as I have it specified. However, after an event is recorded, if I click the event number, it loads after some time with a still frame (the first frame of the event, I think) but does not stream the event.

If I click "replay", nothing happens in the view, although the browser claims it is "transferring data." Meanwhile, a two zms processes are running, one which is actively using the CPU, the other is not.

Does anyone have a clue as to how I can track down this issue? The logs don't have any mention of zms, except to say that it has started occasionally. I do get a "zma-m3 WAR approaching buffer overrun" message in /var/log/messages, but that's about it.

I can create mpegs from the events, and view those, but I would prefer to just stream the events via jpeg through my browser.

[zoneminder]

It's a bit of a long shot but try changing ZMS_PATH to use nph-zms instead of just zms?

Otherwise try putting cambozola on your server and forcing ZM to use that. Wther that works or not might help figure out where to look next.

Phil,

[endeitz]

As it turns out, the problem was that I had my pre-event buffer set to the same as my ring buffer (both 10, I have shared memory issues that I'm working on). Once I was able to increase my ring buffer to 20, the problem went away.

Thanks for the great software and support!

Ed.

[MTurner]

Ed,

Thanks for posting this and the fix. I had the same problem and it fixed it.

Thanks,
Mark

[candlerb]

As it turns out, the problem was that I had my pre-event buffer set to the same as my ring buffer (both 10, I have shared memory issues that I'm working on). Once I was able to increase my ring buffer to 20, the problem went away.

I had the same problem here - thanks for the fix. It took me a while to realise that the setting is called "Image buffer size (frames)", as it doesn't actually say "ring buffer"

I had also reduced my image buffer size to 10 due to memory problems (only 128MB machine and I was trying out 640x480 resolution). Perhaps zm should refuse to let you set image buffer size <= pre-event buffer size.

I'm using mocord, and before the fix, frames clearly were being saved - I could skip through frames one by one by clicking on 'alarm frames' and selecting an individual frame - just not replay an event as a stream.

After increasing image the buffer size to 20, the previously-saved events still can't be replayed, but newly-recorded ones are OK. It would be nice if there was a way to fixup the saved data, but it's only one day's worth

Regards,

Brian.

[jameswilson]

the image buffers only effect the capture and are nothing to do with playback. I would assume that because you cant playback, that because of the error noting was actually recorded

James

[candlerb]

the image buffers only effect the capture and are nothing to do with playback. I would assume that because you cant playback, that because of the error noting was actually recorded

OK I think I can explain this. In my older events, if I show the list of captured frames, I see that the first frame or two is out of sequence with regard to timestamps, so they aren't monotonically increasing:

Code: Select all

Event 12        Close
Frame Id        Alarm Frame     Time Stamp      Time Delta      Score
1               No              17:00:00        0.00            0
2               No              17:00:00        0.21            0
3               No              16:59:58        -1.62           0
4               No              16:59:58        -1.42           0
5               No              16:59:58        -1.22           0
6               No              16:59:59        -1.01           0
7               No              16:59:59        -0.81           0
8               No              16:59:59        -0.61           0
... etc

When I click 'replay' I see the first two frames, and then it stops.

So if I could either delete the first two frames, or if replay were able to cope with timestamps out of order, then the problem would be solved.

[jameswilson]

i doubt the images are there, if you browse your event folder can you see the images then, i thing the images are grabbed form the data in the db, so it can handle events out of order. Like i said i would expect when you open the relevant folder there to be only 2 valid images there

James

[candlerb]

i doubt the images are there

The images are definitely there - I can view them frame by frame, by clicking on the individually numbered frames, and by using forward/next. Alarm frames later in the event show my "intruder" outlined in red too

I just can't replay the whole event as a stream. I imagine the out-of-sequence timestamp is confusing the replay. My guess is this is due to the mechanism which plays the frames back at the right speed.

Note that I have my camera set to 5fps and configured 'frame skip' to 4. This means that the start of an event shows 5fps, and thereafter I get 1fps, except when movement is detected in which case it goes back to 5fps. The real-time display handles this perfectly.

This means that somewhere, something is waiting until the time of the next frame comes along to trigger the display of the next frame. I can imagine that an out-of-order timestamp would confuse this process, and it would wait indefinitely for a time which never occurs.

Regards,

Brian.

[jameswilson]

oh i see this is new to me then, Has your out of order issue stopped with the buffer changes you made or are they still out of order. I suppose you could manually edit the db to get the images back in order. Also im fairly sure zm4ms would handle this as it doesnt use any time info at the moment in playback and uses the evenbt id for sorting, so that should playback your images in the correct order. (But that really is theory as i have never had out of order images to test against)

James

[candlerb]

OK I found the problem. Sending of frames at the right rate is done by usleep(), which takes an unsigned int parameter. If it gets a negative value it will sleep for a very long time indeed

Here's a fix:

Code: Select all

--- src/zm_event.cpp.orig       2006-01-11 10:18:11.000000000 +0000
+++ src/zm_event.cpp    2006-01-11 10:19:38.000000000 +0000
@@ -471,7 +471,10 @@
                        if ( (frame_mod == 1) || (((id-1)%frame_mod) == 0) )
                        {
                                double this_delta = last_db_delta+(((id-last_db_id)*(db_delta-last_db_delta))/(db_id-last_db_id));
-                               delta_us = (unsigned int)((this_delta-last_delta) * 1000000);
+                               if (this_delta > last_delta)
+                                       delta_us = (unsigned int)((this_delta-last_delta) * 1000000);
+                               else
+                                       delta_us = 0;
                                if ( rate != ZM_RATE_SCALE )
                                        delta_us = (delta_us*ZM_RATE_SCALE)/rate;
                                Debug( 2, ( "I:%d, DI:%d, LDBI:%d, DD:%lf, LD:%lf, LDBD:%lf, TD:%lf, DU:%d", id, db_id, last_db_id, db_delta, last_delta, last_db_delta, this_delta, delta_us ));

In normal operation the delta between frame timestamps will always be positive, but this lets zm cope with the case where it isn't.

Regards,

Brian.

[jameswilson]

oh i see well done

[zoneminder]

I will add this fix to the next release, thanks for looking into it. I think the reason for the sequence issue is that because the ring buffer is so small that when the event comes to be saved (after x frames) the early frames have already been overwritten, so they aren't in fact the first frames at all, but the 11 and 12 for instance. So even if you do stream the event it will look a bit odd and appear to be out of sequence.

One thing to be aware of if you are changing the buffer or image sizes (especially when making them bigger) is to close down any streams before you make the change and do a full restart of ZM afterwards. If anything is attached to the shared memory then it cannot be resized upwards to may appear to give the impression that you don't have enough shared memory space in total, when in reality it is just that something is hanging onto it and locking it.

[ekiboy69]

This thread was very interesting. It just might be that my faulty mainboard was not the only thing to blame in this issue:

http://www.zoneminder.com/forums/viewtopic.php?t=3443

I had similar experiences last winter with another machine. I will dig more into the ring buffer mythology and see how it helps.