A bursty upstream eats the join cushion, and one minute in the session rebuffers once

[superuser404notfound]

A direct-ingest live channel plays for about a minute and then rebuffers once, briefly, with the source never actually stopping. Captured on iOS 26.6 against Red Bull TV (rbmn-live.akamaized.net, 6 s upstream segments).

The upstream publishes 6 s of media per batch, but not every 6 s. Measured from one minute of live seg-N finalized lines, the interval between batches:

6.66  6.66  9.86  6.56  6.84  9.80  3.55  6.85

Each batch delivers exactly 6.0 s of media, so the deficit per batch is gap - 6, and it ACCUMULATES:

0.66  1.32  5.18  5.74  6.58  10.38  7.93  8.78

The chain's total slack is 12 s: the ingest joins 1.5 x upstream TARGETDURATION behind the upstream edge (2 segments, [HLSIngest] joined 2 segment(s), ~12s behind the live edge), and AVPlayer then joins at our own 3 x TD holdback, which on a 12 s window is the start of it. An AVPlayer playing at 1x therefore eats that slack at the rate the deficit accumulates, and at 10.4 s of it the runway is gone:

17:30:14.560  #446 the source has missed its cadence (quiet 9.55s, it delivers every 6.84s);
              the consumer is at the end of what the window holds, so there is no runway
17:30:17.303  #1 playbackStalled
17:30:17.305  #1 timeControlStatus=waitingToPlay reason=AVPlayerWaitingToMinimizeStallsReason t+56.21s
17:30:18.678  #1 timeControlStatus=playing reason=- t+57.58s

1.4 s of stall, 57 s into the session, with the source delivering normally either side of it. HLSPlaylistTracker's own doc states the intent the 1.5x term was chosen for: "at least one upstream cadence of buffer across the bursty inter-batch arrival gap". One cadence is the right unit and one of them is not enough: this source's gaps run 10 to 65% over its segment length, repeatedly and in the same direction, so the deficit is cumulative rather than self-correcting.

The same log shows the second half of it. TARGETDURATION sealed at 4 s from measured floor 6.000s, which is the upstream's ADVERTISED segment length, and the arrival meter later reads the true rhythm as 6.84 s:

17:29:21.469  live TARGETDURATION sealed at 4s (holdback 12.000s): max EXTINF 3.000s,
              1.5 x cut target 0.750s, measured floor 6.000s needs 4s of patience;
              upstream advertises 6.000s (reported, not used)

1.5 x 4 = 6.0 s of client patience against a 6.84 s rhythm, so AVPlayer drew -12888 Playlist File unchanged three times in the captured minute. The advertised duration bounds the cadence from BELOW (a batch cannot arrive faster than it is cut, but it can arrive later), and it was used as if it bounded it from above.

Both halves are the shape AE#523 fixed one level up: a number derived from the nominal segment length where the measured delivery rhythm was the honest input.

Expected: a source that keeps delivering, however unevenly, does not rebuffer, and does not make the client draw -12888 on its ordinary rhythm.

The cost of the obvious fix is latency behind live and is worth stating: covering three upstream cadences instead of one and a half puts the viewer one upstream segment further back. HLSPlaylistTracker's own A/B says first picture does not pay for it (both arms fetch to the same upstream segment at the same wall clock, the backlog is caught up at I/O speed), so the cost is the standing distance from live and nothing else.

[superuser404notfound]

Correcting the account above before anyone builds on it. The batching numbers are right and the conclusion drawn from them is not.

Reconstructing where the playhead actually sat, from [AVKitLayer] sample (clock=0.67 at t+1s, 1.68 at t+2s, 2.69 at t+3s, so the item plays 1x from media 0 with no jump) against the newest finalized segment:

• 17:29:21.6, playback starts: newest cut media 15.0 s, playhead 0. Cushion 15 s.
• 17:30:05.0: newest 57.0 s, playhead about 43.4 s. Cushion 13.6 s.
• 17:30:14.6: newest 57.0 s, playhead about 53 s. Cushion about 4 s, and the consumer is at the end of what the window holds.
• 17:30:17.3: playbackStalled.

So the cushion did not fall to zero because of one 9.8 s gap. It eroded from 15 s across the whole minute, and the 9.8 s gap was merely the excursion that finished off what was left. Summed over the eight batches the deficit is only 3.2 s, which does not account for the 11 s that went missing, so the erosion has a term this log does not name.

What also does not fit the simple story: AVPlayer's own fetch point tracked the newest segment rather than sitting a holdback behind it (it fetched seg-18 at 17:30:11.6 while the playlist offered nothing newer), and avBufAhead read 2.5 s at t=30 s and 7.7 s at t=60 s against a 12 s holdback. A client keeping 3 s of fetched runway on a 12 s holdback is either not honouring the holdback or has already caught up to the edge, and the difference between those two decides the whole fix.

Joining deeper therefore buys time before the same thing happens rather than preventing it: a cushion that is set once at join and only ever erodes runs out on any source that publishes slightly slower than real time for long enough, whatever it starts at.

The next step is a measurement rather than a patch: publish the cushion (edge - playhead, and the client's own loaded runway) once a second for the life of a live session, and read the erosion curve. That separates the two candidates directly. A persistent rate deficit means the session has to rebase periodically and no constant will do; a jitter excursion against a healthy average means a deeper cushion is exactly the answer and the only question is how much latency it is worth.

The -12888 half of the report stands as written: 1.5 x TARGETDURATION is 6.0 s of client patience against a measured 6.84 s arrival rhythm, sealed from the upstream's advertised segment length, which bounds the cadence from below and was used as if it bounded it from above.

[superuser404notfound]

Fixed and verified on the reporting device, 92 s on the same channel with the same upstream.

The cause was the delivery meter reading a backlogged join as the source's rhythm. A backlogged origin hands over its whole window at I/O speed, the cutter finalized five segments in 55 ms, and every sample the meter held was an interval INSIDE one delivery: it reported it delivers every 0.04s for a source delivering every 6.5 s. Dropping the single worst sample, which is what keeps one outage from teaching the meter patience, then threw away the only real interval there was. So the first ordinary quiet stretch read as an outage, the window closed, the served edge froze, and the playhead ran off the end of it at 1x into an item swap fourteen seconds in.

Two changes. An interval under 0.25 s is the same delivery, not the next one. And the lateness question also reads the ingest's own arrival meter, which is the better measurement and the earlier one: a delivery there is a playlist refresh that brought new segments, it carries no intra-delivery intervals at all, and on this session it had read 6.000 s before the provider had finalized its second segment.

The verification run carries none of the lines this issue is about: no has missed its cadence, no ENDLIST, no didPlayToEndTime, no item swap, no playbackStalled, and no -12888. The one #446 source stopped delivering line that remains is the CAN-BLOCK-RELOAD withdrawal, which is the cheap half and latches once per session by design.

What the healthy shape looks like, from the probe, and it corrects the reading in the comment above: the published edge already carries the holdback, so a NEGATIVE cushion against it is the normal operating point rather than a deficit. The playhead sits between 5 and 13 s behind the newest cut and sawtooths by one delivery interval as each batch lands, while the fetched runway holds between 3 and 8 s. The margin at the bottom of that sawtooth is about 3 s, which is why a regression in the close logic showed up on the very first quiet stretch.

Still open here, and worth its own decision rather than a patch: fastZap bounded start served a 9 s window against a 12 s holdback on both captures, so AVPlayer joins with no holdback cushion at all. That is a zap-latency trade, not a defect, and it wants measurements from more than one channel.

[superuser404notfound]

Released in 6.81.0 (22aaf35d, merged as 5dc27b42). Both consumers are pinned to it.