A bursty live source is judged by the client's patience, so every normal delivery gap closes the window

[superuser404notfound]

A live channel hitches for a fraction of a second about every thirty seconds: the picture freezes, the layer drops out and comes back, and playback continues. The picture never jumps and the position is held, so it reads as a very short rebuffer rather than as a stall.

The device log names the whole mechanism. The producer cuts 3.000 s segments, and they finalize in PAIRS about 30 ms apart, one pair every 6.5 to 6.9 s:

15:55:34.708  live seg-17 finalized: start=51.033s dur=3.000s
15:55:34.736  live seg-18 finalized: start=54.033s dur=3.000s
15:55:41.251  live seg-19 finalized: start=57.033s dur=3.000s
15:55:41.277  live seg-20 finalized: start=60.033s dur=3.000s
15:55:47.864  live seg-21 ...

Measured gaps between bursts over one minute: 6.85, 6.52, 6.59, 6.50, 6.85, 6.53, 6.58, 6.77 s, with three short 3.4 to 3.6 s gaps mixed in. The upstream hands over roughly 6 s of media at a time and the cutter turns each delivery into two segments, so the source's own delivery interval is about 6.9 s at its widest. It is delivering 72 s of media in 64 s of wall clock, which is to say it is not behind at all.

TARGETDURATION is 4 s, so the client's unchanged-playlist patience, 1.5 x TD, is 6.0 s. That is the number sourceIsLateLocked uses to decide whether the SOURCE has stopped delivering, and every single ordinary burst gap is wider than it:

15:55:47.840  #446 the source has missed its cadence (quiet 6.56s, TARGETDURATION 4s); the consumer
              is at 19 of 21 with 3.0s of runway, and the window stays live until 12.0s of silence,
              or sooner if that runway would not carry the wait that far (5.4s of it left)
15:55:47.843  #446 the source stopped delivering with the consumer at 19 of 21 ... so the wait has
              run out of content rather than out of clock); serving the rest of the window as a
              finished asset (ENDLIST)
15:55:53.810  #2 didPlayToEndTime
15:55:53.810  #446 the window ran out and the source is delivering again; swapping the item

Then the same thing again at 15:56:17.90, and the same swap at 15:56:25.17. The item swaps land 31.4 s apart, which is the hitch the viewer sees. layer.isReadyForDisplay goes false for 47 ms and 134 ms across the two swaps.

So a healthy source is being judged by the client's patience. 1.5 x TARGETDURATION is the right threshold for withdrawing CAN-BLOCK-RELOAD, which is a statement about what AVPlayer will sit through, and it is the wrong one for "has the source stopped delivering", which is a statement about the source. Nothing in the session measures the source's own rhythm, so a source that is merely COARSER than its advertised target duration is indistinguishable from one that has died, and the close then costs an item swap every time it delivers normally.

The runway bound (AE#520) is not what fires here. It is asked only once the source is judged late, and with lateness read correctly none of these gaps reaches it.

Expected: a source that keeps its own steady rhythm never closes the window. An outage that misses that rhythm still does.

Reported on iOS 26.5, engine at the Sodalite#104 branch tip.

[superuser404notfound]

Released in 6.81.0 (b70e7660, merged as 11bb8a84). Both consumers are pinned to it.

[Simpendaal]

Quick follow-up on 6.84.0: the 6.81 fix works, about 35 of 40 gaps in a 45 minute session were absorbed silently. The window still closed 5 times, though, each time the silence ran just past the deadline (≈2× measured cadence, 7.6 s) while the consumer still held 5.8 to 8.5 s of runway, and the source resumed within a few seconds. Each close caused a visible item swap. Would it make sense to keep the window live as long as the runway covers the wait?

[superuser404notfound]

That question turns out to name the defect exactly, and the answer is sharper than "sometimes": the runway was never a second bound at all.

While the source is quiet the consumer keeps walking the window, so the content ahead of it and what is left of the deadline fall at the same rate. runway + silence is fixed for the length of an outage, so runway <= deadline - silence, which is how the runway bound was written in AE#520, is decided the first time it is asked and never changes its answer afterwards. For any consumer holding more than a deadline's worth of content it is false forever, and the deadline then closes the window on the clock with every second of that content still in hand. The two bounds shared one axis and the cheaper one always got there first.

Reproduced on the harness at TARGETDURATION 6, a viewer 30 s inside the window against a 22 s freeze:

[+ 67.44s] the source has missed its cadence (quiet 10.07s, it delivers every 4.00s); the consumer
           is at 15 of 22 with 24.0s of runway ...
[+ 77.47s] the source stopped delivering with the consumer at 15 of 22 (quiet 20.10s, 24.0s of
           runway left, past the 18.0s deadline ...); serving the rest of the window as a finished
           asset (ENDLIST)
[+108.72s] didPlayToEndTime -> swapping the item

Same runway at both ends of it, 24.0 s, and the source was delivering again two seconds after the decision. The five closes in the 45 minute session are that shape, with 5.8 to 8.5 s in hand instead of 24.

So the wait now ends with the content rather than with a clock. The window stays live while the consumer still holds more than one target duration of runway ahead of its own fetch point, whatever the silence has been. One target duration is what the close itself needs in order to arrive: a client polls an unchanged playlist about once per target duration with the blocking-reload advert withdrawn (measured at 0.81 x TD), and an ENDLIST that reaches a consumer with nothing left to play out converts a stall into an end instead of into a controlled swap. The only clock left is the one it does not share with the content: the producer gives up a source that cuts nothing after 35 s, and a window not closed a patience ahead of that would never be closed at all.

Measured, same command line in each pair:

arm	before	after
the reported shape (30 s inside the window, 22 s freeze)	ENDLIST, item swap	gap absorbed, no ENDLIST
AE#520's control (8 s inside, 12 s freeze)	gap absorbed	gap absorbed
a viewer at the edge (12 s freeze)	closes on the runway at 13.10 s with 4.0 s left	identical
a genuine 30 s outage, at three depths	position held	position held, never POSITION LOST

The new reading is uniformly more patient than the old one, apart from the last poll before the old deadline, where a runway already under the reserve now closes one poll earlier than a clock that was about to close it anyway.

One diagnostic came out of this too: the line that reports an absorbed gap now states the widest silence and the lowest runway of the episode against the reserve, so a gap that was comfortable can be told apart from one that nearly closed without another round of captures.

Built as 1ff5612a on fix/523-close-on-content-not-clock, not released yet. A note will follow here when it ships.

[superuser404notfound]

Released in 6.87.0 (1ff5612a, merged as 40f0127e). Both consumers are pinned to it.

[superuser404notfound]

A second round of the same shape landed in 6.88.0 (56953aff), and it matters for the gaps this issue is about.

6.87.0 measured the wait against the runway the window LISTS above the consumer's fetch point. That leaves out everything the consumer has already fetched and still holds, which near the live edge is most of what it has: measured at TARGETDURATION 6, a window closed on 4.0 s listed while AVPlayer held another 4.9 s, and the source delivered again 1.84 s later. The close spends the full depth now, listed plus held, so a short delivery gap has roughly twice as much content to be waited out with as it did in 6.87.0. The reserve it keeps in front of itself, and the ceiling, are unchanged.

Both consumers are pinned to it.