Fix catchup stream backward skip on EOF near live edge

[kontell]

When watching a catchup stream within ~15 minutes of the live edge, playback periodically jumps backward. The skip happens every time the HLS catchup playlist is consumed and FFmpeg returns EOF.

Observed on Flussonic HLS servers which serve catchup playlists as finite VOD (#EXT-X-PLAYLIST-TYPE:VOD with #EXT-X-ENDLIST). The catchup URL uses &utc={utc}&lutc={lutc} parameters where lutc is fixed at URL generation time. Once playback reaches the end of the playlist, FFmpeg hits EOF, triggering the addon's restart logic.

Fixes: kodi-pvr/pvr.iptvsimple#781

Root cause

The EOF restart handler in FFmpegCatchupStream::DemuxRead() used m_previousLiveBufferOffset to determine where to seek after EOF. This variable is set when the stream opens or when the user seeks, but is never updated during continuous playback.

Near the live edge, the catchup VOD playlist is short (only covering the time from utc to lutc). Playback consumes it quickly — within a minute or two — and hits EOF. The restart then seeks back to m_previousLiveBufferOffset (the position at seek time), which is ~1–2 minutes behind the actual playback position. This creates a repeating loop: play briefly, EOF, skip back, play the same content again, EOF, skip back...

Fix

Use m_currentDemuxTime instead, which tracks the actual playback position as packets are demuxed. This ensures the EOF restart continues from where playback actually was, regardless of when the last seek occurred.

m_currentDemuxTime and m_pauseStartTime were both declared without an initializer and not set in the constructor's init list — left as indeterminate values of type double. The EOF restart path is gated by !m_isOpeningStream, so it can't be reached before the first packet sets m_currentDemuxTime, but the same isn't true for the pause path that reads m_pauseStartTime. Added = 0 initializers to both for safety.

• m_previousLiveBufferOffset: seconds since catchup buffer start, set once at open/seek, never updated during playback. Represents when the user last interacted, not where playback is.
• m_currentDemuxTime: milliseconds, updated from pPacket->pts on every demuxed packet. Represents actual playback position.

DemuxSeekTime() expects milliseconds, so m_currentDemuxTime can be passed directly (the old code multiplied m_previousLiveBufferOffset by 1000 to convert from seconds).

Testing

Tested on Android (Kodi 22, ARM v7) with a Flussonic HLS catchup stream.

Before fix — backward skip confirmed

CheckReturnEmptyOnPacketResult - isEOF: 1, terminates: 1, isOpening: 0, lastSeekWasLive: 0, lastLiveOffset+duration: 532805 > currentDemuxTime: 518426
DemuxRead - EOF detected on terminating catchup stream, starting continuing stream at offset: 518405, ending offset approx 518607

currentDemuxTime was 518426 but the restart seeked to 518405 (m_previousLiveBufferOffset) — a 21-second backward skip. Kodi's video player confirms:

CVideoPlayer::CheckContinuity - resync backward :2, prev:518426772000.222229, curr:518405000000.000000, diff:-21772000.222229

After fix — no backward skip

Debug logging over 5 minutes captured 4 consecutive EOF restart cycles:

• Demux offsets advance monotonically — no backward skips
• Each EOF restart seeks to within seconds of where playback was (starting offset vs ending offset gap: ~63s, matching the catchup URL window)
• Stream maintains steady ~62 second distance from live edge
• Audio resync occurs at each restart (CVideoPlayerAudio:: synctype set to 0) — brief audio glitch but no video disruption
• No CVideoPlayer::CheckContinuity - resync backward messages (present in the pre-fix log)

[kodiai]

Review Details

• Files reviewed: 2

• Findings: 0 critical, 0 major, 0 medium, 0 minor

• Lines changed: +5 -4

• Profile: strict (auto, lines changed: 9)

• Contributor experience: profile-backed (using linked contributor profile guidance)

• Review completed: 2026-04-27T13:49:36.694Z

• Total wall-clock: 4m 6s

• Phase timings:

  • queue wait: 0ms
  • workspace preparation: 1.9s
  • retrieval/context assembly: 2.1s
  • executor handoff: 2.0s
  • remote runtime: 3m 57s
  • publication: 1.2s

• Tokens: 74 in / 10,671 out | 0.3074

• Keyword parsing: No keywords detected

[kodiai]

kodiai response

Decision: APPROVE
Issues: none

Evidence:

• Review prompt covered 2 changed files.

[phunkyfish]

Thank you for the contribution!

Great fix, if you would like it released please update the micro version number in addon.xml.in and add a changelog entry. I've also merged your previous PR so feel to also add "Fix 6s close delay on timeshift HLS streams" to the changelog.

Let me know. Thanks again.

[kontell]

Thanks for reviewing this.

I've updated addon.xml.in & changelog.txt as suggested.

[phunkyfish]

The new commits are good. However you seem to have picked up a merge commit somewhere. There should only be 3 commits and not 4.