Time jumps in recorded frames

[SyRenity]

Hi.

As some may recall, I increased the default pre/post buffers to 120 frames in order to reduce "disappearing" people effect (where people dis/appeared into/from nowhere).


Now, having a buffer of 120, pre of 119, and post of 120, I noticed in records an effect of time jump for random frames, where the recording is briefly skipping to time in future (couple of seconds) and then goes back, replaying in progress the time jump.

Meaning, if I have the current time say at 12:30:20, I might see a frame of 12:30:24, and then the recording is back to 12:30:20. The 12:30:24 frame will be replayed again when reached during normal playback.


I'm calling them "ghost frames" because you are see the people/objects briefly on some position, and then they back to their normal movement, getting eventually into the position.

To summarize it, the event starts, runs and ends normally, and the ghost frame can be anywhere inside it.


Any idea if this is a known bug, and if it was fixed in the latest version?

[jameswilson]

Syrenity
I know you didnt agree with me before but you need some room between total buffers and pre alarm. 1 frame isnt enough. If you run at 120 total and say 90 pre that will give you system a 30 images of buffer. It currently has only 1.
Im not sure it related but it isnt best.

Anyway back to the problem

Are you using modect, or mocord?

[SyRenity]

Hi James.

Thanks for your opinion, but here Phil said it's perfectly safe to set the pre-event number to buffer size - alarms frames:

http://www.zoneminder.com/forums/viewto ... highlight=

Without checking I can't be exactly sure but until I can confirm I would set it to image buffer size - alarm frame count. So in most cases image buffer size -1 just to be on the safe side. It partly also depends on how loaded your machine is as if the analysis is running a long way behind the capture then you may still hit overrung scenarios."

So if I have the buffer size set to 120, and the default 1 alarm frame, shouldn't it be ok to set the pre-alarm to 119?

Perhaps I simply don't understand how the whole thing works (shouldn't the pre-alarm take the data from the buffer, and work fine if it has enough buffer?)...

I'm using modetect btw.

[zoneminder]

Just because I said something doesn't necesarily make it true

I think in your case it would be worth trying to add a bit more of a 'buffer' between the two values and seeing if the problem goes away. In normal use the ring buffer should function ok but if anything causes any of the processes to temporarily hang then you may get wraparounds but I would expect to see warnings/errors in your logs if this happens.

[SyRenity]

Hi Phil.

Well, it's good to know that even you not perfect .

Since my first posting, I reduced the pre-event to 100, but it still has ghost frames here and there.

What's the most strange thing, is that it doesn't seems as being wrapped around. I mean, in such case it would be displaying:
1) ghost frame
2) first frame and onwards
3) until the ghost frame again

But in my case it's rather:
1) first frame and some frames onwards
2) ghost frame
3) onwards normally
4) until the ghost frame again

Could it be some issue in the capturing daemon, incorrectly placing the frames sometimes? Were there any fixes done in this area, in the latest versions?

[zoneminder]

There were no changes in recent version in that area. Are you able to dump out the contents of the Frames table for an event with a ghost in (and highlight the offending frames if not obvious). When I say dump, if you can get them into something readable and post it here it would be helpful.

[SyRenity]

I will post it, thanks Phil for your help.

By the way, perhaps you can resolve the long-lasting question I have, and tell me, how blend % actually influences the detection mechanism?

Also, what's better for slow moving objects vs. fast moving - high % (like 50) or low % (like the default 7)?