An unsatisfiable blocking reload starves a client whose cache already holds its runway

[superuser404notfound]

Split out of #442, where it is the step before the one that was reported. Measured on the harness, not from a device log.

What happens

A live session with a DVR window, viewer parked inside it, upstream stops delivering (connection stays open, no further bytes). Every segment ahead of the playhead is already in the segment cache and the local server would hand it over instantly. Playback stops anyway.

  state=playing t=60.90s edge=253.40s behind=192.50s range=1.4...253.4
[+251.96s] [NativeAVPlayerHost] #1 playbackStalled
  state=playing t=61.31s edge=253.40s behind=192.09s range=1.4...253.4
[+257.44s] [HLSLocalServer] -> 503 /media.m3u8 reason=blocking reload msn=54 unsatisfiable
[+257.45s] [NativeAVPlayerHost] #1 errorLog code=-16849 ... 'HTTP 503: Service Unavailable'
[+258.18s] [AetherEngine] #65 re-engaging stalled AVPlayer (stall + 6s without fetches): nudge seek to 59.91s

range=1.4...253.4 is the resident range since AE#441, so this is not the window overstating what the cache holds. The client is 192 s behind live with 192 s of resident content in front of it, and it stalls.

Mechanism

AVPlayer refreshes the playlist with a blocking reload (?_HLS_msn=N). Once the source stops, that request can never be satisfied, so the server holds it for liveBlockingReloadHoldSeconds and then answers 503, which is what RFC 8216bis asks for and what #167 put there. While that request is outstanding AVPlayer issues no segment requests at all, and its forward buffer is 4 s deep by our own forwardBufferDuration. From a second run, timed off the same log:

• +89.18 poll for msn=24 goes out
• +93.21 last segment fetch
• +102.12 playbackStalled, buffer drained
• +107.19 the hold expires, 503 goes back: 18.0 s, exactly 3 x TARGETDURATION (TD=6)

liveBlockingReloadHoldSeconds already carries the rule this violates: "A hold that outlives AVPlayer's ~4 s forward buffer guarantees the stall it exists to prevent." That was written about the old hardcoded 18 s under fastZap. On a stalled source 3 x TD reproduces it exactly, because the bound is only tight while the source still cuts segments.

What ends it

Two things, both accidental:

• our own #65 re-engage nudge, one stall-recovery window later, which buys about two segments before the next hold parks it again;
• AVPlayer demoting itself. After one -15410 'Invalid server blocking reload behavior for low latency' at +124.34 it stopped sending _HLS_msn entirely, and the same frozen source then played the whole cached runway continuously (40+ s, no stall, only harmless -12888 playlist-unchanged entries).

So the error the 503 exists to avoid is, on this path, the thing that restores playback.

Why it matters

This is the entry point of #442. A viewer parked minutes behind live does not need the newest playlist at all, but the hold starves them anyway, the stall escalates through the recovery ladder, and by the time #93 item death fires there is a position to lose. Fixing where the recovery rejoins (done, #442) does not stop the source freeze from stopping playback for someone who had everything they needed on disk.

Not fixed yet, and why

The obvious move, answering the unsatisfiable hold with the current playlist instead of holding, is exactly the -15410 case #167 put the 503 there to avoid. The measurement above says that particular -15410 is benign and in fact recovers, but that is one Mac run against a synthetic source, and #167 came off a device. Withdrawing CAN-BLOCK-RELOAD once production has halted has the same delivery problem: the client cannot learn about it without a response it will accept.

Wanted before building: a device run that says whether a fast 503 (bail immediately when liveProductionHalted, no hold) is enough to keep the fetch loop alive, or whether the advertisement itself has to go.

Reproduction

swift run aetherctl live --realtime --preroll 30 --dvr-window 1800 \
  --freeze-after 150 --rewind-before-freeze 120 --seconds 260

--freeze-after leaves the connection open and stops delivering, which is how a dead upstream usually looks and is a different failure from --drop-after's RST.

[superuser404notfound]

Built and released in 6.54.0, though not by the route this issue proposed, and the fd logging above settled the question I opened it with.

The connection is not the problem. The request log now carries the fd, and during a hold the two links are visibly separate: playlist polls on one, segment fetches on another, the segment one idle for the whole eighteen seconds with nothing to stop it. AVPlayer simply does not fetch while a blocking reload is outstanding, so the only lever is not to hold.

Rather than answering an unsatisfiable hold with a stale playlist, which is the exact -15410 the #167 follow-up put the 503 there to avoid, the session withdraws the advertisement. That is the same policy liveProductionHalted already applies, moved one watchdog earlier: today it turns CAN-BLOCK-RELOAD off for the rest of the session, but only once the no-cut watchdog has run at 35 s, and the starvation starts within ten. The new signal is delivery latency measured at the provider, 1.5 x TARGETDURATION because that is AVPlayer's own patience for an unchanged live playlist, latched for the same reason #167 latched. A poll already in flight when the source died now wakes in one second slices instead of riding out the whole bound.

before   withdrawal never, first fetch back at +108.2, two stalls in the outage window
after    withdrawal at +98.2, first fetch back at +99.3, none

playbackStalled across the run 3 to 1, and no -15410 at all: the withdrawal produces the same demotion deliberately, one 503 and a playlist that stops claiming what it cannot deliver.

Two things keep this open rather than done.

The first is that the fix has only a Mac run behind it, and #167 came off a device. What a device run should show is the withdrawal line appearing within ~10 s of a real source going quiet, no -15410, and plain GET /media.m3u8 polls with segment fetches continuing between them.

The second is the ceiling, which the same runs made visible. Once the playlist stops changing altogether AVPlayer parks regardless of any of this, and the no-cut watchdog then hands the session to the host with the producer is starved, not the consumer. So a viewer cannot ride out an arbitrarily long outage on cache alone. Serving the remaining cached window as a finite playlist once the source is confirmed dead would be the lever for that, and it is a larger question than this one: it ends the live session semantically, and the DVR window would have to be re-served with an ENDLIST while the host still believes it is watching live.

[superuser404notfound]

Reproduced, and the cause is not where either of us was looking.

Harness shape, matched to yours as closely as a fixture can: 1x paced origin, DVR window, viewer parked
146.86 s inside it, then the upstream freezes with the connection held open. 36 segments resident ahead
of the playhead, none of them fetched yet.

+200.0   FREEZE   playhead 34.62s   edge 181.48s   runway 146.86s resident
+205.7   #446 source stopped delivering; withdrawing CAN-BLOCK-RELOAD
+206.7   seg10   -12888 Playlist File unchanged for longer than 1.5 * target duration
+207.1   seg11
+211.2   seg12   ... one per playback interval, and a -12888 on every poll between them
+223.2   seg15   <- the last request of the session
+226.7   two polls, then silence
+232.2   playbackStalled, 115 s of runway resident

So the fetches do continue past the outage, which is what #446 bought, and then AVPlayer strikes out on
its own unchanged-playlist watchdog and stops asking for segments it has never downloaded and that are
listed in the playlist it just read. Six -12888s is where it gives up, here and in every arm.

Three things I can now rule out, all measured rather than argued:

• It is not low latency. An arm that never advertised CAN-BLOCK-RELOAD at all behaves the same:
  78.57 s of a 150.86 s runway, then the same silence. So withdrawing the advertisement is not too late,
  it is simply not the lever.
• EXT-X-SODALITE-REFRESH never worked. That tag exists in this server precisely to keep
  consecutive polls distinct against -12888. Curled live during the freeze, two polls 4 s apart differ
  in that line and nothing else, and -12888 fired on both. AVPlayer's unchanged test reads the parsed
  playlist, so a tag it does not know cannot count. The comment claiming otherwise is corrected.
• A sliding MEDIA-SEQUENCE does not count either. I built the obvious fix (keep the window sliding
  on the clock while the source is late, one segment per TARGETDURATION, hard-stopped at the consumer's
  fetch point) and measured it: identical -12888 cadence, strike-out in the same second, and it spends
  the viewer's rewind depth for nothing. Reverted. What AVPlayer watches is the TAIL of the playlist.

And the part that reframes this issue. When the playlist finally does move again, AVPlayer rejoins at
edge-minus-HOLD-BACK by itself. Measured forward step 117.76 s, with no recovery line of ours anywhere
near it. That is a second way to lose a rewind position, independent of the reload policy #442 fixed,
and it is only invisible in your run because your playlist never moved again.

What does move it is the one thing that is also true. While the source is not delivering and the
viewer still has resident segments ahead, the window is not a sliding live playlist, it is a finite
asset, so it is served as one: #EXT-X-ENDLIST, no SERVER-CONTROL, same MEDIA-SEQUENCE, every segment
still listed. Same fixture, same seed, viewer 149.96 s inside the window when the source froze:

                       advance after the freeze   fetches   -12888   item deaths   largest step
before                 24 s, then silence          6         5+       3             117.76 s
without CAN-BLOCK-RELOAD  78.57 s, then silence    18        yes      0               1.10 s
window slides on the clock 48.10 s                 45         5+      3             117.66 s
ENDLIST                166.75 s, the whole runway  40         0        0              1.10 s

Two consequences had to be built with it, because ENDLIST is not free, and both of them bit before they
were right:

• An item that has seen an ENDLIST never reloads its playlist again, so the source coming back needs an
  item swap. What counts as "coming back" has to be the exact complement of what closed the window. My
  first version asked whether one more segment existed than at closing time, and a dying source cuts a
  last partial segment on its way out, so it swapped into a window that was still closed and landed the
  viewer 180 s below the place it was supposed to hold. It now asks whether the source is delivering.
• didPlayToEndTime at the end of such a window is not an end. .ended is terminal here, so forwarding
  it would turn a source hiccup into a dead session. It now either swaps the item or holds the session
  live and watches for the source to cut again. The swap carries the held position explicitly, because a
  finite asset's distance-behind-live reads zero by construction and the A live reload with a DVR window should be able to rejoin the pre-reload playhead instead of the edge #442 policy would aim at the
  edge on that reading alone.

Measured end to end, viewer 60 s inside the window and a 20 s outage: the runway plays out with no
-12888 and no item death, then the source returns and the session is live again at 131.32 s, 92 s behind
the edge, which is where it was. --unfreeze-after is new in the harness for that leg; without it the
recovery path could not be driven at all, which is why it had never run.

Merged on main in 20eaeed3; it rides the next tag along with the #443 window sizing.

The ceiling I flagged before is unchanged and worth repeating: this makes the runway reachable, it does
not make an outage survivable past the runway. When the last resident second is played and the source is
still down, the viewer waits, as they would have. Measured that too: the session sits there holding its
last frame rather than ending.

[superuser404notfound]

6.55.0 carries 20eaeed3, and one thing about the re-run is worth flagging before it: the freeze in your 6.54.0 capture was this engine's own park, the AE#443 defect, which is also in this tag. Your fixture may therefore not reach an outage at all on 6.55.0 unless it freezes the source deliberately.

When it does: the stalled window is served with an ENDLIST while the source is not delivering, same numbering, every segment still listed, so the resident runway is fetchable instead of being abandoned after ~6 x -12888. Measured on the harness with a viewer 149.96 s inside the window, 166.75 s of playback against 24 s before, no item deaths. A source that comes back is picked up with an item swap, so the place is kept, and didPlayToEndTime at the end of such a window is not forwarded as .ended.

The device run is still the one I would like most, since #167 came from a device and this touches the same advertisement.

[cmcpherson274]

Ran the two 6.55.0 fixture legs on our side — seeded not with a synthetic sample but with a 90 s capture of our own live source (real broadcast TS). One green, one red, and the red half's mechanism is measured.

The runway half: PASS, matching your numbers. --dvr-window 1800 --freeze-after 300 --rewind-before-freeze 150 (no thaw):

playhead at freeze: 432.50s (152.05s behind the edge)
advance after freeze: 168.97s   largest forward step: 1.10s
itemDeath=0 edgeRejoin=0   final state: paused (holding the last frame)
VERDICT: live-freeze position held

The whole runway plays out under the ENDLIST serve, no -12888 strike-out, and the session parks rather than dies — your 166.75 s on our seed is 168.97 s. Zero timeline-rebase or discontinuity lines across the run (which wraps the seed ~6×, so the fixture's loop is timestamp-continuous — that matters below).

The recovery half: the place is lost — BACKWARD, into ~47 s of repeated content, and the log measures the mechanism. --rewind-before-freeze 60 --unfreeze-after 25:

The harness verdict prints POSITION LOST (forward step 114.50s), but that number is a 1 Hz tick sampled inside the ~130 ms between the item swap and its deferred seek, on a mixed shift axis — please disregard it (the leg may want to skip samples between swap and a pending deferred seek). What the log establishes:

1. The swap is gated on didPlayToEndTime (fired the same instant, +379.50; the runway leg proves the gate is the runway ending — its didPlayToEndTime fires with the source still frozen and takes the hold branch). The consumed runway was 78.98 s (523.50 → 601.51) — the runway=61.05 printed at freeze is behind-at-freeze and understates the asset by the ~18 s of segments that finalize after the freeze.
2. The swap's deferred seek LANDS: replaying deferred pre-ready seek to 602.48s (#127) → seek#2 programmatic landed rendered=602.48 target=602.48.
3. And it lands ~47 s of content BACKWARD. A timeline rebase fires at the thaw (video timeline rebase (live): jumpTicks=4415339 = 49.06 s; prodShift 271.90 → 320.95 while hostShift lags), and the swap's seek converts the held position through the NEW shift — its own line says so: live seek target=602.48 behind=116.35 seekableEnd=397.882 — re-entering a place the last tick recorded at behind=0.00 at 116 s behind. First post-seek tick: t=554.30s = 602.48 − 49.06 − ~1 s of playback; steady ticks climb from there. Axis-free proof: item HDR10+ and Dolby Vision missing dynamic metadata #2 re-fetches seg63 through seg72 — ten segments item Add option to route video via AVPlayer instead of AVSampleBufferDisplayLayer #1 had already fetched and played. The viewer re-watches ~47 s.

So the held position is an old-axis number applied post-rebase — and a rebase at resume is not a fixture artifact: a real outage always resumes with a PCR jump (the tuner loses the broadcast seconds). One genuine fixture question remains for you: the jump is 49.06 s against a 25 s outage and a timestamp-continuous ~93 s loop — neither matches, so where the 49.06 comes from in --unfreeze-after is worth a look on the harness side too.

Happy to re-run any parameterization — the seed + both logs are archived. (The device run you asked for is still owed from us: it needs a source we can silence on demand in front of the real app — the current plan is a dispatcharr custom channel fronting this same Mac fixture, so the app tunes it as an ordinary channel and the fixture's freeze/thaw drives the outage.)

---

Edited same hour after our review pass: the first posting led with the harness's +114.50 s "forward" figure (a mixed-axis single sample — the measured outcome is the ~47 s backward re-entry above), presented the rebase conversion as speculation when the log measures it, mis-stated the swap trigger and runway arithmetic, and blamed the thaw rebase on a per-loop PCR splice the runway leg disproves. Direction, magnitude, and mechanism all corrected; the leg is still red.

[cmcpherson274]

The device run you asked for — the ENDLIST shape on real hardware, plus the recovery swap, both at 6.55.0.

Setup. Apple TV 4K gen 3 (tvOS 26.6, build 23L773), engine 6.55.0 78735b04 inside our tvOS client (NativeAVPlayerHost path), fed through the same app-owned spool / custom IOReader you know from #445. The origin is your own LiveFixture (aetherctl live --serve-only --realtime --freeze-after …) behind a Jellyfin m3u tuner and a dumb relay, so the app tunes it as an ordinary live channel and DirectPlays the raw TS. Seed = a fresh 95 s real capture of the same HLN channel our earlier fixture legs used — same recipe (188-aligned, h264+aac), not the same file, so seed content/length is a free variable between those runs and these. Wall-clock and device-clock axes kept separate throughout; times below are device-log times, and freeze-relative numbers are anchored to the device-observed DATA STOP (the fixture's own freeze stamp wasn't retained).

Leg 1 — freeze, no thaw (the #167-class advertisement question). Viewer timeshifted −31.8 s, source frozen mid-session (connection open, no bytes). Last delivered segment finalized 19:35:03.4 (data stop, three-way derived: last finalize, the producer's own "no segment finalized for 35s" at 19:35:38.9, and the spool pull's 60 s timeout at 19:36:03.7):

• [VideoSegmentProvider] #446 the source stopped delivering with the consumer at 85 of 110; serving the rest of the window as a finished asset (ENDLIST) … — the fix fired on device with its own breadcrumb, ~4 s after the data stop.
• Real tvOS AVPlayer accepted the mid-stream ENDLIST, kept fetching, and played the runway out to didPlayToEndTime — +27 s past the serve, ~31 s of playback past the data stop, ending on a cleanly held frame (capture stills on file). No unchanged-playlist strike-out, no stall-park, no item death. That answers the advertisement concern on hardware as far as our bench can take it.
• Aftermath, and one engine-side fact you'll want: the viewer-visible teardown was our app's live policy (spool-pull timeout → reconnect ladder → visible retry), and it won the race by ~4 ms — but your producer independently aborted at hold+4.6 s on its own 35 s no-cut-stall rule (no-cut stall: no segment finalized for 35s … aborting the source read and exiting for host retune, then HLSVideoEngine … requesting host retune to the server route at +29 s). So the An unsatisfiable blocking reload starves a client whose cache already holds its runway #446 "holding the session live … (this is not an end)" state has an engine-side expiry ≈35 s after the last cut; Leg 2's swap came only 3.1 s into its hold, so that leg never exercised it.

Leg 2 — freeze 100 s, unfreeze 30 s later (the recovery swap). Same shape, viewer −31.7 s:

• The full round-2 machinery ran: ENDLIST serve → didPlayToEndTime → #446 the window ran out with the source still down; holding the session live and watching for the source to cut again (this is not an end) → thaw → #446 … the source is delivering again; swapping the item so the session is live once more, at 139.18s, the place it held → new item playing live.
• Zero reconnects and zero pull deaths across the whole arc; the app's stall counter ticked once — that one stall IS the ~3.3 s held frame across the swap (rate 0 between didPlayToEndTime and the new item playing). A 30 s outage cost the viewer the runway play-out plus that ~3 s hold. As an outage experience this is genuinely good.
• The backward / repeated-content mode from our earlier report did not reproduce at 6.55.0. Verified at segment granularity: the consumer had fetched through seg109 pre-swap; post-swap fetches resume at seg139+; seg110–138 show zero fetches anywhere in the log. (Caveat for your reasoning: the seed is a fresh capture, not the byte-identical one from the earlier report's legs.)

The one finding — the swap position. The timeshifted consumer (−31 s, consumed through seg109) was joined at seg139 ≈ the post-burst window end / live edge: ~29 s of content skipped and the timeshift discarded. Two attribution checks so it lands on the right component: (a) the fixture does not skip content at thaw — the serve loop parks at its packetIndex while frozen and the wall-clock pacing gate then bursts the backlog, so seg110–138's content was delivered; (b) the burst shows up consumer-side: five segments (seg139–143) were fetched from the engine's local HLS server within 0.2 s at swap time — i.e. the producer had already cut well past the gap when the swap placed the join. So the edge-join is the engine's swap placement. If joining the live edge after an outage is the intended live-mode policy, that's defensible — but the breadcrumb's "the place it held" doesn't describe what happens to a timeshifted consumer, and for a rewound viewer it means both skipped content and a silently reset timeshift. Your call whether that's a label fix or a placement fix; happy to re-run either way.

Incidental confirmation while we were here: the #440 join lever's breadcrumb (cutting the stall-avoidance wait short at rate 1.0 (buffer ahead 4.99s)) fired on this leg's initial tune — as it did on every live join across this session's device legs (17 sightings, buffer ahead 4.20–4.99 s): consistent engagement on hardware.

[Edited same evening: our adversarial review round caught five errors in the first posting — tvOS version (26.6, not 26.5), the seed described as the same file when it is a fresh capture of the same channel, freeze-relative numbers anchored to an unretained fixture stamp (now anchored to the device-observed data stop: "14 s" → ~4 s, "~41 s" → ~31 s), a "zero stalls" overclaim in Leg 2 (one stall counted — the held frame across the swap), and a false "first time on hardware" on the #440 lever sighting. The Leg-1 aftermath bullet also now discloses the engine-side 35 s no-cut expiry we originally folded into "app policy".]

[superuser404notfound]

Both device findings reproduce on the harness, and they are two defects plus one the counter-run turned
up, none of them the placement policy they look like. The segment-level accounting in particular is what
made the first one findable: it could not have been settled from a seconds axis, for reasons the last
section makes concrete.

The swap position: an incoherent conversion, not a placement

The rejoin does carry the held position. What it does with it is convert session time into the item's
own clock, and it did that by subtracting the PUBLISHED live edge from the item's seekableEnd sampled
now. Those two describe the same state only while both come from the same epoch, and a rejoin runs in
the two moments where they do not.

During an outage the published edge FREEZES. The item that has seen the ENDLIST never reloads its
playlist, so nothing advances the edge, while the playhead legitimately runs on through the runway. By
the time the runway ends, the held position sits ABOVE the edge the window still advertises. The clamp
pulls the target back down onto that stale edge, the distance behind live collapses to zero, and "zero
behind the edge" converts into the fresh item's own seekableEnd, which after the backlog burst is the
live edge. That is seg139 with the timeshift gone.

The earlier Mac leg was the same defect in the other direction: an edge published on a post-rebase shift
against an item still presenting the pre-rebase one lands the seek backward by their difference. Which
of the two a run gets depends on whether a 1 Hz publish tick landed between the item swap and the
deferred seek, which is why the first harness run of this shape landed correctly and the device did not.
A race, not a policy.

Fixed by taking one sample. The edge comes from the item being seeked rather than from the running
maximum the window keeps across ticks, and the session-to-item conversion is now the seam-aware one the
engine already uses for scrub thumbnails (PresentationAxisMap.itemSeconds), which reads the shift that
was in force for THAT position instead of the newest one the producer has moved to.

Measured, 76 s outage, viewer 62.9 s inside the window, on a run whose reconnect happens to carry a
28.7 s source seam:

live seek target=181.41 clockTarget=180.01 seekableEnd=198.375 shift=30.025 publishedEdge=228.4
across the swap: consumed through seg35, resumed into seg33,34,35,36, never fetched 0 segment(s)

The same numbers through the old form: behind = 228.40 - 181.41 = 46.99, clockTarget = 198.375 - 46.99 =
151.38 against the correct 180.01, so 28.6 s of already-watched content, which is exactly that seam. The
seg33-35 above are the landing's own backward buffering rather than a re-entry: the seek landed at item
180.01, the start of seg36.

If the archived device log still has it, the line that confirms this reading is
[AetherEngine] live seek target=... behind=... at the swap: a behind near zero for a viewer who was
31 s back is this clamp and nothing else produces it.

The 35 s expiry: not only an expiry

Reproduced, and worse than the hold's promise being too long. Harness, 76 s outage:

+150   freeze, viewer 62.9s inside the window, 81s of runway resident ahead
+185   no-cut stall: no segment finalized for 35s ... aborting the source read and exiting for host retune
+226   the source delivers again  <- nothing is reading it, so nobody sees
+231   the runway ends; the session holds its last frame for the rest of the run (final state: paused)

The read was abandoned while 46 s of runway were still being handed to the consumer, and that abort is
what made the source coming back unobservable. So the wait was not merely bounded at 35 s, it was ended
before the outage was over by something that had nothing to do with the outage.

The starvation exit now defers while the closed window still has segments above the consumer's fetch
point, bounded by the hold budget that already exists (liveSlowDeliveryMaxHolds), and says so:

[HLSSegmentProducer] #446 outage hold 1/6: nothing cut for 35s (rate=0.4pkt/s), and the closed window
is still feeding the consumer; keeping the source read so the source coming back can still be seen

Same leg after: the read survives, the thaw at +226 is seen, the swap lands at +231, zero segments
skipped, the session is playing at the end. The deferral only lasts while pictures are still being
delivered, so a viewer whose runway has run out waits at most one more watchdog window than before. A
cutter wedge is untouched: it reads at full rate and waiting does not fix it, so it still exits at its
own 10 s timeout.

The ceiling from Leg 1 stands, and is now stated where it belongs. With a 150 s outage the runway ends
at +231, the budget is spent at +255, and the session is handed over rather than left claiming to watch:

#446 the outage wait ends here: the source read was given up, so nothing can observe the source
cutting again; the session is the host's to retune
#446 the window ran out and the source read is already given up; holding the last frame

The third one, found by the counter-run

That 150 s leg also caught something round 2 had described and only half closed. The no-cut exit
finalizes a last partial segment in the same millisecond as its abort:

+255.31  no-cut stall ... aborting the source read and exiting for host retune
+255.32  live seg-36 finalized: start=180.000s dur=4.000s

That flush refreshes the finalize timestamp, so liveOutageProductionResumed, which asks whether the
source is late, reads "delivering again" for one cadence, and the outage watcher swapped the item into a
window whose source was dead. Exactly the shape the round-2 comment warns about, reached by a different
route. A source read that has been given up now blocks both the swap and the watcher, which is the line
pair above.

The #65 breadcrumb also names which of the two positions it used now, since a window closed with
ENDLIST reads zero behind live by construction and printing that next to a carried position said nothing
true about a timeshifted viewer.

The 49.06 s, and why the leg judges in segments

It is the harness, and it is worth keeping. The reader reconnects during a freeze (its own stall
reconnect, and again while the source stays quiet), and LiveFixture.serve() starts every connection at
PACKET 0 of a loop index derived from wall clock and the high-water mark. The remainder of the loop the
parked connection had not reached is therefore skipped, and it reaches the engine as a genuine source
discontinuity. On the bundled seed the same leg produces 28.7 s (video timeline rebase (live): jumpTicks=2580000); on a 93 s capture it is a remainder of up to 93, and 49.06 is one. A tuner that
resumes loses broadcast seconds the same way, which is why that arm is the one that exposed the backward
half of the conversion defect. The fixture now says it on every reconnect instead of leaving it to be
derived.

It does mean the leg's seconds-based verdict cannot be read: the playhead steps by the seam without
losing anything, and the same run reports largest forward step 29.63s while skipping nothing at all. So
the freeze leg reports and judges in segments now, the way the device run did, measured against the
LOWEST index fetched after the swap rather than the highest (a fresh item probes its own live edge once
before the stashed seek lands, so the highest says where the playlist ends, not where the viewer
resumed; counting the holes below it invented six skipped segments out of a run that had simply ended).

It fails on any segment the window listed that the consumer had not reached and the rejoin jumped over,
on a re-entry deeper below the held place than the landing's own backward buffering explains, and on a
run where the source delivered again while the engine still held the read and the session never went
live. That last one is Leg 1's aftermath, and it read green on every seconds-based number before: the
playhead had not moved, so it had not moved wrong. Where the read was given up after the runway ran out,
the leg names the hand-off instead of failing, because that is the ceiling rather than a defect.
--unfreeze-after is documented now too.

Merged on main in b0d0b20 (the engine half) and f76b794 (the harness half); they ride the next tag.

What would settle it from the device side, whenever convenient: Leg 2 again on the next tag, same
timeshifted shape, and one leg with an outage longer than the runway, which is the hand-off above rather
than a recovery. And thanks for the #440 sighting count. Consistent engagement across 17 joins is a
better answer than this harness can give, since the wait it cuts short does not reproduce on loopback at
all.

[superuser404notfound]

Shipped in 6.56.0, all three legs of round 3: the rejoin's position converted from one sample rather than from an edge and a seekableEnd sampled in different epochs, a starvation verdict that defers while the closed window still holds segments above the consumer's fetch point, and a read that has been given up blocking both the swap and the watcher instead of being polled.

Worth capturing on a device retest, in segments rather than seconds: whether the rejoin skips any segment the window listed and the consumer had not reached, and whether an outage long enough to spend the hold budget hands the session to the host instead of swapping into a dead window. The harness legs are 25 s and 76 s with zero skipped, and 150 s handed over.

[superuser404notfound]

Field evidence for the rejoin arrived on day one, from the #447 retest run on 6.56.0. Twice in one session the window ran dry and the source came back, and both times

#446 the window ran out and the source is delivering again; swapping the item so the
session is live once more, at 12724.46s, the place it held

That is the leg the harness could only show against a scripted origin, so having it on a real portal with a real outage is worth recording here.

The same run also has the shape this does not cover, and it is worth naming rather than leaving to be found again. On a 0.960 s channel the source stopped 1.6 s after the first manifest was served, at a join, so nothing was resident ahead of the viewer:

first live manifest served after 0.151s: 4 segments / 3.840s >= 3.000s holdback (TARGETDURATION 1s)
#446 source stopped delivering (no segment finalized for 1.6s, TARGETDURATION 1s)
errorLog code=-12888 domain=CoreMediaErrorDomain uri=.../media.m3u8

Then twelve seconds of nothing and the viewer left. Serving the stalled window as a finite asset is an answer for a viewer with runway ahead; a join has none by definition, so there is nothing to convert and the reload times out against a window that never grew. Whether anything better than that is available from in here is a separate question from this issue's rejoin, and I would want the finalize lines and the phase around it before deciding it is one.

[cmcpherson274]

The two device legs you asked for, on 6.56.3 6ca59c5e — plus one extra, because the hand-off leg's runway arithmetic has two branches and the second one is where your deferral fix lives.

Setup. Same stack as the 6.55.0 run: Apple TV 4K gen 3 (tvOS 26.6, build 23L773), engine pinned 6.56.3 inside our tvOS client (NativeAVPlayerHost path, app-owned spool / custom IOReader), your LiveFixture at the 6.56.3 checkout behind the Jellyfin m3u tuner and the relay. Times are device-log times; freeze-relative numbers anchor to the device-observed data stop (last full finalize); the fixture's freeze stamps were wall-clock-retained this session and corroborate each anchor within ~1 s (device↔Mac offset ≈0). Judged in segments per round 3, against the lowest post-swap fetch. The 6.56-only breadcrumbs below (the TARGETDURATION seal derivation, the outage-hold line, the #65 which-position note) are the on-device proof of the fix generation.

Leg 2 re-run — the timeshifted thaw (jump −30, freeze ~100 s, unfreeze +30): zero listed-and-unreached segments skipped

• Tune → spool jump committed −30 (settled behind 31.8 s of 60.1 s; post-join snapshot behind 31.2 s of a 61.1 s window).
• Data stop = last finalize seg-111 (the window listed 112 segments, seg0–111). Your detector at +3.0 s; ENDLIST serve at +4.0 s with the consumer at 87 of 112.
• didPlayToEndTime at data stop +30.8 s; consumer fetches reached seg111 — the closed window's true end.
• Hold ("this is not an end") → thaw → swap 3.0 s into the hold: swapping the item so the session is live once more, at 139.18s, the place it held. The new Presented frame drifts ~6 s ahead of currentTime/sourceTime after a rapid bidirectional seek burst (loopback-HLS native path) — frameAhead/producerShift/hostShift all report 0 #65 disclosure printed with it: carried across the swap: the window it played out under was closed, so its own distance behind live reads zero.
• Segment accounting: lowest post-swap fetch = seg140. Segments the window listed that the consumer had not reached: none (it reached seg111 of seg0–111). Skipped listed-and-unreached: zero. No backward re-entry. Zero reconnects, zero pull deaths across the arc; the app's stall counter ticked once — the ~3.2 s held frame between didPlayToEndTime and the new item's timeControlStatus=playing.
• The confirming line you pointed us at cannot appear on this stack, and the reason seems worth having on file: the swap's rejoin seek is policy-rejected before it would log. The arc here was replaying deferred pre-ready seek to 139.18s (#127) → seek(to:139.17997706944445) ignored: live, DVR disabled → seek#1 programmatic rejected(liveWithoutDVR) target=139.18 (quotes verbatim from the trace this time; the first posting rounded inside the backticks). Our client never enables engine-side DVR (rewind is the app-side spool), so the live item refuses programmatic seeks and the landing comes from the fresh item's own live join. In this shape the landing sat AT the carried target: by the finalize starts, 139.18 falls in seg-141 (139.144–139.878), and the lowest post-swap fetch, seg140 (starts 138.143), is the landing's own backward buffering just below it — so the rejection cost nothing here. But if a swap ever carries a held place that differs from the natural join point on a liveWithoutDVR item, the rejection would silently eat the placement. Flagging the interaction rather than asserting a defect; if the carried position went in as the reload's start position instead of a post-load seek, stacks like ours would be covered.
• Viewer axis, for completeness — with an honest scope note: the outage backlog (seg112–139, burst at thaw) was not fetched, and the −31 s timeshift ends with the closed window's exhaustion (behind-live for that consumer reads zero by your by-construction note). The zero-listed-and-unreached accounting above is fully derivable for the CLOSED window (it listed seg0–111 and the consumer reached seg111); whether the RE-OPENED window's playlist listed seg112–139 at the join is not derivable from our side — playlist bodies aren't logged in our trace — so that half of the classification is yours to adjudicate from the window semantics. Same viewer outcome as 6.55 on this exhausted shape either way; what 6.56.3 adds is that the breadcrumb now says which position it used.

New leg — outage longer than the runway (freeze, no unfreeze): handed to the host, no swap into a dead window, no lying park

• Same −30 shape. Data stop = last finalize seg-104 (window 105, seg0–104) → detector +3.0 s → ENDLIST +4.0 s (consumer 80 of 105) → didPlayToEndTime +30.7 s → hold → no-cut abort at +35.3 s (aborting the source read and exiting for host retune) with no deferral — correctly: the window had run out 4.6 s earlier, and the deferral only lasts while pictures are still being delivered.
• Zero swap lines after the hold — the given-up read blocked the swap and the watcher on device.
• Hand-off: our app's spool pull died on its own 60 s timeout at data stop +60.6 s, and the engine's requesting host retune landed 9 ms after the app's reconnect decision (10 ms after the pull-death line) — the same two-horse photo-finish as the 6.55 run (~4 ms then), both reaching the identical handover. The app's ladder then ran three re-tunes against the frozen origin (each: open 200, no first byte in 15 s, 20 s start budget expires) → viewer-visible retry screen at data stop +158 s (glass capture on file). Process alive at the terminal, zero fresh crash logs.
• Your new "outage wait ends here / already given up" line pair did not fire — in our ordering the window ran out before the read was given up, so the hold line and the abort line carried the story. Noting it so nobody greps for the pair in vain on this shape.

Extra leg — the deferral branch itself (jump −55, so the runway outlasts the 35 s check)

• Jump committed −55 (settled behind 56.9 s of 70.1 s). Data stop = last full finalize seg-126 (window 127, seg0–126); ENDLIST +4.0 s with the consumer at 77 of 127 — ~50 s of runway, this time past the no-cut check.
• Data stop +35.5 s: #446 outage hold 1/6: nothing cut for 35s (rate=0.8pkt/s), and the closed window is still feeding the consumer; keeping the source read so the source coming back can still be seen — your deferral, verbatim, on device, with ~20 s of runway still ahead. Sixteen consumer segment fetches landed during the deferral window; the last fetch was seg126, the window's true end, and didPlayToEndTime came at +55.9 s. At 6.55 this read aborted at +35 (we measured +35.6 s on the earlier device run) — the observability window now covers the whole runway.
• Then the ceiling, host-side: our pull's 60 s timeout at +60.3 s → EOF through the custom source → live custom-source pump exited (reason=eof); … requesting host retune 5 ms after the app's reconnect decision (6 ms after the pull death) → ladder → the same terminal retry screen. One structural note: on this stack the host's 60 s pull policy always preempts the engine's 6-hold budget, so the +255-style budget-spend shape is unreachable here by construction — the hold budget's tail is yours to verify, the first hold is now device-confirmed.
• The defect-3 flush shape also made an appearance and fooled nothing: the read's end flushed a final 0.5 s partial (live seg-127 finalized … dur=0.500s, at .830) within a millisecond of the pump exit (.831), and no swap followed.

Net: both requested legs pass the round-3 criteria on 6.56.3, the deferral's first hold is confirmed on hardware, and the one new item is the liveWithoutDVR seek-rejection interaction above, which in the exhausted-window shape is benign by coincidence of targets.

[Edited same morning: our adversarial review round corrected five details in the first posting — the seg-mapping of the carried target (139.18 is in seg-141 by the finalize starts, not seg139; the seg140 first fetch is the landing's own backward buffering, so the join landed at the target rather than "a beat later"); the "never listed in any window" claim scoped honestly (derivable for the closed window only — the re-opened window's playlist contents were not captured); "same millisecond" → adjacent milliseconds on the L4 flush; both photo-finish deltas restated with their exact anchors, and the seek-rejection quotes made grep-ably verbatim. No verdicts changed.]

[superuser404notfound]

Both requested legs read as passes here too, and the extra leg is the more valuable of the three: the deferral's first hold on hardware, with sixteen consumer fetches inside the window and the last one landing on the closed window's true end, is the half the harness could only assert. The scope note on the re-opened window's playlist contents is the right call; that half is not derivable from a trace that does not carry playlist bodies, and saying so is worth more than a verdict that quietly assumed it.

The liveWithoutDVR interaction was flagged as an interaction rather than asserted as a defect. It is a defect, and lifting it turned out to be the smallest of three things stacked on top of each other. All three are on main now (5360e1c3, merged at dd869f97); none of it is tagged yet, because the third one wants a device leg before it rides a release.

1. The refusal is the host's contract, and the engine's own rejoin was never party to it

seek(to:)'s live-only guard is defence-in-depth for a host that draws a scrubber it should have hidden. The rejoin is not a scrub: it picked its position out of content this same session cut and served. Seeks now carry their origin, and only a host seek is refused. seekableLiveRange still reads nil on a session loaded without a DVR window, so nothing about what your client is told has moved.

Your suggestion (carry the position in as the reload's start position) was not taken, and the reason is on file rather than a matter of taste: LiveReloadPolicy.skipInitialSeek exists because of a device-verified wedge, a start seek against a re-served backlog parked the reloaded item in waitingToPlay forever. The placement had to be fixed without moving that.

2. Underneath it, a clamp with no trustworthy edge

Lifting the refusal alone made things worse, which is worth stating plainly because it is also the reason your leg 2 passed. On our harness the carried 71.40 s then landed at 43.40 s, four segments below the consumer's own last fetch. At the moment a rejoin runs neither edge the engine publishes is true: LiveWindow.edgeTime is a running maximum that an outage freezes BELOW the playhead that legitimately ran past it, and a freshly swapped item's seekableEnd is a range it has not finished reporting.

A rejoin is now measured against what the producer HOLDS, sampled at the seek rather than at the last publish tick. The only thing that can disqualify a position the session itself served is eviction, and the cache is the one party that is neither ahead of nor behind itself.

3. The one that was hiding under both: an item's zero is where its playlist began

This is the part worth your device time. Adding the item's own seekable-range START to what the engine mirrors (only the end was ever mirrored, which follows a live edge and cannot answer whether a position is inside the item at all) put the three readings on one line for the first time:

#446 placement audit: item clock 70.01s in item range 0.00..42.00s, shift 1.40s
                      -> session 71.41s; the producer holds 51.40..111.40s

An item clock reading 70.01 while its own seekable range ends at 42.00 is not one timeline. AVPlayer places a live playlist's content by the PLAYLIST it was handed, so an item's zero is the first segment that playlist listed, not the producer's first segment. For the item a session starts with those coincide. For any item attached after the window has slid, which an in-place swap does routinely, they do not, and the session had no term for the difference.

The consequence is larger than this issue: the session clock read 71.41 while the picture was at 121.4, and the rejoin to "the place it held" aimed 50 s past it, onto the live edge. Every DVR leg we have ever run passed only because an 1800 s window does not slide inside a single run.

The offset is measured rather than assumed, and it verifies itself. One rule sizes both the playlist's first visible segment and the cache's eviction, so the two floors slide together and their difference holds still:

sample	producer holds	item reports	difference
+1.5 s	51.40..116.40	0.00..42.00	50.00
+6.7 s	56.40..116.40	5.00..47.00	50.00
+13.0 s	66.40..126.40	15.00..57.00	50.00

It is latched per item, because it is a property of the playlist that item loaded, and re-measured when the item under the host changes. It reads 0 for the item a session starts with, which is why nothing needed it until a swap attached a second one.

Harness verdict on the live-only freeze leg, 28 s outage, judged in segments:

before: consumed through seg13, resumed into seg18, 4 skipped, advanced 14.00s
        VERDICT: POSITION LOST
after:  consumed through seg13, resumed into seg11, 0 skipped,
        re-fetched 3 below (lookback allows 3), advanced 71.80s
        VERDICT: position held

What would be worth measuring on your stack

Your NativeAVPlayerHost path with an app-owned spool is the one shape this was never observable in, because the refusal was standing in front of it. Two things, both from main:

• The offset line, if it appears at all. #446 this item's playlist began Xs into the session fires only when a swapped item's playlist starts above the producer's first segment. Your spool jump makes your window's geometry different from ours, so whether it fires and what X reads is a real question rather than a formality.
• The placement audit across your leg 2. The pair that matters is the item's range against the producer's. If they overlap on your stack, our offset is a harness artefact and I would want that trace; if they do not, the 139.18 s landing that sat at the carried target by coincidence was coincidence twice over.

The --live-only arm that produced all of the above is in aetherctl now (live --live-only), which loads with no DVR window and, because live-only retention is a sliding 60 s, is the only arm in which an item's own axis is observable at all.

Thanks for flagging this as an interaction rather than asserting it. Asserting it would have got the refusal lifted and nothing else, and the refusal was the least of it.

[superuser404notfound]

All three are tagged now: 6.56.5 (1463d707), so the device leg does not need a main checkout.

One property worth having before you pin it, because it bounds what a retest can even disturb: the offset reads 0 for the item a session starts with, and it is only measured again when a different item is under the host. A live session that never swaps an item is therefore unchanged by this release, and the DVR freeze leg produced no offset line at all, because an 1800 s window does not slide inside one run. What moved is the path that was already landing in the wrong place.

The two readings named in the previous comment are still the ones worth capturing, and both come off grep '#446':

#446 this item's playlist began Xs into the session
#446 placement audit: item clock ... in item range ... the producer holds ...

If the first never fires on your stack, your swapped items are loading playlists that still begin at the producer's first segment, and the offset is a harness artefact rather than a general rule. That is a result, not a null one, and I would rather know it than assume the harness generalised.