Issue/Bug -- DTS = INT64_MIN causes stream failure during Timeshift

userxy79 · 2025-10-25T16:00:21+00:00

Hello, I discovered a very long existing and reproducible issue affecting Live-TV Timeshift in Tvheadend. After several hours of uptime with Timeshift act...

DeltaMikeCharlie

DeltaMikeCharlie I'm going to keep going until tomorrow morning and see what happens.

It seems that during the night, my timeshift buffer reset itself. I went to bed with well over 1100 buffer files and I awoke to find 555.

I started my experiment at 2025-10-30 10:23:40 UTC and I got the INT64_MIN error at 2025-10-31 10:14:10 UTC. Give or take a few minutes, this is almost exactly 24 hours. Not quite the 26-ish I was hoping for, but possibly consistent with the broadcaster having just wrapped their DTS ≈2 hours before I commenced my test. Maybe.

I don't know the significance of this finding because I only have 1 data point. It could be just random chance.

What is interesting though, after the INT64_MIN error, the stream seems to have restarted without a problem. From the log, at 2025-10-31 10:24:24.122 UTC, 10 minutes after the freeze, Kodi disconnected and then reconnected and restarted the stream. This is strange because in Kodi, my "Threshold for reconnect on stalled streams (seconds)" is "10".

userxy79

My last run was the longest i noticed for a long while with the following Runtime:

Started:

2025-10-31 01:50:56.145 [  DEBUG]:service: 5: PRO 7 si 0x7fa7b00268b0 Conexant CX24117/CX24132 #1 : DVB-S #0 weight 0 prio 10 error 0 (OK)
2025-10-31 01:50:56.145 [  DEBUG]:service: 6: PRO 7 si 0x7fa7b0016120 Conexant CX24117/CX24132 #0 : DVB-S #0 weight 0 prio 10 error 0 (OK)
2025-10-31 01:50:56.145 [  DEBUG]:htsp: 127.0.0.1 [ **** | Kodi Media Center ] - subscribe to PRO 7 using profile htsp

Stalled:

2025-11-01 03:26:45.389 [WARNING]:tsfix: transport stream TEXTSUB, DTS discontinuity. DTS = -9223372036854775808, last = 8293070599
2025-11-01 03:26:43.759 [WARNING]:tsfix: transport stream TELETEXT, DTS discontinuity. DTS = -9223372036854775808, last = 8293238863
2025-11-01 03:26:43.702 [WARNING]:tsfix: transport stream AC3, DTS discontinuity. DTS = -9223372036854775808, last = 8293239360
2025-11-01 03:26:43.702 [WARNING]:tsfix: transport stream MPEG2AUDIO, DTS discontinuity. DTS = -9223372036854775808, last = 8293238640
2025-11-01 03:26:43.041 [WARNING]:tsfix: transport stream MPEG2VIDEO, DTS discontinuity. DTS = -9223372036854775808, last = 8293237200

So in fact 25 hours, 35 minutes and 49 seconds, very close to the magic 26 hours, 30 minutes and 43 seconds.

And i can confirm the timeshiftbuffer files got deleted.

I see that, because after the Stream stalled it reconnects as always and starts playing again, the RAM is growing wich means its again creating the Timeshiftbuffer. But as you know it is not possible to shift forward or backward until the Channel got stopped clean and tuned into it again.

So let us decide what to do with all the things Discovered and how to move on 😉

DeltaMikeCharlie

After yesterday's incident, knowing the exact time that the previous INT64_MIN error occurred on my system, I left TVH running to see what happens:

Yesterday (times are UTC)
2025-10-31 10:14:10.302 - INT64_MIN error
2025-10-31 10:24:24.122 - Kodi restarts stream (00:10:14)

Today
2025-11-01 12:44:54.031 - INT64_MIN error (26:30:44)
2025-11-01 12:45:05.172 - Kodi restarts stream (00:00:11)

The interval between yesterday's and today's INT64_MIN errors is 26:30:44. I think that this data point is consistent with the broadcaster wrapping their DTS.

userxy79 So let us decide what to do with all the things Discovered and how to move on 😉

I think that we need to examine the area of code that deals with the DTS of the incoming stream.

Also, the error it could need 2 conditions to trigger: If the incoming DTS wraps AND the buffer is a larger than certain size, for example.

I would like to see when happens to a shorter timeshift (maybe 1-2 hrs) that occurs when the broadcaster DTS wraps.

userxy79

Allright, then this confirms exactly the DTS Wraparound Issue in TVH or in other words the Issue how TVH handles it and that it leads to the Problems we discovered. Well Done.

Testing a lower Timeshiftbuffer, for example 1-2 Hours, would lower the chance of hitting exact the DTS Wrap and trigger the Issue. And Maybe thats why until now none discovered this Bug/Issue because the longer the Timeshiftbuffer runs the higher the Risk to hitting the Spot.

I've revised my code proposal for the fix and posted it Here

Please keep in mind that this is just a suggestion, but perhaps it points in the right direction and only requires minor adjustments. Or you can build upon it or use it as a starting point. May its something to work with.

DeltaMikeCharlie

I have left my system running because I intend to test with a short timeshift between Wednesday-Sunday when the wraparound should occur during my waking hours.

Today's freeze was the same as yesterday: 26:30:44 with Kodi restarting after 00:00:11. I had to double-check my log just to make sure I was looking at the right day.

« Previous Page