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...

userxy79

Thank you for your Respnse, sure i can.

Do you need to be timeshifting BACK a few hours, or timeshifting FOR a few hours by any amount?

Just Tune into a Channel u like, pause for example 30 seconds and let it play until the Stream stalls. You can rewind and fast forward as you like, it makes no difference. It happens when Timeshift comes into play, no matter in wich direction you timeshift.

How long is 'a few'? 2, 3, 4, more?

The DTS rollover issue occurred in my case by a good chance of 90% in a range from 6-18 hours of continuous timeshift usage – which is before the theoretical 26h31min limit imposed by the 33-bit counter at 90kHz.

Does this happen on a particular type of stream (HD, SD)?

No, it happens with Live-TV (in my case via DVB-S) as soon as timeshift comes into play.

Does this happen at a particular time of day?

No, it has nothing to do with the time of day, I would have noticed that

Which client(s) are you using for playback?

My clients are Kodi, both locally on the HTPC with TVH as the server, as well as on my TV, laptop, or tablet. It has nothing to do with the clients itselfand their versions, which are all stable 20.4 except for the one on the TV, which is 21.x, but as I said, that has nothing to do with the clients.

Having these parameters could help reproducibility and testing efforts.

Whatever you want to know, ask me and I will give you the answers to the questions you want to know

DeltaMikeCharlie

I was able to reproduce this today on an older version of TVH (LibreELEC 12).

I started live TV.
Paused for 1m30s.
Chase-played for the next 10+ hours.
Tried to rewind. It worked at first, but playback eventually froze and then showed a green screen.

TVH and Kodi were still working, but live TV was dead.

2025-10-27 07:39:04.717 tsfix: transport stream MPEG2VIDEO, DTS discontinuity. DTS = -9223372036854775808, last = 3461472442
2025-10-27 07:39:05.118 tsfix: transport stream MPEG2AUDIO, DTS discontinuity. DTS = -9223372036854775808, last = 3461473792
2025-10-27 07:39:05.184 tsfix: transport stream TELETEXT, DTS discontinuity. DTS = -9223372036854775808, last = 3461474212
2025-10-27 07:39:05.251 tsfix: transport stream TEXTSUB, DTS discontinuity. DTS = -9223372036854775808, last = 3461391027

I got back to the Kodi menu and selected another live TV channel and all was well again.

This is a good start and proves that this issue is reproducible. I want to try to force a few more freezes to familiarise myself with the problem. Once I do that, I'll try on a single bleeding-edge system, pre and post PR#1931 and see what happens.

userxy79

Yes, this Bug is as old as i use TVH, means since ₂₀₁₆.

Thank you for confirming 😉

"tsfix:" and "DTS = -9223372036854775808" are the Keywords here.

So yes, let`s see what happens next.

DeltaMikeCharlie

@userxy79 - Have you ever tried playing a recording-in-progress from the beginning and then skipping forward and then back again? I'd be interested to know if something similar happens.

DeltaMikeCharlie

@userxy79 - Can you please go into Config/Recording/Timeshift (in expert mode) and provide your settings?

userxy79

Have you ever tried playing a recording-in-progress from the beginning and then skipping forward and then back again? I'd be interested to know if something similar happens.

It does not happen often, but playing a Record that is already still recording and skipping Commercials happens from Time to Time and in all this ₁₀ Years i use TVH i did not see the Record fail because of this. May because in this Situation i am just playing the unfinished Recordfile instead of the Live-TV Stream or the Timeshiftbuffer if i am not wrong. And mostly my Records are not any longer then 2-3 Hours and the specific "tsfix DTS" errors happens in a wider Timerange as described earlier.

Can you please go into Config/Recording/Timeshift (in expert mode) and provide your settings?

Enabled: yes
Maximum period (mins): empty to use unlimited Time

Storage path: (empty to use the default path)
Maximum size (MB): empty to use unlimited Size
Maximum RAM size (MB): 16000 (32GB RAM available)
RAM only: No

On-demand (no first rewind): No
Unlimited time: Yes
Unlimited size: Yes
Fit to RAM (cut rewind): No
Include teletext: No

This is the Setup i prefer, but trust me, i tried many many other Configurations with different Settings/Limits and it does not make any Difference. The last 3 Months i tried the following Setting but no Difference, the Error triggers also.

Enabled: yes
Maximum period (mins): 600 (10 Hours)

Storage path: (empty to use the default path)
Maximum size (MB): 100000 (100GB)
Maximum RAM size (MB): 16000 (32GB RAM available)
RAM only: No

On-demand (no first rewind): No
Unlimited time: No
Unlimited size: No
Fit to RAM (cut rewind): No
Include teletext: No

DeltaMikeCharlie

Today I have been timeshifting for 12 hours with no freeze. I was regularly moving the timeshift around to see if there was a specific time limit to when the freeze may occur. Perhaps that regular activity prevented the freeze, perhaps it's just slightly random. I will try again tomorrow and not touch the RCU for 8 hours and see what happens.

I am also logging HTSP (Kodi) activity to look for the subscriptionSeek HTSP command immediately prior to the freeze. If that request is malformed, it may be easier to trace the source and explain the freeze. Even if I do find a malformed command, it would still be a TVH problem because TVH should sanity-check the values before skipping.

userxy79

Hey, it's great to see how you're tackling this problem.

Unfortunately, there's no specific scenario that triggers the error at a particular point. It's random and can happen sooner or later. That's what made it so difficult for me to analyze too.

Believe me, from time to time over the last years i have tested things out to narrow it down and maybe even solve the problem myself. Only when I realized the error wasn't just 30-50 cm behind the screen and that it was very likely a bug did I publish the report on GitHub.

But, and this is crucial, having a second or third person confirm all of this is not only helpful but practically essential for a proper error analysis.

As I said, my research indicates that it's highly likely this is related to how TVH handles this tsfix error in the code.

But first, let's see what your tests reveal, and then we'll proceed.

userxy79

Following what happens when the stream stalled, unnecessary things have been cut out (Logs sorted from Bottom to Top):

tvheadend.log

2025-10-28 06:41:06.104 [  DEBUG]:htsp: 127.0.0.1 [ *** | Kodi Media Center ] - first packet
2025-10-28 06:41:06.104 [  DEBUG]:htsp: 127.0.0.1 [ *** | Kodi Media Center ] - subscription start
025-10-28 06:41:05.660 [  DEBUG]:linuxdvb: Conexant CX24117/CX24132 #1 : DVB-S #0 - locked
2025-10-28 06:41:05.660 [  DEBUG]:linuxdvb: Conexant CX24117/CX24132 #1 : DVB-S #0 - status    GOOD (SIGNAL | CARRIER | VITERBI | SYNC | LOCK)
2025-10-28 06:41:05.567 [  DEBUG]:htsp: 127.0.0.1 [ userxy | Kodi Media Center ] - subscription speed
2025-10-28 06:41:05.567 [  DEBUG]:htsp: 127.0.0.1 [ userxy | Kodi Media Center ] - subscription grace 10 seconds
2025-10-28 06:41:05.567 [   INFO]:subscription: 2588: "127.0.0.1 [ userxy | Kodi Media Center ]" subscribing on channel "ZDF INFO HD", weight: 125, adapter: "Conexant CX24117/CX24132 #1 : DVB-S #0", network: "ASTRA OST", mux: "11347V", provider: "ZDFvision", service: "ZDFinfo HD", profile="htsp", hostname="127.0.0.1", username="userxy", client="Kodi Media Center"
2025-10-28 06:41:05.567 [  DEBUG]:mpegts: 11347V in ASTRA OST - open PID 1A2C (6700) [16/0x7fa7b0016a60]
2025-10-28 06:41:05.567 [  DEBUG]:mpegts: 11347V in ASTRA OST - open PID 1A4B (6731) [8/0x564b7eb6c0d0]
2025-10-28 06:41:05.567 [  DEBUG]:mpegts: 11347V in ASTRA OST - open PID 1A4A (6730) [8/0x564b7eb6c0d0]
2025-10-28 06:41:05.567 [  DEBUG]:mpegts: 11347V in ASTRA OST - open PID 1A43 (6723) [8/0x564b7eb6c0d0]
2025-10-28 06:41:05.567 [  DEBUG]:mpegts: 11347V in ASTRA OST - open PID 1A42 (6722) [8/0x564b7eb6c0d0]
2025-10-28 06:41:05.567 [  DEBUG]:mpegts: 11347V in ASTRA OST - open PID 1A41 (6721) [8/0x564b7eb6c0d0]
2025-10-28 06:41:05.567 [  DEBUG]:mpegts: 11347V in ASTRA OST - open PID 1A40 (6720) [8/0x564b7eb6c0d0]
2025-10-28 06:41:05.567 [  DEBUG]:mpegts: 11347V in ASTRA OST - open PID 1A36 (6710) [8/0x564b7eb6c0d0]
2025-10-28 06:41:05.567 [  DEBUG]:mpegts: 11347V in ASTRA OST - open PID 1A2C (6700) [8/0x564b7eb6c0d0]
2025-10-28 06:41:05.567 [  DEBUG]:tbl-eit: eit: installed table handler (pid 18)
2025-10-28 06:41:05.567 [  DEBUG]:mpegts: 11347V in ASTRA OST - open PID 0012 (18) [20/0x7fa7b00e7da0]
2025-10-28 06:41:05.567 [  DEBUG]:tbl-eit: eit: grab started
2025-10-28 06:41:05.567 [  DEBUG]:mpegts: 11347V in ASTRA OST - started
2025-10-28 06:41:05.561 [  DEBUG]:linuxdvb: Conexant CX24117/CX24132 #1 : DVB-S #0 - starting 11347V in ASTRA OST
2025-10-28 06:41:05.504 [   INFO]:mpegts: 11347V in ASTRA OST - tuning on Conexant CX24117/CX24132 #1 : DVB-S #0
2025-10-28 06:41:05.504 [  DEBUG]:service: 5: ZDF INFO HD si 0x7fa7b0148090 Conexant CX24117/CX24132 #1 : DVB-S #0 weight 0 prio 10 error 0 (OK)
2025-10-28 06:41:05.504 [  DEBUG]:service: 6: ZDF INFO HD si 0x7fa7b00245b0 Conexant CX24117/CX24132 #0 : DVB-S #0 weight 0 prio 10 error 0 (OK)
2025-10-28 06:41:05.504 [  DEBUG]:htsp: 127.0.0.1 [ userxy | Kodi Media Center ] - subscribe to ZDF INFO HD using profile htsp
2025-10-28 06:41:05.504 [  DEBUG]:htsp: using timeshift buffer (unlimited)
2025-10-28 06:41:05.158 [   INFO]:htsp: 127.0.0.1 [ *** | Kodi Media Center ]: Privileges updated
2025-10-28 06:41:05.158 [   INFO]:htsp: 127.0.0.1 [ Kodi Media Center ]: Identified as user '***'
2025-10-28 06:41:05.158 [   INFO]:htsp: 127.0.0.1: Welcomed client software: Kodi Media Center (HTSPv35)
2025-10-28 06:41:05.158 [   INFO]:htsp: Got connection from 127.0.0.1
2025-10-28 06:41:05.137 [  DEBUG]:htsp: 127.0.0.1 [ *** | Kodi Media Center ] - subscription stop
2025-10-28 06:41:05.137 [   INFO]:subscription: 24BC: "127.0.0.1 [ *** | Kodi Media Center ]" unsubscribing from "ZDF INFO HD", hostname="127.0.0.1", username="***", client="Kodi Media Center"
2025-10-28 06:41:05.137 [   INFO]:htsp: 127.0.0.1 [ *** | Kodi Media Center ]: Disconnected
2025-10-28 06:40:50.963 [  DEBUG]:tbl-eit: eit: completed pid 18 table 00000000 / 00000000
2025-10-28 06:40:34.589 [WARNING]:tsfix: transport stream MPEG2AUDIO, DTS discontinuity. DTS = -9223372036854775808, last = 2171102947
2025-10-28 06:40:34.589 [WARNING]:tsfix: transport stream MPEG2AUDIO, DTS discontinuity. DTS = -9223372036854775808, last = 2171103307
2025-10-28 06:40:34.575 [WARNING]:tsfix: transport stream TELETEXT, DTS discontinuity. DTS = -9223372036854775808, last = 2171102480
2025-10-28 06:40:34.552 [WARNING]:tsfix: transport stream AC3, DTS discontinuity. DTS = -9223372036854775808, last = 2171102283
2025-10-28 06:40:34.552 [WARNING]:tsfix: transport stream MPEG2AUDIO, DTS discontinuity. DTS = -9223372036854775808, last = 2171104387
2025-10-28 06:40:33.870 [WARNING]:tsfix: transport stream H264, DTS discontinuity. DTS = -9223372036854775808, last = 2171103147
2025-10-28 06:40:31.786 [WARNING]:tsfix: transport stream DVBSUB, DTS discontinuity. DTS = -9223372036854775808, last = 2170910551
2025-10-28 06:40:30.844 [  DEBUG]:mpegts: 11008.5V in ASTRA OST - add raw service

kodi.log

2025-10-28 06:41:07.928 T:288944 warning <general>: OutputPicture - timeout waiting for buffer
2025-10-28 06:41:06.137 T:137299    info <general>: Opening stream: 1006 source: 256
2025-10-28 06:41:06.137 T:137299    info <general>: Opening stream: 1007 source: 256
2025-10-28 06:41:06.137 T:137299    info <general>: Opening stream: 1004 source: 256
2025-10-28 06:41:06.137 T:137299    info <general>: Opening stream: 1001 source: 256
2025-10-28 06:41:05.683 T:3927356    info <general>: AddOnLog: pvr.hts: Async updates initialised
2025-10-28 06:41:05.159 T:390540    info <general>: AddOnLog: pvr.hts: Async updates requested
2025-10-28 06:41:05.159 T:390540    info <general>: AddOnLog: pvr.hts: Request async EPG (31 days)
2025-10-28 06:41:05.159 T:390540    info <general>: AddOnLog: pvr.hts:   Name: webtv-h264-aac-matroska, Comment: WEBTV profile H264/AAC/Matroska
2025-10-28 06:41:05.159 T:390540    info <general>: AddOnLog: pvr.hts:   Name: webtv-vp8-vorbis-webm, Comment: WEBTV profile VP8/Vorbis/WEBM
2025-10-28 06:41:05.159 T:390540    info <general>: AddOnLog: pvr.hts:   Name: htsp, Comment: HTSP Default Stream Settings
2025-10-28 06:41:05.159 T:390540    info <general>: AddOnLog: pvr.hts:   Name: WEB-TV-CUSTOM, Comment: Custom Profile to use GPU (GTX 1060) for Streaming
2025-10-28 06:41:05.159 T:390540    info <general>: AddOnLog: pvr.hts:   Name: webtv-h264-aac-mpegts, Comment: WEBTV profile H264/AAC/MPEG-TS
2025-10-28 06:41:05.159 T:390540    info <general>: AddOnLog: pvr.hts:   Name: stream, Comment: 
2025-10-28 06:41:05.159 T:390540    info <general>: AddOnLog: pvr.hts:   Name: webtv-h264-vorbis-mp4, Comment: WEBTV profile H264/Vorbis/MP4
2025-10-28 06:41:05.159 T:390540    info <general>: AddOnLog: pvr.hts:   Available streaming profiles:
2025-10-28 06:41:05.158 T:390540    info <general>: AddOnLog: pvr.hts:   streaming connection limit : 0
2025-10-28 06:41:05.158 T:390540    info <general>: AddOnLog: pvr.hts:   DVR connection limit       : 0
2025-10-28 06:41:05.158 T:390540    info <general>: AddOnLog: pvr.hts:   global connection limit    : 0
2025-10-28 06:41:05.158 T:390540    info <general>: AddOnLog: pvr.hts:   anonymous HTSP only        : 0
2025-10-28 06:41:05.158 T:390540    info <general>: AddOnLog: pvr.hts:   Failed/aborted DVR         : 1
2025-10-28 06:41:05.158 T:390540    info <general>: AddOnLog: pvr.hts:   HTSP DVR                   : 1
2025-10-28 06:41:05.158 T:390540    info <general>: AddOnLog: pvr.hts:   HTSP streaming             : 1
2025-10-28 06:41:05.158 T:390540    info <general>: AddOnLog: pvr.hts:   administrator              : 1
2025-10-28 06:41:05.158 T:390540    info <general>: AddOnLog: pvr.hts:   Received permissions:
2025-10-28 06:41:05.131 T:137299 warning <general>: AddOnLog: pvr.hts: demux read no data for at least 30 secs; restarting connection
2025-10-28 06:40:35.647 T:288941    info <general>: CVideoPlayerAudio::Process - stream stalled

DeltaMikeCharlie

userxy79 Following what happens when the stream stalled,

Based on the timestamp, once the TVH error occurs, Kodi gets a timeout and then seems to reinitialise pvr.hts. This seems to be reasonable behaviour.

Next time, can you please include htsp-req in your TVH logging. It will show the commands that TVH receives from Kodi.

DeltaMikeCharlie

I left my system running overnight so that I could accumulate 8 hours of timeshift while I slept. Luckily, this resulted in another freeze. 🙂 There is no -9223372036854775808 in the TVH log, so I suspect that I have encountered something different. 🙁

The subscriptionSeek command issued by Kodi was not malformed as far as I can tell.

The freeze is slightly different this time: I still have an image and I can navigate back and forward to various locations within the stream and the image changes accordingly, I just can't play the stream.

When I skip, Kodi shows that it is reloading its buffer, but when that reached 100%, it still does not play.

The Kodi log keeps repeating CDVDAudio::AddPacketsRenderer - timeout adding data to renderer every few seconds, but I suspect that this is normal behaviour if it is simply not getting any data.

I can try to pause/play the stream. The Kodi OSD clearly indicates that it is playing after a pause/play cycle. It is just not playing.

Unfortunately, I think that this incident was not particularly helpful.

userxy79

I also did another Testscenario.

This time i tuned into a channel and let it play, but without start/stop or timeshifting back or forward, until it eventually fails what it did after approx ₁₁ Hours.

To be clear, as you know my Timeshiftsetting is that the Timeshift buffer starts as soon as i tune into a channel but as i sayed i just let it play without touching the stream. This indicates clearly that start/stop or timeshifting the buffer back or forward is not the Problem nor triggers it.

And the Error itself is the same als always "tsfix DTS discontinuity. DTS = -9223372036854775808". This also should be a helpfull discovery.

And for "htsp-req" in my logs, there is not such logentry.
I have set Debug subsystems to all in the TVH Debug Configuartion page, so this should include "htsp-req" but as i sayed, no such logentry.

DeltaMikeCharlie

userxy79 This time i tuned into a channel and let it play, but without start/stop or timeshifting back or forward, until it eventually fails what it did after approx 11 Hours.

userxy79 This indicates clearly that start/stop or timeshifting the buffer back or forward is not the Problem nor triggers it.

This is actually excellent news. Well done!
I will try to reproduce these results this evening.

Did your live TV freeze or keep playing?
Did your timeshift buffer files keep growing or did they stop after the error?

I think that we can rule out anything to do with htsp commands now.

userxy79

Did your live TV freeze or keep playing?

Same behave as always, stream stalls, then it reinitalize and plays but nor start/stop or timeshifting back or forward is working until the stream got stopped and retuned into it clean.

Did your timeshift buffer files keep growing or did they stop after the error?

To be true i did not watched this behaviour. but because nor start/stop or timeshifting back or forward after reinitialize works, i think the buffer is gone after crash and thats why it dont works after reinitialize. Just a theory.

DeltaMikeCharlie

There is 1 timeshift buffer file per minute that seem to be named according to the timestamp where they start. If the file name looks crazy or file creation stops, that may also be a hint. Maybe I could also make a cron job that lists the buffer files every minute.

userxy79

Let`s do things step by step 😉

May first try to reproduce what we found out newly and if you can confirm it, let`s see wich step next to take on.
Progress is going good so far and its not that we need to rush trough.