What does "Non-increasing DTS" mean?

General Discussions
1

I was looking at the Plex logs because of some problem I had (not relevant to this query) and I saw in Plex Media Scanner.log and there were a lot of lines that looked like this:
“DEBUG - [FFMPEG] - Non-increasing DTS in stream 1: packet 880 with DTS 734, packet 881 with DTS 734”.

Does this mean there’s a problem with some of the media files? Too many files to analyse, but I did see that in one case the lines came after analysing a movie file that had no DTS tracks. It had Dolby True HD (Format: MLP FBA) and two Dolby Digital (AC-3) tracks.

2

It just means that the media analysis was not able to identify a valid DTS stream within your file. Which makes sense if there actually is no DTS stream in there.

3

Thanks for the quick reply. But it’s not like the line appears only once. I have log files of about 78,000 lines and there are chunks of literally hundreds of consecutive lines like this, with only the packet and DTS digits changing.

Once the analysis has found there is no DTS stream, it doesn’t seem logical to continually look for it.

4

DTS here is Decode TimeStamp. It’s in indicating when the video or audio frame (packet) should be decoded as opposed to PTS which is Presentation TimeStamp. Essentially it is presenting a warning that there is a discontinuity in time stamps where the DTS went down from one packet to the next. This is atypical and usually is the result of cutting together video data that was not encoded together. It can potentially cause playback issues around the time discontinuity if the player gets confused around when decode and presentation should actually be preformed for these frames.

5

Thanks for the explanation. Darn TLAs!

6

I stand corrected.
I wonder if you could fix it by remuxing the file. For regular videos you could use MKVtoolnix.
If this is a recorded video (i.e. a .TS file), you can try dedicated software like “TS-Doctor”.

7

I suspect I could fix it, but I would have to dig through the log files to see which specific files are affected. I did try out one file which had these errors, and it seemed to play fine. So for practical purposes and for now, doesn’t seem to be a big issue, except for the large log files. From what I can see, the files don’t seem to be growing or perhaps they cycle, so it’s not like the logs are eating up disk space.

So I’m just going to leave things as they are for now.