[Bug] Video freezes while audio continues - second bug?

[mr-brunes]

Describe the problem

My Hardware Setup:
Device: Minix NEO U22-XJ (S922X-J)
OS: CoreELEC 22.0-Piers_alpha3 (Amlogic-NO architecture)

Issue Description:
When using the iPlayer WWW add-on, the video stream completely freezes a few moments after playback starts, while the audio track continues to play flawlessly in the background.

Possible fix

This was fixed by #2075 but the issue is occurring again.

Steps to reproduce

Open iplayerwww
Select live stream
Select BBC News
After a few minutes the video freezes but the audio continues.

Debug log

https://paste.coreelec.org/FelizCleavage
video freezes around 13:44

Stream manifest file(s)

No response

Additional info

No response

Operating system(s)

Other (specify below)

Operating system version(s)

22.0-Piers_alpha3 build (22.0-Piers_nightly_20260721

InputStream Adaptive version(s)

22.3.19.1

Kodi version(s)

Kodi (22.0-BETA1 (21.90.801)

[larena1]

Hi @mr-brunes — this might be related to a segment-buffering bug I've been fixing in the shared AdaptiveStream layer: at a segment boundary the reader can drop media that hasn't finished downloading, punching a hole into the video with no error and leaving the decoder on a stillframe while audio keeps playing — during plain playback, not just on seeks.

One caveat: in my tests it recovered after a few seconds rather than freezing for good, so yours may be the same cause hitting harder on your stream/platform, or something adjacent. A build would tell us.

PR: #2093

Could you build inputstream.adaptive from it and retry the BBC News live stream?

[mr-brunes]

@larena1 thank you for the info. The video froze and did not recover in my case.
Unfortunately I don't know how how to build inputstream.adaptive. I'm happy to install a zip file, test and submit logs as I did with #2075.

[larena1]

We'll have to wait for @CastagnaIT then

[CastagnaIT]

your PR touch many different critical code parts, and made by AI which is difficult to trust blindly
but if this issue concern is a small part of the code, it's better to identify which one it is rather than making many changes that need extensive tests

in PR section "How has this been tested" you mentioned AV sync problem in the seek, but its not explained the difference before/after if readable from log, i hadn't noticed AV sync problems so i will need to understand better this thing

I have really been short on free time lately, so it might take up a week to look into the problem

[larena1]

It was a few different issues on different streams actually. You and I discussed seeking before and it has gotten a bit better but especially with HLS there are still issues.

I had Claude add lots of debug logging so it can identify the root cause of each and fix it over many iterations. I didn't notice any regressions and as you well know there have been quite a few regressions in the past so it can always happen unfortunately.

Can you let the pipeline run so @mr-brunes can see if this improves his issue too? It's not one of the issues I experienced but still worth a try. I'll keep running my build until this maybe gets merged.

[CastagnaIT]

i ask to @mr-brunes to republish your log file because its expired, i suggest you to attach it directly as file "drag n drop" or use https://paste.kodi.tv/ that keep the data longer

to note that the problem mentioned by the user of the previous issue was about the "wait for segment" code it should not related to your changes
You can also have your changes tested here, but then how can you figure out what the underlying problem? you need to gradually narrow down the changes step by step, but you need to test it each time...
what i mean is that to determine the actual issue solution, its needed to reproduce the problem locally and then investigate it

[mr-brunes]

kodi.zip Log attached with video freeze about 2026-07-25 15:02.

[larena1]

I had Claude go through the full log. The defect is the video sample reader latching
EOS and never being asked for anything again:

Claude analysis

The lead-up is ordinary use. The viewer pauses for 122 s (KEY_PAUSE
14:39:22.716, resume 14:41:24.708) and presses StepBack eight times between
14:39:15 and 14:45:19. All eight seeks land correctly - video and audio at the same
position, each pair exactly 42667 µs apart, two AAC frames at 48 kHz. One period, one
representation per track, no ABR switch, no discontinuity anywhere in the session.

Kodi keeps filling while paused, so afterwards the demuxed pts runs ~253 s ahead of
the playback clock and stays between 251 and 255 s for the next twelve minutes. The
addon is not holding that - m_segBuffers.SetMaxSize(4) caps our own buffer at four
segments, ~15 s - it sits in Kodi's queues. Playback is completely normal throughout.

Video downloads stop. A ~253 s span keeps Kodi's video queue at level:100, so
Kodi stops pulling video and we stop downloading:

14:58:06.708  OnSampleRequested: [AS-0] End WaitForSegment stream rep. id "pv14" period id "1"
14:58:06.844  [AS-0] Download finished: .../v=pv14/b=5070016/464840593.m4s (2778902 byte)

That is the last [AS-0] line. For the following four minutes there is not one video
download, not one ProcessVideoData and not one further ensureSegment for AS-0 -
while audio keeps fetching every ~4 s. Begin/End WaitForSegment for AS-0 are
balanced at 27/27, so the reader is not blocked in a wait; it is never called again.

Four minutes later it runs out. The queue drains at exactly 1× (247.935 s of pts
across 247.955 s of wall clock) and ends where the queued material ends - last picture
pts:1784987870.620 at 15:02:15.516, then Stream stalled, start buffering. Audio: 100 - Video: 0. Audio continues, video never returns.

The mechanism. CSession::GetNextSample has exactly one silent skip
(src/Session.cpp:810):

else if (!streamReader->EOS())

Everything else in that loop either logs or stops the whole call -
IsReadSampleAsyncWorking() and OnSampleRequested() both set waiting, and
IsReady() is unconditionally true for the fragmented reader. Video is passed over
with no log output at all, so EOS() was true.

It is latched in CFragmentedSampleReader::ReadSample
(src/samplereader/FragmentedSampleReader.cpp:259):

if (result == AP4_ERROR_EOS)
{
  ...
  if (adByteStream->waitingForSegment())
    result = AP4_SUCCESS;   // download pending -> caller retries
  else
    m_eos = true;           // nothing pending -> latch
}

The waitingForSegment() branch is what normally rescues a reader that runs dry, and
it does not apply here: because the queue-full state had already stopped us
requesting the next segment, nothing was in flight when the reader consumed the last
of segment 593. m_eos is only cleared by Reset(false), reachable solely from
SeekAdStream in CSession::SeekTime (src/Session.cpp:923) - no playback path clears
it, which is why it never recovers.

This is a race rather than a deterministic outcome; it depends on whether a download
happens to be in flight when the reader hits the end. The queue-full state makes it
very likely because it stops the fetching entirely.

Direction. EOS on a live stream that still has segments ahead of it is not an end
of stream. The waitingForSegment() guard already encodes the right intent, it is
just too narrow - it covers "a download is in flight" but not "no download has been
requested yet". Either do not latch while the timeline holds segments beyond the
current one, or clear the flag when ensureSegment next produces data.

A single seek after the freeze should restore the picture, since that is the only
thing calling Reset(false) - cheap confirmation of the whole diagnosis.

[mr-brunes]

kodi-seek-back-1648.zipI did another test and the video froze at about 16:45. Then when I'd spotted the freeze at around 16:48 I pressed skip back and the video started again, not back at that point but the stream was back near live.

[larena1]

I think I ran into this too a few versions back, and it stuck around for a while — but on my side it's been fine since. Claude took a few attempts to finally land on this conclusion, and it had other suspicions along the way. Now we'll have to wait and see whether @CastagnaIT confirms this is really the cause, or whether it turns out to be something else entirely.