ZoneMinder Forums

the reason why this issue happens with 1.36.35 but not with 1.36.33 is according to the analysis of the videostore code and the shared logs that the way non-monotonic dts values are being identified was changed as part of 1.36.34 or 35. anyway, it seems that no one else has a configuration/setup ...

Still doesn't explain why it doesn't happen using log level 3. couldn't non-monotonic dts values be caused by heavy network traffic e.g. if packages are dropped? this might happen with a higher probability when debugging is off because the system will then probably run more performant and hence ...

iconnor wrote: ↑Fri Nov 29, 2024 4:24 pm I think we have definitely pinpointed the issue. I don't want to revert as that fix was there for a reason. But I really think the calculated duration is wrong so I can look into that.

appreciate it - thank you so much

I think the duration calculations are completely bogus. We are using the duration from the frame we are stuffing into the codec but that isn't necessarily the frame we get out of the codec. the trouble in the context of this thread seems to be that with 1.36.35 the calculated duration is also used ...

I think the duration calculations are completely bogus. We are using the duration from the frame we are stuffing into the codec but that isn't necessarily the frame we get out of the codec. you are probably referring to this change which is referred to in the release notes of 1.36.34 as follows ...

That -1 does look sketchy, but I'm not convinced. I don't see why turning on debugging would change the behaviour. I need a debug level 3 log. sure, no problem and thank you very much for your time/effort to get this sorted out :D. i just ran 1.36.35 with debug level 3 and shortly after that with ...

setting last_dts value to -1 and comparing it later on with a variable which was declared to be unsigned?

please ignore this one - i was overlooking the cast to int64_t of this variable. any other/better suggestion?

How do your videos look? Good or starting off with grey and smearing and slowly coming in? the video i just generated with 1.36.35 looks fine to me even though the zmc log was flooded with "non increasing dts" WAR messages during the whole recording period along with one single "non increasing dts ...

also, if the creation of jpges is disabled then (and only then) the following error is raised 11/20/24, 11:55:09 AM GMT+1 web_php 7634 ERR Can't create frame images from video for this event 56339-video.mp4Command was: /usr/bin/ffmpeg -ss 1.00 -i /media/user/LINUX-EXT/zmdata/2/2024-11-20/56339 ...

the default configuration of the latest reolink camera i purchased recently came without any access other than through the reolink client/app using a dedicated port. this was not the case with the previous reolink cameras i've had experience with and the reolink statement "No need to download any ...

Yeah I've been able to reproduce it. Don't worry about logs excellent - so one step closer to get this figured out :D. btw the logs i sent you were taken from a 22.04 installation but on 24.04 i ran into the same issue ... with 1.36.35 while 1.36.33 is running perfectly fine with my configuration ...

Ok, I know what is happening. Your packets are coming in out of order, but because you are encoding, we actually use wall clock timestamps. So since we resorted the packets, they are now out of order in terms of wallclock. So I'm disabling the reorder_queue stuff when doing encoding. You should ...

How stable is the timestamp from the cameras? Are they using ntp? You can send me a debug level 3 log from one of them and maybe I can figure it out. yes, both cameras are synchronized twice daily with ntp. i've attached the log to my original post on this issue (https://forums.zoneminder.com ...

I'll review the changes with an eye towards encoding... That last error suggests something very wrong with the encoding.. the last error could not be reproduced but i've attached a debug level 3 log with the "non increasing dts" issue which i am experiencing with 1.36.35 regardless of the reorder ...

Wait @eggenbef.... you are encoding? These dts issues should only happen with passthrough. We use the wall clock for timestamps when encoding... yes, i am using zm in mocord mode with analysis enabled and encoding with h264 using libx264 (see earlier in this post for further configuration details ...