After a re-aimed restart the producer serves in ~2 s but AVPlayer stops requesting, so the landing waits out 5 s park detection plus 6 s re-engage grace

[superuser404notfound]

Split out of #408, whose retest confirmed both halves of the wait it was opened for. Reported and measured by @rrgomes on 6.40.0 / 6.41.0, h264 MKV whose Cues mark non-random-access points, PGS on, Apple TV 4K 3rd gen (tvOS 26.6) and macOS 26.6.2, 2026-08-24/25.

What happens

After a restart whose gate re-aimed, the producer serves its first segment in about two seconds, and then AVPlayer stops requesting. The landing waits out the ladder instead: 5 s of park detection plus 6 s of re-engage grace. Two of the three re-aimed landings in the retest did this; the third never parked, and there is no discriminator yet for which do.

Apple TV, seek#1 to 15.00, 11.94 s in 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 to 147.60, 15.75 s in total: seg35: served 44291341 B (wait=1939.1ms cache=26 restarted=true) at +1.9 s, then no further GET; WEDGE BROKEN ... parked=5s at +9.5 s, producer restarted at idx=36 and re-aimed, gate open at +9.9 s, segments 36 to 44 rebuilt by +13.2 s; consumer re-engage: no segment fetch for 6s at +15.5 s, nudge, landed at +15.75 s.

Why it is worth its own issue

The wait #408 was opened against is gone: fifteen seeks into resident content landed in 0.05 to 0.23 s on the same asset that used to sit 12 to 27 s. But from a viewer's seat the complaint is unchanged whenever this fires, because the number is the same size and arrives by a different route. The producer is not the blocker here; it has already served. Both timers are worst-case detection budgets sized for a consumer that might still be working, and neither is measuring whether this one is.

Questions this needs answered before a fix

• What separates a re-aimed restart whose consumer parks from one whose consumer does not. The third landing (seek#2 to 205.00, 6.90 s) went through the same re-aim and never parked.
• Whether the park is a consequence of the re-aim at all, or of the restart, in which case it predates 6.40.0 and the retest simply gave it a clean shape to be seen in.
• Whether the 5 s park detection can be earned back with a signal rather than a timer: the producer knows it served, and the provider's fetch counter knows AVPlayer went quiet, so the pair is a fact rather than a wait.

[superuser404notfound]

Two of the three questions above have answers now, and the change that came out of them is about the ORDER of the repair rather than about either half of it.

The wedge does not reproduce here, and that is worth stating plainly

A twelve-seek burst at 400 ms spacing under a 120 kbit/s throttle on the loopback path lands every seek, before and after this change: wedge breaks=0, producer re-anchors=0. That is expected, since the state is AVPlayer's (zero GETs while the item never fails, #93), not the engine's. So nothing below is verified against a real wedge on this side, and the effect can only be confirmed on your setup.

What your logs do settle

The first repair could not have worked in either instance:

21:08:52.498 #65 backpressure WEDGE BROKEN head=15 target=5 cacheTarget=4 parked=5s
21:08:52.503 #65 backpressure wedge: re-anchoring producer to 15.00s -> seg3
21:08:58.508 #65 consumer re-engage: no segment fetch for 6s after wedge re-anchor
21:08:58.748 seek#1 programmatic landed rendered=15.00 target=15.00

The pump had marched to segment 15 and was sent back to segment 3, and the consumer then fetched nothing for the entire grace window, which is the re-anchor reporting its own failure. The nudge that followed landed the seek in 240 ms. Your Mac instance has the same shape around a 44 MB segment that had already been served.

The re-anchor exists for a consumer STARVED of content nobody is producing, and it earns its cost there: it puts the target back inside the producible window. A consumer silent about a segment that is already on disk is not starved, and re-anchoring throws the pump's forward work away to rebuild what it already has. So the repair is now picked on that question. Target stored: nudge the consumer first, and keep the re-anchor as the fallback if the nudge has not taken by the end of the same grace window. Target not stored: unchanged. In your two instances that is the six seconds, removed.

Your second question, whether the re-aim causes the park

On the Apple TV instance it does not, and the timestamps say so: the wedge detector had already been counting for five seconds when it tripped at 52.498, so the consumer went silent around 47.5, while the re-aim you quote belongs to the restart that the wedge re-anchor itself requested at 52.503. Nothing had re-aimed before the silence began. The Mac instance is less clear, because the segment served at +1.9 s came back restarted=true and the log does not say whether THAT restart re-aimed; the re-aim quoted there is the one after the wedge. So "after a re-aimed restart" looks descriptive rather than causal on the evidence available, and the honest position is that the re-aim has not been shown to be involved at all.

Your first question, the discriminator

That one is not answered, and the reason it could not be is that the line does not state what it knows. WEDGE BROKEN gave head, target, cacheTarget and the park duration, none of which say whether the consumer's own target was on disk, which is exactly the fact that decides which repair a wedge calls for. It now carries consumerTargetStored=y|n and highStored=. On a retest that turns the question into a reading: whether the instances that park are the ones whose target was already stored, and whether seek#2 to 205.00, which never parked, differs there.

Left alone on purpose

The 5 s park detection. A frozen fetch target and a frozen clock are also what a normal seek landing looks like for a moment, so shortening that threshold needs a measurement of what an honest earlier signal is, and I do not have one. What this removes is the part your logs indict.

Merged to main (50b2d313), not released; a note follows when it ships. If a retest is convenient, the two lines worth capturing are the WEDGE BROKEN line with its new fields, and whether a #421 backpressure wedge with segN already stored line appears before the landing instead of the re-anchor.

[superuser404notfound]

Released in 6.43.0, with both consumers on the new pin. Leaving this open for the retest.