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.

userxy79

What more does it need to prove the Issue then the following Log, you discovered also:

2025-11-03 15:05:53.002 [WARNING]:tsfix: transport stream TEXTSUB, DTS discontinuity. DTS = -9223372036854775808, last = 4604130735
2025-11-03 15:05:52.074 [WARNING]:tsfix: transport stream TELETEXT, DTS discontinuity. DTS = -9223372036854775808, last = 4604346632
2025-11-03 15:05:52.028 [WARNING]:tsfix: transport stream MPEG2AUDIO, DTS discontinuity. DTS = -9223372036854775808, last = 4604347523
2025-11-03 15:05:52.005 [WARNING]:tsfix: transport stream AC3, DTS discontinuity. DTS = -9223372036854775808, last = 4604346083
2025-11-03 15:05:51.806 [WARNING]:tsfix: transport stream MPEG2VIDEO, DTS discontinuity. DTS = -9223372036854775808, last = 4604348243
2025-11-02 12:35:09.448 [WARNING]:tsfix: transport stream TEXTSUB, DTS discontinuity. DTS = -9223372036854775808, last = 6229649732
2025-11-02 12:35:08.388 [WARNING]:tsfix: transport stream TELETEXT, DTS discontinuity. DTS = -9223372036854775808, last = 6229792515
2025-11-02 12:35:08.348 [WARNING]:tsfix: transport stream AC3, DTS discontinuity. DTS = -9223372036854775808, last = 6229792436
2025-11-02 12:35:08.223 [WARNING]:tsfix: transport stream MPEG2AUDIO, DTS discontinuity. DTS = -9223372036854775808, last = 6229792436
2025-11-02 12:35:07.881 [WARNING]:tsfix: transport stream MPEG2VIDEO, DTS discontinuity. DTS = -9223372036854775808, last = 6229793876

DeltaMikeCharlie

Yet again, today's freeze was identical: 26:30:44 and 00:00:11.

Tomorrow's freeze 'should' occur during my waking hours, so I will be able manually test and see if the freeze only occurs with a long duration timeshift or if any duration will trigger the freeze. Freezes 'should' occur during my waking hours for the next week so I can perform multiple short duration tests if required.

userxy79

Allright, sounds like a plan. So Fingers crossed.

Unfortunately, as much as I wouldreally like to, I cannot really support you in testing the shorter timeshift periods because I do not have a second test system with the required TV card, nor the necessary connections on the satellite system, and I need the long timeshift periods on my live system for some clients. But if there is anything else, let me just know. 😉

Meanwhile yesterday, i cleaned up and finally updated my Posts in tvheadend/tvheadend1931 for a better readability.

DeltaMikeCharlie

userxy79 Unfortunately, as much as I wouldreally like to,

That's OK.

I'm going to test a short timeshift tomorrow morning on my existing LibreELEC unit.

Following that, I going to put in a temporary SSD, build a new clean OS and then test again. After that, I'm going to build with your PR and see what happens.

If short timeshifts also have the problem, then the testing cycle may be shortened because I should be able to target wraparound events.

DeltaMikeCharlie

This morning's test did not freeze. I had been timeshifting for about 2 hours when the wraparound was due but no freeze occurred. This could mean:

TVH is not vulnerable to DTS wraparound error for short timeshifting durations. (How short is short?)
The broadcaster had already wrapped/restarted the DTS for unrelated reasons.
My predicted time was incorrect.

I'm going to let my system continue to timeshift for another 26 hours and see when/if a freeze occurs. If it is still in line with my prediction, I will try a short timeshift the day after.

UPDATE: My system got an INT64_MIN error about 6h30m after the expected time. This suggests to me that the broadcaster may have wrapped/restarted their DTS. This made my total timeshift duration around 08:30:00.

I will test a 2h timeshift at my new projected time tomorrow.

DeltaMikeCharlie

I tested a 2h timeshift a few days ago and no freeze occurred. I have encountered difficulties rebuilding the test system that I was planning to use, so further testing is delayed until those issues are resolved.

userxy79

Thank you for reporting back 😉

Don't worry, it takes as long as it takes and i'm as i said very sorry that i can't test it with you too, related on this specific 2 Hours Test Scenario. Keep me up to date.

userxy79

@DeltaMikeCharlie

So, whats the status on your side? Please give me a little Feedback 😉

DeltaMikeCharlie

userxy79 So, whats the status on your side? Please give me a little Feedback

I have not forgotten this one. 🙂

I am still struggling with my test system configuration. I have my production system that I was able to reproduce the issue with. I also have a test system that I want to run in parallel to test the proposed fix. If the production system has the error and the test system does not, then we have a successful fix.

I need to preserve the current test system because it has work-in-progress that I value. I have tried to install a new SSD/HD, but the machine won't recognise them. My next step will be to use Clonezilla to backup the SSD, I will then install a fresh test system, run the test and then restore the original contents of the SSD.

To add to that, as the test system currently stands, it will not timeshift in the way the the production system does. No matter what I do. I'm sure that it is just a silly configuration parameter that I have missed somewhere, I just need to find it.

Both systems are based on LibreELEC and I would like to keep them roughly aligned, so I have build a LE system with both fixed and standard versions of their TVH addon.

I also work on other projects.

DeltaMikeCharlie

userxy79 Please give me a little Feedback

I finally got another HDD working in my test system. I need to review my previous LibreELEC builds and potentially rebuild and then install and test.

DeltaMikeCharlie

userxy79 Please give me a little Feedback 😉

My test system is finally up and running with the proposed fix and I have checked that timeshifting is currently active.
My production system is also running and timeshifting on the same channel as the test systems.

Logging is running on both systems. I hope to see my production system report a DTS error and my test system NOT report a DTS error at the same time.

Hopefully, within about 26h30 we should have a result.

DeltaMikeCharlie

userxy79 Please give me a little Feedback 😉

I have some promising results, but I am not yet sure that they are valid.

Unpatched 'Production' system log (Times in UTC)

2025-11-26 22:05:15.509 [WARNING] TS: DVB-T Network/177.5MHz/7HD Sydney Transport error indicator (total 28)
2025-11-26 22:05:15.509 [WARNING] TS: DVB-T Network/177.5MHz/7HD Sydney: H264 @ #577 Continuity counter error (total 20)
2025-11-26 22:31:39.697 [WARNING] tsfix: transport stream H264, DTS discontinuity. DTS = -9223372036854775808, last = 5969067570
2025-11-26 22:31:40.432 [WARNING] tsfix: transport stream TELETEXT, DTS discontinuity. DTS = -9223372036854775808, last = 5969066220
2025-11-26 22:31:40.432 [WARNING] tsfix: transport stream AC3, DTS discontinuity. DTS = -9223372036854775808, last = 5969067840
2025-11-26 22:31:41.250 [WARNING] tsfix: transport stream TEXTSUB, DTS discontinuity. DTS = -9223372036854775808, last = 5969057430
^^^^ DTS ERROR HERE FOLLOWED BY KODI RESET - THIS IS NORMAL
2025-11-26 22:31:51.155 [   INFO] htsp: 127.0.0.1 [  | Kodi Media Center ]: Disconnected
2025-11-26 22:31:51.155 [   INFO] subscription: 0001: "127.0.0.1 [  | Kodi Media Center ]" unsubscribing from "7 Digital", hostname="127.0.0.1", username="127.0.0.1", client="Kodi Media Center"
2025-11-26 22:31:51.158 [   INFO] htsp: Got connection from 127.0.0.1
2025-11-26 22:31:51.164 [   INFO] htsp: 127.0.0.1: Welcomed client software: Kodi Media Center (HTSPv35)
2025-11-26 22:31:51.164 [   INFO] htsp: 127.0.0.1 [ Kodi Media Center ]: Identified as user ''
2025-11-26 22:31:51.295 [   INFO] mpegts: 177.5MHz in DVB-T Network - tuning on Silicon Labs Si2168 #0 : DVB-T #0
2025-11-26 22:31:51.296 [   INFO] subscription: 0002: "127.0.0.1 [  | Kodi Media Center ]" subscribing on channel "7 Digital", weight: 100, adapter: "Silicon Labs Si2168 #0 : DVB-T #0", network: "DVB-T Network", mux: "177.5MHz", provider: "Seven Network", service: "7HD Sydney", profile="htsp", hostname="127.0.0.1", username="127.0.0.1", client="Kodi Media Center"

Patched 'Test' system log (Times in UTC+1100)

2025-11-27 02:37:07.327 [WARNING] TS: Default-DVB-T/177.5MHz/7HD Sydney Transport error indicator (total 81)
2025-11-27 02:37:07.327 [WARNING] TS: Default-DVB-T/177.5MHz/7HD Sydney: H264 @ #577 Continuity counter error (total 41)
2025-11-27 02:37:07.327 [WARNING] TS: Default-DVB-T/177.5MHz/7HD Sydney: AC3 @ #579 Continuity counter error (total 14)
2025-11-27 04:42:12.635 [WARNING] TS: Default-DVB-T/177.5MHz/7HD Sydney Transport error indicator (total 82)
<SNIP> LARGE NUMBER OF CONTINUITY ERRORS
2025-11-27 09:05:15.488 [WARNING] TS: Default-DVB-T/177.5MHz/7HD Sydney Transport error indicator (total 100)
2025-11-27 09:05:15.488 [WARNING] TS: Default-DVB-T/177.5MHz/7HD Sydney: H264 @ #577 Continuity counter error (total 52)
2025-11-27 09:31:39.692 [WARNING] tsfix: transport stream H264, DTS discontinuity. DTS = 0, last = 5973227761
^^^^ APPROXIMATELY THE SAME TIME - NO ERROR - NO KODI RESET
2025-11-27 09:43:14.004 [   INFO] epgdb: snapshot start
2025-11-27 09:43:14.148 [   INFO] epgdb: queued to save (size 4398258)
2025-11-27 09:43:14.149 [   INFO] epgdb:   broadcasts 10566
2025-11-27 09:43:14.149 [   INFO] epgdb: save start
2025-11-27 09:43:14.268 [   INFO] epgdb: stored (size 899994)

The good news is that the patched version of TVH did not appear to encounter the INT64_MIN problem when at the same time the unpatched version encountered the error. 👍️

The bad news is that the test system also encountered a lot more incidental discontinuity errors that may possibly have skewed the results in some way. Maybe, the test system is just under-powered for the task or maybe I am just being over-cautious.

Both systems are fed by the same antenna cable into the same splitter. From that splitter, each system has its own dedicated cable and USB tuner device. Both USB tuner devices are the same make/model.

I plan to rerun the test swapping the USB tuner, cable and port between the 2 systems. If the continuity errors follow the USB tuner, then I know that the issue is with that cable, splitter port or USB tuner. If the continuity errors follow the test system, then I know that the test system is under-powered or faulty in some other way.

This is potentially good news, just a little more testing is required to confirm my findings. However, if it were up to me, I would still not accept a patch this fundamental to the operation of TVH until it had been tested and proven on multiple systems with multiple configurations under various real-world conditions. Live TV, Recorded TV, DVB-T, DVB-C, DVB-S, ATSC, etc, etc...

IMHO, either more testing volunteers are required, or, there needs to be a parameter to disable this patch in a running system just in case there are has unexpected consequences.

Note: Even though the channels used appear to have different names, the come from the same service. The test system did a channel scan after the broadcaster changed the channel name. The production system has not been rescanned for a long time, the service name changed, but the channel name was not updated.

userxy79

Thank you for your quick response. 😉

As for your attempt to add a HDD/SSD that isnt reconized, first try if the disk get reconized in another system. if thats the Case the disk itself is okay. Then check the Cables in the System you failed to add the Disk, plug Cables out and back in, if its not working either, change to the cable where the Disk worked before. If that also fails, try another Port, if that also fails, the system itself where you want to add the Disk is having a Problem. Could be the Port, that is disabled in Bios or damaged or the OS itself is having Issues. Just some Tips to figure out whats the Case for the Problem.

As former Network/systemadministrator i know about the usecase of Production and Test Systems and the limited Resources of Time when working on more then one Project. Beside the Fact that only a handfull of Persons on TVH Project here are available to Help users and fix their Problems.

Even though the faulty DTS handling in TVH after 27.5 hours has already been confirmed several times, tell me what exatcly you wanted to prove with your Testsystem and maybe myself or someone else is able to help out testing.

DeltaMikeCharlie

@userxy79 - Thanks for your advice. I have swapped ports, etc, and the error always followed the drive. At first I thought that the drive was faulty, but then I got similar results with a second drive too.

userxy79 tell me what exatcly you wanted to prove with your Testsystem and maybe myself or someone else is able to help out testing.

I was simply going to run 1 patched and 1 not patched system side-by-side and observe the results. 2 systems with errors will mean that the fix did not work.

I think that my next step with the test system will be to make note of the exact BIOS error messages and then consult the manual.

userxy79

Allright, it was just an Idea from my side to Troubleshoot.

I know real Man`s dont look into Manuals and figure everything out them self,
but hey, sometimes a manual is useful for more than just the tilting chair 😃

As for your comparing patched and unpatched system side-by-side test, that is something i sadly can help you out.

But first things first, and i think in one way or another after consulting your Manual for BIOS Error Messages, it will tell you whats the Problem and what to do to get this fixed 😉

If you need further help contact me and we get this fixed.

userxy79

DeltaMikeCharlie
That sounds good. And what was the Problem, i hope it was not a faulty Disk, but rather that the problem was just a missconfigured BIOS setting.

« Previous Page Next Page »