Native-path seek recovery waits 12-24 s on a target the producer is already serving — the reconcile budget is sized for a slow source, not for the island it can measure

[rrgomes]

Reporting the cost side of the slow-source seek recovery (a4e049b4, fix(seek): recover slow-source VOD seeks without reverting the clock). The recovery itself is correct and does land the seek. What I would like to raise is when it decides to act: on a LAN origin with the target already cache-resident, the wedge is detectable within a second or so, and the engine waits 12 s — or 24 s with extensions — before re-anchoring.

What it looks like

Apple TV 4K (3rd gen), tvOS 26.6, wired GbE, engine 6.34.1. Origin is a Plex server on the same subnet. I checked the reconcile-budget path against 6.37.0 before filing: the three constants, seekIsWedged and the re-anchor branch are unchanged, and the 6.36.0 notes say the wedge re-anchor was left deliberately untouched, so I have not re-measured on the newer tags. Asset is 1080p H.264, ~35 Mbit/s, direct play on the loopback-HLS native path. Backward skip presses, 166-251 ms apart, each -10 s.

seek slow but producer serving target
  (island=7.30s at target, rendered=456.13s buffered=456.13s); extending budget 1/4

seek did not land within budget
  (1 extension; starved, island=7.30s at target, rendered=456.13s buffered=456.13s);
  holding clock at target 466.10s and re-anchored producer at 466.10s, re-seeking

The re-anchor then lands it immediately. Four instances in one ten-minute session across two devices; every one carried a non-trivial island at the target and rendered == bufferedEnd.

The wait is the two constants, not a measurement

nativeSeekReconcileBudgetSeconds = 8.0
nativeSeekExtensionBudgetSeconds = 4.0
nativeSeekMaxDeadlineExtensions  = 4

Observed landings cluster exactly on that arithmetic: 12.07, 12.10, 12.11, 12.13, 12.29 s (8 + 4, one extension), and ~26.5-27.0 s at the top of the extension ladder. Median landing for the same asset and device when this path is NOT hit is 166 ms (127 samples).

So the figure a viewer waits is not derived from anything the engine observed about this seek. It is the same 12 s whether the target is a fresh network fetch or, as here, content the producer is already serving.

Why the island seems like the signal

seekIsWedged already establishes the diagnosis — rendered == bufferedEnd, AVPlayer parked with nothing ahead of it — and the log line already reports island=Ns at target. Both are available at the first deadline check. When the island at the target is comfortably above nativeSeekProgressIslandFloorSeconds and the rendered position has not moved, waiting appears to buy nothing: there is no fetch in flight that more time would complete.

I want to be careful about the other direction, because the budget is clearly there for a reason. On a genuinely slow origin, re-anchoring the producer early would thrash, and the current figures are presumably tuned for that. So this is not a request to lower them — it is a question of whether the wait could be conditioned on what is already measured, so a session with the content in hand does not pay a slow-origin budget.

Failing that, exposing the three as configurable would let a host on a known-local origin choose, the way AVIOReader.connStallTimeout now can be.

Where this bites hardest

In a synchronised viewing session the cost is multiplied rather than shared. The peer that stalls reports itself buffering, the group gate pauses everyone, and every participant watches a spinner for the full 12 s — for a seek one device could have completed in 166 ms. Repeated skip presses are ordinary during such a session, so this is reached often.

Two things that shift the odds, in case they narrow it

Embedded subtitles enabled make it markedly more likely. Same asset, same device, same kind of press runs:

subtitles	landed seeks	median	over 1 s
on	63	252 ms	7 (11%)
off	127	166 ms	2 (1.6%)

With subtitles on, the two worst cases (~27 s, the full extension ladder) occur; with them off the residue tops out at ~12 s. Every slow instance in both columns is a BACKWARD seek into content the producer reports as resident.

I have the full engine logs for each instance and can send whichever are useful, including the subtitle-event bursts that accompany the subtitles-on cases.

[rrgomes]

A second finding on the same path, from the same session, which I think belongs here rather than in a new issue: when the budget expires and the producer is re-anchored, the seek does not land at the target. It lands at the next keyframe the restarted producer accepts, which in this file is seconds later, and the first picture it shows is broken.

The landing error is systematic. Every video gate open after a re-anchor today, same asset and devices as above:

target=788204  actual=793751  shift=5547
target=732607  actual=735610  shift=3003
target=948322  actual=962128  shift=13806    (twice, two re-anchors to the same target)
target=652277  actual=662078  shift=9801
target=244119  actual=255255  shift=11136

That last one end to end:

02:54:11.886  seek#11 programmatic began target=246.57
02:54:23.992  seek did not land within budget (1 extension; starved, island=7.74s at target,
              rendered=215.54s buffered=215.54s); holding clock at target 246.57s and
              re-anchored producer at 244.12s, re-seeking
02:54:24.024  [HLSSegmentProducer] init OK (baseIndex=61, segments=1277, targetDur=4.000s)
02:54:25.910  [HLSSegmentProducer] still waiting for video keyframe: dropped=200 lastDts=252335
              lastPts=252335 isKey=false target=244119 baseIndex=61
02:54:26.110  [HLSSegmentProducer] video gate open: actual=255255 anchorPts=255297 target=244119
              desired=244119 shift=11136 videoPID=0 reconstructed=false
02:54:38.200  seek#11 programmatic landed rendered=256.54 target=246.57

Reported as landed, 10 s from the target, 26.4 s after the press. Sixteen of these today across the two devices (9 + 7), all backward seeks into resident content, every one with a shift of 3-14 s.

Two things about the keyframe wait don't fit together. The segment plan for this file says keyframe-aligned, 6004 IRAPs → 1339 segments — an IRAP every ~0.9 s on average over 5355 s. Yet after the re-anchor the producer dropped 200 packets and accepted nothing as a keyframe for 11 s (244.1 → 255.3). So either the demuxer seek behind reanchorProducerToPlaylistTime is landing somewhere the plan did not expect, or the producer's isKey test after a restart is stricter than the one the plan was built with (IDR only vs. every IRAP, say). I can't tell which from the host side.

The picture. At the moment the gate opens after such a re-anchor, the frame shown is visibly broken — blocky and smeared for a moment before it cleans up. That is what open-GOP leading pictures look like when decode starts at a CRA rather than an IDR, which would be consistent with the restart beginning on the first thing that passes isKey rather than on a clean random-access point. The reporter on the couch saw it repeatedly during a session of skip presses and had not seen it before; it appears to be a property of this recovery path specifically, since ordinary seeks that land inside the budget show a clean first frame.

So the cost side of the budget, from the viewer's seat, is not only the 12-24 s wait: when the wait ends, the picture lands in the wrong place and starts broken. If the wait could be conditioned on the measured island as suggested above, this path would be reached far less often; if not, the re-anchor landing seems worth looking at on its own.

Engine 6.34.1, path unchanged through 6.37.0 as before. Full logs available.

[superuser404notfound]

Thank you for this one, and for filing the cost side separately from the recovery itself. The arithmetic in the report is right, and it turned out to be the visible end of two defects rather than a tuning question. Both are fixed on fix/ae408-seek-reconcile (424ffeeb), not yet merged or released.

The 12 s is a fallback, not a budget for this seek

The reconcile path is reached at all because nothing else aimed the producer at the new target, and it then grants its first extension on a reading that does not mean what its own comment claims.

The island is not measured at the target. bufferedSecondsAtTarget sums every loaded range intersecting [target - 1 s, target + 30 s]. The window reaches thirty seconds PAST the target, and a band anywhere in it counts at full weight, so media loaded well downstream reads as "the producer is serving the target". That is the only reading consistent with the trace in the report: island=7.30s at target sitting next to rendered == bufferedEnd and a seek that never lands. Had 7.3 s of media actually covered 466.10 s, AVPlayer would have landed on it instead of parking. The figure came from somewhere else in the window.

Coverage of the target is now a gate on the reading. The window keeps its width, because measuring how deep the served region runs is what separates a producer still filling from one that served a little and stopped; it is only the licence to read the window at all that now requires the target to be inside it. In the reported shape the island reads 0, which is below nativeSeekProgressIslandFloorSeconds, so no extension is granted and the deadline goes straight to the re-anchor. The extra 4 s came entirely from the first extension being free: it has no earlier sample to compare against, so presence alone bought it.

The producer was never told to move. A backward target jump into a cache-resident segment deliberately skips the proactive re-anchor. That gate exists for the Continuous-Audio handover refetch, roughly seven to ten segments backward into content the active pump is still writing, where an unconditional restart re-arms the FLAC bridge and glitches the audio. Residency of the target segment alone does not carry that, because a scrub band left by an earlier pump is resident too, and it ends.

Reproduced headless with the CLI harness, seeking back into a three-segment band while the pump was anchored at seg99:

[AetherEngine] seek#2 programmatic began target=155.00
[HLSVideoEngine] declareTarget backward jump 103 -> 38: resident in cache, no restart
...
[HLSVideoEngine] seg41: out-of-range fetch (cache.range=25..113 highWater=113 attempt=1/3), restarting producer

Nothing moved the pump. The consumer walked the band in 4 s and asked for the first index above it with 5 s of buffer left, and the whole re-anchor was paid at that moment. With a longer band the pump instead sat parked for 24 s, until the #65 backpressure wedge breaker moved it on the AVPlayer position.

The gate now holds only in the two shapes where it is true: the resident run reaches the active march front, so the band carries the consumer straight back into the pump's own output and there is no gap at all (the handover case), or the run is at least a prefetch window deep, so the gap gets asked for with a full cushion and re-anchoring early would only re-produce content already on disk. Anything shallower re-anchors when the target changes. The same run, after:

[HLSVideoEngine] declareTarget backward jump 103 -> 38: resident only through seg40, which is
                 below the march front 113, so the band ends in a gap nothing is producing
[HLSVideoEngine] producer restarted at idx=38 (seek=152.00s, restart took 1ms)

On making the three constants configurable: holding off, and the precedent named in the report does not quite hold. AVIOReader.connStallTimeout is an init parameter taken so tests can shorten it; there is no host-facing knob for it, and the shipped value is the only one a deployment ever sees. Beyond that, the complaint is that the figure a viewer waits was not derived from anything the engine observed about this seek. The answer to that is for it to be derived, not for a host to guess a better constant per deployment.

The landing error after a re-anchor

This is the sharper of the two findings and it cannot be closed from here yet.

The plan boundary at target=244119 is an entry in the container's own keyframe index. The restart seeks the demuxer to exactly that timestamp with the target as a lower bound, and the producer's gate then opens on the first packet that carries AV_PKT_FLAG_KEY and presents at or after it. Those are two different authorities on the same question. The plan trusts the index (AVINDEX_KEYFRAME, which for Matroska comes from Cues and for MP4 from the sync sample table); the gate trusts the flag on the demuxed packet. Where they agree the shift is zero, which is what every local run shows. Where they disagree there is no path back, because the seek may not land before the boundary and the gate may not open before it either, so the producer scans forward to the next packet both authorities accept and the segment then carries content that much later than the playlist says it does. The systematic 3 to 14 s and the broken first picture both fit that: after a scan of that length the packet the gate opens on is far more likely to be a recovery point than an IDR, and leading pictures referencing frames the producer never emitted look exactly as described.

What would settle which of the two it is, on the reporting asset:

1. The keyframe flags across the region, which is one line: ffprobe -v error -select_streams v:0 -read_intervals 244%+16 -show_entries packet=pts_time,dts_time,flags -of csv=p=0 <file>. If no K appears between 244.119 and 255.255 the runtime flags are sparser than the index and the plan is describing a stream the producer cannot open where it was told to. If they appear every 0.9 s as the index claims, the seek is landing somewhere else and the demuxer side is where to look.
2. ffprobe -v error -show_entries format=format_name,duration -of default=nw=1 <file>, since Matroska and MP4 fail this in different places.
3. From the same session, the [HLSVideoEngine] segment plan: line, and whether any [Demuxer] Seek to stream N timestamp T failed appears near the restart. That last one has a fallback that lands earlier rather than later, so its presence would rule the scan explanation out.

One thing in the trace that does not fit

Every quoted instance has rendered BELOW the target: rendered=456.13 against target=466.10, and rendered=215.54 against target=246.57. Those are forward seeks in AVPlayer's terms, while the presses are described as backward and the instances as backward seeks into resident content. Both readings are possible in a burst, since the rendered position stays pinned at the pre-seek playhead while the optimistic clock walks on, so an early press in the burst could have left it far below everything that followed. It matters because it decides which branch the fixes reach: a backward jump in the declared target is the residency gate fixed above, whereas a target above the pump's own front is decided somewhere else entirely. The [HLSVideoEngine] declareTarget and [HLSVideoEngine] seg<N>: lines around one instance would show it directly, and the full log for that instance would be welcome.

[superuser404notfound]

Released in 6.39.0 (f70d4ae), with both consumers on the new pin.

Leaving this open: the second finding (the re-anchor landing 3 to 14 s past its target with a broken first picture) is untouched by the release and still needs the ffprobe reading from the reporting asset, and a retest of the wait itself would be worth having before closing the first half.

[rrgomes]

Thank you — that's a far better outcome than a knob, and the reasoning on why not to expose the constants is convincing. The readings you asked for, all from the reporting asset and the quoted instance.

1. The keyframe flags: your option A, decisively

Container: matroska,webm, duration 5355.352.

ffprobe -v error -select_streams v:0 -read_intervals 244%+16 \
  -show_entries packet=pts_time,dts_time,flags -of csv=p=0 <file>

K-flagged packets in the window: 243.118 (the interval read's own landing, before the window), then nothing until 255.297 — which matches the producer's anchorPts=255297 to the millisecond. A packet does exist at exactly the plan boundary — 244.119000,243.994000,___ — with no K flag: the index entry points at an ordinary frame. And the packet count between 244.119 and the scan's end at 252.335 is 198, against the producer's dropped=200.

So the runtime flags are sparser than the index, the plan is describing a stream the producer cannot open where it was told to, and the scan is correct behaviour against these packets. The gate opened on the first true keyframe there was.

Wider context — K packet times across 200–300 s:

204.663  215.674  219.636  220.762  226.560  230.397  243.118  255.297
255.297  256.798  258.842  260.802  262.053  263.263  265.265  267.017
270.353  276.151  277.736  280.697  283.492  287.412  291.374  295.629

Three droughts of 11–12.7 s in this hundred seconds alone (204.7→215.7, 230.4→243.1, 243.1→255.3), against a plan of 6004 IRAPs averaging 0.9 s. So the Cues in this mux mark cue points that are not random-access points, in quantity, and every one of them is a place where a re-anchor lands late with leading-picture damage. That also explains the determinism we saw: two devices produced byte-identical dropped=200 lastDts=252335 … shift=11136 independently.

2. The other asks

Segment plan line from the session:

[HLSVideoEngine] segment plan: keyframe-aligned, 6004 IRAPs → 1339 segments
  [firstKeyframePts=0 (0.000s) videoStream.start_time=0 format.start_time=0us plan[0].startSeconds=0.000]

[Demuxer] Seek to stream N timestamp T failed: zero occurrences in the whole capture, which by your criterion leaves the scan explanation standing — and the flags above confirm it.

3. You were right about the direction — a correction to my report

The quoted end-to-end instance was a forward step in a press burst (targets 202.67 → 216.57 → 246.57), not a backward seek; rendered=215.54 is the previous landing, pinned while the optimistic clock walked on. My "all backward seeks into resident content" claim was wrong for that instance — the run that produced the 12 s landings with backward presses was a different session. Full excerpt for the quoted instance, one device:

02:54:11.886  seek#11 programmatic began target=246.57
02:54:14.053  [HLSVideoEngine] seg61: served 17649937 B (wait=2164.5ms cache=54 restarted=false)
02:54:14.324  [HLSVideoEngine] seg62: served 16219733 B (wait=226.9ms cache=55 restarted=false)
02:54:23.992  seek did not land within budget (1 extension; starved, island=7.74s at target,
              rendered=215.54s buffered=215.54s); holding clock at target 246.57s and
              re-anchored producer at 245.40s, re-seeking
02:54:24.024  [HLSSegmentProducer] init OK (baseIndex=61, segments=1277, targetDur=4.000s)
02:54:25.910  [HLSSegmentProducer] still waiting for video keyframe: dropped=200 lastDts=252335
              lastPts=252335 isKey=false target=244119 baseIndex=61
02:54:26.110  [HLSSegmentProducer] video gate open: actual=255255 anchorPts=255297 target=244119
              desired=244119 shift=11136 videoPID=0 reconstructed=false
02:54:38.200  seek#11 programmatic landed rendered=256.54 target=246.57

No declareTarget line precedes the restart — this re-anchor came from the deadline path itself, so the landing error is reachable without the residency gate you fixed.

Happy to retest the wait on 6.39.0 and report back; the asset stays available for anything else you want read out of it.

[superuser404notfound]

Thank you for reading that out of the asset, and for the correction on the direction. Both mattered: the flags settle which of the two authorities is wrong, and the corrected instance is what makes the landing error reachable without the residency gate, which is where the fix now sits.

The index is not a keyframe index

The plan is built from avformat_index_get_entry, filtered on AVINDEX_KEYFRAME. For Matroska those entries come from matroska_add_index_entries, which walks the Cues table and enters every cue position:

if (track && track->stream)
    av_add_index_entry(track->stream,
                       pos[j].pos + matroska->segment_start,
                       index[i].time / index_scale, 0, 0,
                       AVINDEX_KEYFRAME);        /* unconditional */

The block's own keyframe flag is never consulted. Cues mark seek points; nothing in the format says a cue point is a sync sample, and this mux writes them at ordinary frames. So 6004 IRAPs was never an IRAP count, it was a cue count, and the plan cut 1339 segments on positions three quarters of which cannot start a decode. Your 244.119000,243.994000,___ is that fact in one line.

Worth adding, because it forecloses the other reading: the K flag ffprobe printed is not the block flag. With parsing on, which is the default, it comes from the elementary-stream parser, and the H.264 parser sets it for a slice carrying a recovery point SEI, not only for an IDR (h264_parser.c), while the HEVC parser sets it for every IRAP NAL. Measured here on a file whose block flags were cleared by hand: -fflags +noparse prints the (cleared) container flags, the default prints the bitstream truth. So the drought in your window holds no random-access point of any kind, open-GOP included, and the scan was doing the only thing it could.

Reproduced, and what changed

Scripts/mkv-cue-fixture.py injects cue points at non-sync positions the way your asset carries them, over a fixture with a deliberate 12 s drought at 43 s. That reproduces your log line for line, down to the drop count:

still waiting for video keyframe: dropped=200 lastDts=52292 isKey=false target=44000 baseIndex=11
video gate open: actual=55000 anchorPts=55000 target=44000 desired=44000 shift=11000

The fix is on fix/ae408-plan-boundary-truth (7d3563de), not yet merged or released.

The gate no longer opens past a boundary that claimed random access. It goes back for a sync sample that covers it, in widening steps (4, 8, 16, 32 s, four attempts at most). The common case costs one extra seek and finds the covering sample one segment back; a deeper drought escalates, and each attempt stops as soon as it reaches ground already proven empty, so the gap is read once rather than once per attempt. It also detects the case on the packet sitting on the boundary rather than after reading the whole gap, which makes the fixed path cheaper than the old one, not just more accurate.

A gate that opened early keeps its own timestamps. Pinning the first frame to the advertised start is what turns a gate mismatch into a shift of the whole item axis, and it exists for the case that cannot be helped: opening late leaves a hole at the advertised time and AVPlayer waits on holes forever. Opening early has no such problem. Publishing 243.118 at its own time costs an overlap with the previous segment, which AVPlayer absorbs, and the item axis then equals the source axis, so the seek lands where it was aimed rather than a second short of it.

Same fixture, resuming at 45 s, two seconds in on each arm:

	gate	clock at t=02
before	actual=55000 target=44000 shift=11000	57.80 s
after	actual=43000 reaimedTo=40000 shift=0	46.80 s

and a backward seek to 46 s:

before:  seek#1 programmatic landed rendered=47.08 target=46.00
after:   seek#1 programmatic landed rendered=46.00 target=46.00

The control fixture, identical except that its cues ARE its sync samples, is untouched on both arms: no re-aim, no extra seek, shift=0.

The broken first picture should go with it. The epoch now opens on a sync sample by construction rather than on whatever the scan first accepted after a long forward run, and leading pictures that reference frames the producer never emitted are dropped as before. That one is worth confirming from the couch rather than from here, since it is the part the logs describe worst.

Two things I would rather say than leave for a later surprise. The scope is deliberately the keyframe-aligned plan only: the uniform grid never claimed its boundaries were random-access points, and a source-declared plan aims below its IRAP on purpose, so neither may be re-aimed. And the tolerance for opening slightly past a boundary now covers the stream's own reorder depth, because a container index entry is a decode timestamp while the gate judges presentation time, so a well-formed B-pyramid index legitimately puts the keyframe's presentation a reorder delay above the boundary and must not pay a second seek for it.

Separately, and not fixed here: on a source like this the segment cutter, which opens a segment only on a sync sample, steps over the boundaries that fall inside a drought, so the playlist offers two or three segments the producer never cuts. Playback rode through it on the harness, but it is a real property of these files and it is on the list rather than in this change.

Retest whenever it suits, and thank you for keeping the asset available. Both halves of the wait would be worth a fresh reading on 6.39.0 plus this.

[superuser404notfound]

Correcting the last paragraph of my previous comment. I inferred it from the producer's ledger lines rather than measuring it at the serving layer, and the serving layer says something narrower.

The cutter does step over the boundaries inside a drought, and the cache accounts for that explicitly (#358 fold counting). But no advertised index goes unserved. Fetched through the loopback server on the same fixture, every index came back with content inside its own window, and the case that matters resolves properly:

• A cold fetch of a segment inside the drought (a seek arriving there) takes the out-of-range path, which restarts the producer at that index. With this change that restart opens on a sync sample: seg11, advertised 44.0-48.0, comes back starting at 43.000000,K__ and running to 48.0, so it is independently decodable and it covers its own advertised start.
• The same index produced by a pump that walked through it sequentially starts mid-GOP (44.000000,___, no sync sample in the whole segment). That one is only ever consumed by a player already decoding continuously, so it costs nothing there. When a later seek does arrive on it cold, AVPlayer fetches the PREVIOUS segment first and lands exactly: measured as GET /seg10.mp4 immediately after seek#2 programmatic began target=46.00, then landed rendered=46.00 target=46.00.

So: not a hole, and not a second broken-picture path on this client. What is left is that a segment produced sequentially through a keyframe drought does not begin on a sync sample, which is a deviation from what a media segment is supposed to be, and a client less forgiving than AVPlayer would have nothing to walk back to. Worth its own issue rather than a sentence in this one, and not something your retest needs to account for.

[superuser404notfound]

The segment-cut half of the last comment is now tracked separately as #412, with the mechanism pinned down: video is routed into segments by the keyframe-gated cutter, audio by a plain boundary lookup, so in a keyframe drought the audio opens the segments the video cutter folded and the video inside them starts mid-GOP. Nothing there needs to hold up a retest of this issue.

This one is merged to main (095a8c5d). A release note follows when it ships.

[superuser404notfound]

Released in 6.40.0 (7ba42377), with both consumers on the new pin.

Leaving this open for the retest. Both halves are in now: the wait itself from 6.39.0, and the landing from this one. The segment-cut observation from further up is tracked separately in #412 and does not need to be accounted for in a reading of this issue.

[rrgomes]

The fresh reading on both halves, from the reporting asset (the h264 MKV whose Cues mark non-random-access points), PGS subtitles on, on 6.40.0 and 6.41.0 — a couch pass on an Apple TV 4K (3rd gen, tvOS 26.6) and a driven pass on a Mac (macOS 26.6.2), 2026-08-24/25.

The wait half (6.39.0) holds. On the Mac, fifteen seeks into resident content landed in 0.05–0.23 s each; 6.34.1 sat 12–27 s on the same asset and the same presses. Nothing has regressed that since.

The landing half (6.40.0): every re-aimed seek now lands where it was aimed. Apple TV: seek#1 target=15.00 landed 15.00 (re-aimed 12012→8012→4012→0), seek#2 target=205.00 landed 205.00 (re-aimed to 188037, pinnedTo=191983). Mac: seek#9 target=147.60 landed 147.60 (boundary 144853 not a sync sample, re-aimed to 140853, pinnedTo=142809), seek#10 197.60 landed 197.60. On 6.39.0 these were 3–14 s past the target. The couch pass reported no broken first picture where 6.39.0 had shown them. For completeness, the seeks that did not need a re-aim landed with small forward offsets: seek#7 325.30 → 328.04, seek#10 378.20 → 378.59, seek#12 368.90 → 371.20, seek#14 338.90 → 340.76 (all under a second of wait; reporting the numbers, not claiming a defect).

What the remaining long waits are. Two of the three re-aimed landings were not the re-aim: the producer restarted and served its first segment within ~2 s, and AVPlayer then stopped requesting — the #65 consumer wedge — so the landing waited out the ladder's two timers.

Apple TV, seek#1 → 15.00 (11.94 s total):

21:08:46.884 seek#1 programmatic began target=15.00
21:08:52.498 [HLSSegmentProducer] #65 backpressure WEDGE BROKEN (advance) head=15 target=5 cacheTarget=4 parked=5s (fast path: fetch target + rendered clock both frozen)
21:08:52.503 [HLSVideoEngine] #65 backpressure wedge: re-anchoring producer to 15.00s -> seg3 (requested seek target; frozen clock 5.09s) (attempt 1/5)
21:08:58.508 [HLSVideoEngine] #65 consumer re-engage: no segment fetch for 6s after wedge re-anchor (pos=5.09s); asking host to nudge AVPlayer
21:08:58.748 seek#1 programmatic landed rendered=15.00 target=15.00

Mac, seek#9 → 147.60 (15.75 s total): seg35: served 44291341 B (wait=1939.1ms cache=26 restarted=true) at +1.9 s, no further GET, WEDGE BROKEN … parked=5s at +9.5 s, producer restarted at idx=36 and re-aimed (boundary 144853 is not a random-access point … re-aimed the gate 4s below it at 140853, gate open at +9.9 s, segments 36–44 rebuilt by +13.2 s), consumer re-engage: no segment fetch for 6s at +15.5 s, nudge, landed rendered=147.60 target=147.60 at +15.75 s. The third re-aimed landing (seek#2 → 205.00, 6.90 s) never parked. So 5 s of park detection plus 6 s of re-engage grace is the seek wait now on this asset, when it wedges; I don't have a discriminator for which re-aims park the consumer and which don't.

One observation from the Mac wedge, one sample only: while AVPlayer was parked, an AVPlayerItem.currentTime() from the host's main actor did not return for 13.3 s — it came back 30 ms after your re-engage watchdog fired — and the app was fully blocked meanwhile. The same wedge on the Apple TV the same afternoon returned instantly. Our side no longer reads the player from the main actor during a stall; mentioning it because reengageStalledConsumer and NativeAVPlayerHost.bufferedEnd read it there too, and on macOS they would have joined the same wait.

[rrgomes]

The flip side of the 6.40.0 landing fix is up as #418: after a restart whose gate re-aimed below its boundary, the clock runs ahead of the picture by the re-aim (captions early, and a synced host's reported position with them) — same asset, with AVPlayer's loaded ranges in the log this time.