Frame order issues in recorded events

Discussions related to the 1.36.x series of ZoneMinder
Post Reply
tonyblack
Posts: 1
Joined: Mon Apr 28, 2025 6:36 am

Frame order issues in recorded events

Post by tonyblack »

Hello,
I'm running ZoneMinder 1.36x in a TrueNAS Jail and it's been excellent up until a couple of months ago. Now my recorded events are 'out of order' - for example time jumps back/forwards by upto 5 seconds and is now obviously unusable.

I have 3 Tapo C320WS cameras (I know they're low-end but they've been working fine up until recently). For months ZM has been capturing all 3 streams on 'Record' mode with decoding enabled and analysis off, at QHD resolution and ~15 FPS. Low CPU and RAM usage, I was very happy.

However, i'd started seeing errors like below:

"pkt.dts(50162348) must be <= pkt.pts(50155872).Decompression must happen before presentation."

"Error writing packet: Invalid argument"

and "non increasing dts, fixing. our dts 54207982 stream 0 last_dts 54210997. reorder_queue_size=0"

I've tried decreasing and increasing the reorder_queue_size value, to the point that I used all 32GB of RAM on my server and locked the system up, and nothing had any impact on the recorded footage.

Does anyone have any recommendations on how to fix this?
cookiemonster
Posts: 64
Joined: Sat Aug 15, 2015 1:46 pm

Re: Frame order issues in recorded events

Post by cookiemonster »

Perhaps nothing to do with it but maybe time is something to check as well.
I had as ususal had to go and fix it when we had the change to BST (I am in the UK). If anytning it might be the reason for events out of order/time jumping.
mikb
Posts: 701
Joined: Mon Mar 25, 2013 12:34 pm

Re: Frame order issues in recorded events

Post by mikb »

tonyblack wrote: Mon Apr 28, 2025 6:43 am and "non increasing dts, fixing. our dts 54207982 stream 0 last_dts 54210997. reorder_queue_size=0"
Zoneminder is trying to compensate for a broken video stream. Each frame in the video has a timestamp of when it is expected to be shown, relative to the start of the file/stream. Because time is supposed to always run forward, and not stand still, FFMPEG is complaining that the "dts" (timestamp) isn't increasing, which is not right... so it's trying to patch over this bad data.

Have the cameras' firmwares been updated, breaking them? Updates are not always a positive thing.
tinymouse
Posts: 26
Joined: Sat Apr 02, 2022 11:36 pm

Re: Frame order issues in recorded events

Post by tinymouse »

I am too having issues with my Tapo C310 Cams with ghosting/image jumping. This all started to happen when all my Tapo cams got the latest firmware update to 1.4.1. I have rolled back most of my cams to their previous 1.3.8 and all is working fine with ZM.
Post Reply