The retained subtitle window travels ahead of the playhead so a drain that keeps pace still leaves nothing to draw

[RadicalMuffinMan]

What happened?

Subtitles drop out for 20 to 40 seconds at a time and then come back on their own, in the middle of otherwise healthy playback. Four reported instances so far.

The cause is that the retained cue store travels about one drain-lead window ahead of the playhead and stays there, so the region the viewer is actually in never gets decoded. The overlay is correct to draw nothing. There's just nothing covering the clock.

Steps to reproduce

Nothing exotic in the call sequence, it's the steady state that drifts.

1. Load a long file (the reporting asset runs about 25 minutes) with an SRT track, direct play, default LoadOptions
2. Let it play without touching the transport for a minute or two
3. Subtitles stop appearing, while decoding stays healthy
4. Seek, or anything that nudges the transport, and they come back for a while before drifting off again

A reporter found step 4 on his own by pressing up to show the progress bar.

AetherEngine version or commit SHA

6.42.0

Host app

Custom / my own integration

Platform

tvOS

OS version

tvOS 26.6

Device / chip

Apple TV 4K 2nd Generation

Playback path

Software (dav1d) host

Source media (for playback bugs)

SRT, both embedded and external, same behavior either way. Direct play from Jellyfin over LAN, no transcode.

The video side doesn't seem to matter, and I don't think ffprobe output would tell you much here since the failure is in the cue store rather than the media. The one relevant property is cue density: the reporting asset's track runs about one cue every 6 seconds.

Error codes / log lines

2.5.0  t=30s  subCues=12  prefetch=park   prefetchLead=74.5s   pumpParked=1
2.5.1  t=30s  subCues=9   prefetch=park   prefetchLead=74.7s   pumpParked=1
2.5.1  t=60s  subCues=13  prefetch=yield  prefetchLead=-215.8s pumpParked=1

outcome=harvestHole gapAt=954.12

(No thrown errors and no AVFoundation codes. The engine already spots the result and names the gap, it just doesn't repair it)

Anything else

subtitleCueRetentionSeconds is 300 and the track on the reporting asset runs about one cue every 6 seconds so a window over the playhead should hold something like 50 cues. The memprobe lines show it holding a fraction of that, and holding it in the wrong place.

2.5.0  t=30s  subCues=12  prefetch=park   prefetchLead=74.5s   pumpParked=1
2.5.1  t=30s  subCues=9   prefetch=park   prefetchLead=74.7s   pumpParked=1
2.5.1  t=60s  subCues=13  prefetch=yield  prefetchLead=-215.8s pumpParked=1

At the t=30s probe the playhead is 880.1 and the store's nine cues are 852.375, 856.083, 859.666, 862.166, 871.333, 875.250, 925.166, 929.041 and 940.083. Six of them ended before 877 and the other three don't start until 925. Nothing covers 880. That's the blank screen, and the count matches the probe exactly. The lead of each delivered cue over the playhead climbs and then pins at the drain lead:

cue  852.375  playhead 852.000  lead  0.375
cue  871.333  playhead 852.200  lead 19.133
cue  925.166  playhead 865.600  lead 59.566
cue  940.083  playhead 880.100  lead 59.983
cue  969.333  playhead 909.600  lead 59.733
cue 1015.916  playhead 956.000  lead 59.916

subtitleDrainLeadSeconds is 60, so the harvest settles exactly one lead window ahead and stays there. The only cues in the store are whatever the forward prefetcher picked up at its frontier and the region the viewer is in never gets decoded.The engine already spots the result. One delivery tick reports outcome=harvestHole gapAt=954.12. It names the gap but doesn't repair it.

A seek bumps seekGen and kicks off a reason=reconstruction drain that re-harvests around the playhead, republishing cues that do cover it. The lead resets to somewhere between -11s and +37s and then climbs back to 60. That lines up with what a reporter noticed on his own: pressing up to show the progress bar brings subtitles back for a few seconds. Anything that nudges the transport re-anchors the drain window onto the playhead, then the pipeline races ahead again.

prefetchLead hitting -215.8s with prefetch=yield is the other end of it. The prefetcher ends up 216 seconds behind the playhead and then stops doing useful work, harvesting 42 packets in 30 seconds. Once it's behind and yielding, nothing fills the hole. Whatever re-anchors it after a seek looks like the behavior the steady state needs.

I couldn't work out from the logs alone why the lead goes negative. That part probably needs the prefetcher internals or a device.

Reproduced on host builds carrying engine 6.42.0 and I checked 6.68.4 before filing. The three governing constants are unchanged, harvestHole is still named without being repaired, and the only subtitle commits since 6.42.0 are the metered origin prefetch hold, the PGS placeholder log text, the live TARGETDURATION seal and the module renames. So I don't think this is already fixed, though I haven't run 6.68.4 on a device to confirm.

d596461b already says the thing this needs, for a different reason:

A paced or single-slot origin keeps the pump's tap-fed subtitles and yields the speculative far-ahead window.

That's the right trade here too. It's gated on isPaced or requiresSerialRequests, so it only fires when an origin has been handing out 429s. A plain LAN Jellyfin server is neither, which may be why this hasn't turned up in your own testing. Preferring playhead-local cues when the retained window doesn't cover the playhead looks like the same rule under a second condition rather than a new mechanism.

[superuser404notfound]

Good report, and the cue list at the bottom is what makes it actionable: nine cues, six ending before 877, three starting at 925, playhead at 880. That is not an overlay deciding wrongly, that is a store with a hole in exactly the wrong place.

First, a bound on the retention half, because that part turns out to be innocent. I built the shape you describe as a headless repro here: 25 minute asset, SRT at one cue per six seconds, software host, no transport interaction, 150 seconds of playback. The retained set ends holding 35 cues, every cue from the start of the file through playhead plus lead, no gaps, and retainedFrom never moves off its initial value. So subtitleCueRetentionSeconds is doing its job and the prune at playhead - 300 is not what removes them. Something else is leaving the store short.

Your nine cues say two separate things, and they probably have two separate causes.

The hole between 877 and 925 is the one the engine already names (outcome=harvestHole gapAt=954.12). There is machinery for exactly that: the drainer refuses to decode across a hole and hold the cursor on the near side, budgeted in ticks, so a harvest that is merely late still gets its stretch decoded. When the budget runs out the cursor goes past and the region is gone for good. So the gap you see is that budget expiring, and the interesting question is not the drainer, it is which reader left the ground unread.

The second thing is quieter and I would not have caught it without your list: there is nothing before 852 either. At playhead 880 with a 300 second retention, cues from 580 onward should still be in that array, which is another 45 of them. Nine cues spanning 852 to 940 is not a store that lost a stretch, it is a store that was rebuilt around the current window. That points at a reconstruction rather than at the harvest.

The prefetchLead=-215.8s line is the one I would chase first. A negative lead means the side reader's read position is 215 seconds BEHIND the playhead, on a reader whose whole job is to run 60 seconds ahead. The two probes 30 seconds earlier have it at +74.5 and +74.7, so between them it went from a normal park to a long way back. A side reader does not walk backwards; it gets re-anchored or restarted there. Whichever it was, the stretch between where it had got to and where it resumed is ground nobody read, and that is a hole of exactly this shape.

What would pin it, from a log of one dropout:

• grep '#151 forward prefetch' gives every start, in-place re-anchor and read failure with its position. A re-anchored in place at ... or a second started: line during steady playback is the whole answer.
• grep '#250 subtitle-resolution' carries coveredFrom, retainedFrom and seekGen per tick. If retainedFrom jumps forward at the moment the array shrinks, that is the reconstruction, and seekGen says whether anything thought a seek had happened.
• grep '#357 subtitle-delivery' has recon= and the outcome per tick, so the reconstruction and the harvest hole can be told apart in time rather than inferred from the end state.

Those three around one 20 to 40 second dropout would be enough. The harness is standing, so once I know which reader left the hole I can drive it here rather than by inspection.

One question about the session shape, since your build predates a fair amount of this: 6.42.0 is 26 releases back. I checked before asking, and only five commits have touched the subtitle path since, none of them aimed at this, so I am treating the report as current rather than sending you off to re-test first. But if the reporting host has any chance of a re-anchor of its own, a subtitle track re-selection or a reload mid-session, that would be worth knowing, because it moves the suspect from the engine's own restart policy to a host call.

[RadicalMuffinMan]

Got the onset, on 6.71.0. Short version: it still happens, and the mechanism is not the one either of us was chasing.

moonfin-tvos-6.71.0-prefetch-cancel-ae496.log

Attached is a full diagnostic report from Moonfin for tvOS on an Apple TV 4K (3rd gen), engine 6.71.0 clean, no local commits this time.

The prefetcher is cancelled seven seconds in, and nothing restarts it

17:17:13  #151 forward prefetch started: streams=[2] pacing=0 anchor=2 startAt=0.00s lead=75.0s
17:17:14  [AVIOReader] prefetch conn gen=2 ended with error: cancelled
17:17:15  [AVIOReader] prefetch window high water: 16MB ahead; ending the connection, will re-request at the frontier once the consumer drains
17:17:20  #151 forward prefetch exited (reason=cancelled cancelled=true) harvested=37

Playback then ran for another eight minutes. The store froze at 469 cues, prefetchHarvested froze at 37, and the lead fell at exactly the rate the playhead advanced, out to -368.5s. Same arithmetic as the capture I sent before, and the same two numbers: 469 and 37. It is the same asset failing the same way.

What this rules out

The restart budget is not what ends it. There is no giving up after N restarts line anywhere. The exit reason is cancelled with cancelled=true, which is something deliberately cancelling the task rather than the budget being spent.

d596461b does not fix it. This build has holdingForMeteredOrigin. That was the obvious candidate given the shape, and it is now out.

The host is not involved. No reload, no track re-selection, loadGen and seekGen constant across the failing session. I traced our playback layer separately: every path that touches subtitle selection is bring-up, user-initiated, or gated on a backend error, and the only periodic timer reads the subtitle index without writing it.

What I would look at

The AVIOReader line one second before the cancel is the part I cannot explain from the outside:

[AVIOReader] prefetch conn gen=2 ended with error: cancelled
[AVIOReader] prefetch window high water: 16MB ahead; ending the connection, will re-request at the frontier once the consumer drains

The reader hits its high-water mark and ends the connection, which reads as normal and self-healing on its own terms. The prefetcher then exits cancelled five seconds later and never comes back, so whatever "will re-request at the frontier" means for the pump does not seem to apply to the side reader. Whether the connection teardown cancels the task the prefetcher is waiting on, or the two are unrelated and something else cancels it, is inside machinery I cannot see.

The asset

MOV, H264/AAC, 720x540, 23.976, 1457s. Embedded MOV_TEXT subtitle, index 3, English, not forced, deliveryMethod: Embed. Direct play, so the loopback path with HLSVideoEngine serving 363 segments.

One property that may matter, since it shows up on every reader in this session including the prefetch one:

[AVIOReader] prefetch tail prefetch skipped: this origin declined suffix ranges earlier this session (status=200 (no suffix range support))

The origin does not honour suffix ranges. A different asset on the same server resolved its entire subtitle track up front (1343 cues, prefetch=off, prefetcher never needed) and played perfectly for ten minutes, so the two are worth telling apart if the suffix range behaviour is what decides which path a track takes.

Reading the log

Three sessions, the last one is the failure:

• 16:38 a film, whole track resolved up front, prefetch=off, healthy
• 17:16 a short item, prefetcher started and re-anchored on a real seek, then a genuine teardown
• 17:17:12 the failing session, everything above

[superuser404notfound]

Thank you for the full capture, that is what settled it. The mechanism is neither of the two we were chasing, and the log answers it outright once you know which line to pair with which.

Your two AVIOReader lines are innocent, and your own healthy session proves it

17:17:14.545291  prefetch conn start gen=2 offset=33554432 len=32MB
17:17:14.560907  prefetch conn start gen=3 offset=47532163 len=32MB
17:17:14.561352  prefetch conn gen=2 ended with error: cancelled

Gen 3 opened 15 ms before gen 2 reported cancelled, at a further offset. That is a connection being superseded by its own successor as the reader moves its window forward; cancelled there is URLSession's word for the task the reader itself tore down, and it never reaches the prefetch Task.

The high-water line one second later is the same story. It appears twice in your healthy 17:16 session (17:16:48.246064, 17:16:50.274730) with the prefetcher reading on afterwards and only exiting at 17:16:56.733195, on a real teardown. So parking at the high-water mark is the normal path, exactly as it reads.

Both of those happen at 14.5 and 15.0. The Task exits at 20.277. Five seconds and a park apart, with no causal link.

What ended it, and the line 67 microseconds later that names it

reason=cancelled cancelled=true means an explicit cancel(). In this build there are exactly two callers: the prefetcher replacing its own session (which logs a started: line immediately after, and there is none), and stopSubtitleDrainer(), which runs when the last subtitle drain target is cleared.

Then:

17:17:20.277803  #151 forward prefetch exited (reason=cancelled cancelled=true) harvested=37
17:17:20.277870  [AVIOReader] source tail prefetch skipped: this origin declined suffix ranges ...
17:17:20.278086  [AVIOReader] source conn start gen=1 offset=0 len=32MB

source is the default AVIOReader label, and the only thing in the tree that builds one is SubtitleDecoder.decodeFile, the whole-file decode. It has two callers: the sidecar decode path, and the #88 external-native-store fill. The second is excluded by your own session line:

17:17:12.641874  native subtitles: prepare=false eager=false textTracks=1 bitmapOCR=0 enable=false

So the primary subtitle selection moved to an external / sidecar track at that instant. That path clears the primary drain target, which empties the target set, which stops the drainer, which cancels the prefetcher, and then opens the whole-file reader. Four calls, one synchronous hop, in exactly the order your log has them. The engine's own internal re-selection routes (audio switch, title switch) all need a reload, and your loadGen stayed 19 throughout, so this was a call in from outside.

Which means 469 is a finished track, not a frozen store

There is exactly one source conn start in that session, so the decode read at most one 32 MB chunk. The MOV is roughly 840 MB, so it was not the media file, it was the sidecar. It succeeded: subCues goes to 469 and stays at exactly 469 across all fifteen probes from t=30s to t=450s. A drainer-fed array cannot sit still like that, its retention prune trims at playhead - 300 and the count would fall as the playhead runs out to 450 s. A whole-file publish is the only thing that produces a flat line.

And your healthy 16:38 session is the same state: subCues=1343 prefetch=off subTracks=56, static for eighteen minutes, and you call it healthy. After 17:17:20 the failing session is in that state too. The drainer is off and the prefetcher is cancelled because the track being drawn no longer needs either: it is a whole file that arrived in one request.

That also disposes of the falling lead. prefetchLead is last read position minus playhead. With no reader the position is frozen, so the number has to fall at one second per second. It says the prefetcher is gone. It does not say anything is missing from the screen.

So this capture is not the failure the issue is about

The issue body has:

t=30s  subCues=12  prefetch=park   prefetchLead=74.5s
t=30s  subCues=9   prefetch=park   prefetchLead=74.7s
t=60s  subCues=13  prefetch=yield  prefetchLead=-215.8s

Loop alive, parking and yielding, tiny array. This capture has prefetch=cancelled from second eight, a 469-cue array, and prefetchYielded=0s prefetchValve=0 for the whole session, so the link arbitration never engaged once. Those are two different states, and I do not think the second one contains the first. (You mention "the same two numbers, 469 and 37" from an earlier capture. I only have the issue body's, which are 9 to 13.)

The question that is yours, and it is a narrow one

The correlation across your three sessions is exact:

session	PlaybackInfo asked	sidecar decode
16:38 film	subtitleStreamIndex=0 (external SUBRIP)	0.65 s after Bringup: opening
17:16 first pass	subtitleStreamIndex=2 (embedded)	none, prefetcher ran
17:16 after the SDH download	subtitleStreamIndex=0	0.57 s after
17:17 failing	subtitleStreamIndex=3 (embedded MOV_TEXT)	7.83 s after

Every time you ask for index 0 you get the sidecar at bring-up. This one asked for index 3, got the embedded track first (overlay fed by packet-store drainer for stream=2, 17:17:12.869), and then something selected the external track on top of it eight seconds in. The other entry in your own decision record for that item is English - Hearing Impaired - SUBRIP - External, index 0.

So: which of your call sites fires roughly eight seconds after bring-up, and why did it pick the external track when PlaybackInfo asked for the embedded one? selectSubtitleTrack(index:) with an external id, or selectSidecarSubtitle(url:), are the only two ways in. It is worth knowing whether the viewer was seeing the SDH track from then on rather than nothing at all, because those look identical in this log and completely different on the screen.

My half: the log could not say any of this, and that is on me

Two rounds went into reconstructing a cancel from the adjacency of unrelated lines. Pushed (not released yet):

• #151 forward prefetch cancelled (reason=...) at the cancel itself, with every teardown route carrying its own reason (sidecarSelected, closedCaptionsSelected, liveRenditionSelected, subtitlesCleared, sessionStopped, prefetchRebuild, ...). The exit line lands whenever the parked loop next looks, which is why it was useless on its own.
• sidecar decode start: id=... stream=... replacing embedded stream=N and overlay fed by sidecar decode: id=... stream=... (N cues). The drainer had overlay fed by packet-store drainer, the sidecar had nothing, which is precisely why a whole-file publish read as a store that stopped filling. A decode that starts and never publishes is now visible too.

On the original report: this capture cannot confirm or refute it, because its arbitration counters are flat. If you can get me the round-1 shape again (prefetch=park or yield with a live loop), the two fields you left out of that paste are the ones I need: prefetchYielded= and prefetchValve=, plus any #151 forward prefetch yielded the link for Ns line. prefetch=yield alongside pumpParked=1 in the same probe is a combination I would like to see confirmed, because a parked pump should not be a reason to yield.

[superuser404notfound]

The diagnostics from my last comment are out in 6.74.0 (e0ee04a3). A capture from that build answers the cancel question by itself: look for #151 forward prefetch cancelled (reason=...) and, if a sidecar is what took over, the sidecar decode start: / overlay fed by sidecar decode: ... (N cues) pair around it.

Still open on my side, and unchanged by this release: the original report. Its arbitration counters were flat in the capture you sent, so nothing in it confirms or refutes the first mechanism. prefetchYielded= and prefetchValve= are the two fields I need from a round-1 shaped session.

[RadicalMuffinMan]

moonfin-tvos-6.74.0-ae496-three-sessions.log

Answering the handoff question: neither. We never selected the external track in that session. I added client-side logging for setSubtitleTrack, addExternalSubtitle, disableSubtitleTrack and our pre-add wait, pinned to 6.74.0, and ran three sessions on the same episode. The failure does not reproduce, but the logging shows what was different, and I think it points at the trigger.

First, a correction. I read the absence of [applySubtitleEvent] lines as proof that cue delivery had died. Your SubtitleDeliveryStatement header says that line cannot carry the claim, and you are right. What the counts actually support:

	applySubtitleEvent	#357 ticks
failing session (6.71.0)	16	4
healthy sessions (6.74.0)	20	99, 122

Every healthy session stops at exactly 20, which is the budget. The failing one stopped at 16, under the cap, so that was not budget exhaustion. And #357, per tick and uncapped, ticked 4 times and then produced nothing for the remaining seven and a half minutes while subCues sat frozen at 469. That is the evidence I should have led with.

The trigger looks like ordering, not track choice. I reran the exact failing configuration, subtitleStreamIndex=3 selected before playback so PlaybackInfo carries the embedded MOV_TEXT, same item, same direct play. It is clean:

17:41:53.747429  addExternalSubtitle .../Subtitles/0/0/Stream.subrip
17:41:53.747719  setSubtitleTrack index=1 external=false bitmap=false codec=mov_text url=none
17:41:53.748531  [AetherEngine] overlay fed by packet-store drainer for stream=2 (backfilled 7 cues)

Zero sidecar decodes, zero source readers, 122 #357 ticks out to playhead 164s, clean exit at reason=sessionStopped harvested=142.

Now the failing session, same two events:

17:17:12.646  play returned after 152ms
17:17:12.869  [AetherEngine] overlay fed by packet-store drainer for stream=2 (backfilled 7 cues)
17:17:20.277  #151 forward prefetch exited (reason=cancelled cancelled=true) harvested=37
17:17:20.278  [AVIOReader] source conn start gen=1 offset=0 len=32MB

The ordering is inverted. Today our registration and select arrive at 0.36s and the drainer starts 0.8ms later as a result. In the failing session the engine had already brought stream 2 up by itself at 0.22s, and our registration did not arrive until 7.63s after that, at which point the prefetcher was cancelled and a sidecar decode opened.

We pass no subtitle intent in LoadOptions at all, no externalSubtitles, no preferredSubtitleLanguages, no initial track, so that 0.22s bring-up of stream 2 was the engine picking the container's default track on its own. Our late call then landed on an already-active embedded selection. My reading is that the trigger is a registration plus select arriving after the engine has already auto-selected the embedded default, rather than anything about which track was asked for.

I have not been able to force that late arrival again. Our pre-add wait is the obvious suspect and it is not it, it satisfies in 360 to 394ms in all three sessions today. That day the app was also loading home data right after, so it may simply have been a busy isolate.

Session B is the round-one shape you asked for, with the two fields that were missing:

t=30s   subCues=22  prefetch=park prefetchLead=76.3s prefetchHarvested=50  prefetchYielded=0s prefetchValve=0
t=60s   subCues=32  prefetch=park prefetchLead=76.3s prefetchHarvested=72  prefetchYielded=0s prefetchValve=0
t=90s   subCues=44  prefetch=park prefetchLead=75.1s prefetchHarvested=91  prefetchYielded=0s prefetchValve=0
t=120s  subCues=51  prefetch=park prefetchLead=76.2s prefetchHarvested=111 prefetchYielded=0s prefetchValve=0

Live loop, lead parked around 76s, harvest climbing, prefetchYielded and prefetchValve both zero throughout, prefetchTbFallback=0.

What we ruled out on our side for the failing session:

addExternalSubtitleTrack re-runs applyPreferredSubtitleSelection, which was the obvious way a registration could become a selection. Its first guard is !loadedOptions.preferredSubtitleLanguages.isEmpty, and we never set that anywhere, so registration cannot self-select for us.

restoreSubtitleSelection can reach startSidecarDecode through its .sidecar(url) case, but our only reloadAtCurrentPosition call is a foreground-return recovery guarded on state == .paused and playbackBackend == .none. That session played continuously and seams stayed at 1.

We do not call selectSidecarSubtitle(url:) anywhere.

If the ordering reading is right, the way to force it on your side is to let the engine auto-select the embedded default, then register an external track and select the embedded one several seconds later, rather than at bring-up.

[superuser404notfound]

Thanks for the client-side logging, and for the applySubtitleEvent correction. The 16-under-a-cap-of-20 count is the number that rules out budget exhaustion, and it is a better piece of evidence than anything I asked for.

Three things here. The third is the one that matters.

The sidecar: a late arrival cannot change what the call selects

Registration cannot self-select, and the guard you found is the whole of it: applyPreferredSubtitleSelection returns at !loadedOptions.preferredSubtitleLanguages.isEmpty before it reads anything else, so with no preferred languages set addExternalSubtitleTrack is a registration and nothing more, whenever it arrives.

That leaves the select, and your own new logs show the call site firing on this item:

17:24:03.846475  setSubtitleTrack index=2 external=true bitmap=false codec=subrip
17:24:03.846674  [AetherEngine] sidecar decode start: id=100000 stream=auto replacing embedded stream=-1

0.2 ms apart, in two of the three sessions. id=100000 is a registered external track's synthetic id, and the only route that writes it is selectExternalSubtitleTrack, reached from selectSubtitleTrack(index:) with an external id. A late setSubtitleTrack index=1 external=false cannot open a sidecar: that id routes to the drainer, exactly as your 17:41 session shows. So what differed in the failing session is which id the call carried, not when it arrived.

One thing worth checking on your side: registration APPENDS to subtitleTracks. A positional mapping computed after the addExternalSubtitle call sees a list one entry longer than one computed before it, and "index 1" then names a different track. That would produce a select that looks embedded in your model and arrives external at the engine, and it would be sensitive to exactly the ordering you found. Either way the next capture settles it, because the line now names the id and the stream it replaced.

The lead pinning at 60 s is the design, and session B is the proof

The drain window is playhead + subtitleDrainLeadSeconds, which is 60. A cue is therefore delivered when the lead edge crosses it, and the lead of each delivered cue climbing and then pinning at 60 is what a healthy session looks like, not what a failing one looks like. Session B, the one you call healthy:

cue	playhead	lead
76.576	16.900	59.68
79.037	19.500	59.54
81.039	21.600	59.44
84.083	24.700	59.38

That is the same table as the one in the issue body, from a session that was working. So "the harvest settles exactly one lead window ahead and stays there" describes the store working, and I should have said so in round one instead of taking it as the finding.

The cue count goes with it. subtitleCueRetentionSeconds is a ceiling on what is kept, not a floor on what exists: the store holds what THIS session decoded, and cues before the point playback started were never decoded by anyone. Your retainedFrom=-9.50, flat across all six resolution lines, says nothing was pruned at any point. The session in the issue body was a resume around 850 s (playhead 880.1 at its t=30s probe), so nine cues over 852 to 940 is a session that had been running half a minute, not a store that lost 45 of them.

What the probe did carry, and it is now fixed

One number in that probe had no innocent reading, and it is the one I left alone: prefetchLead=-215.8s under a LIVE loop (prefetch=yield), 30 s after two probes reading +74.5 and +74.7. A reader does not drift 290 seconds backwards through 30 seconds of playback. It was left there, and here is what leaves it there.

The forward prefetcher takes a pending re-anchor at exactly one point in its loop, and both of the loop's waits sit in front of that point:

• the link yield holds it while the video path is producing, for up to the whole 60 s cap
• the park holds it for as long as the banked read position stays past the playhead, which after a backward seek means until the viewer catches back up to where the reader already was

In both states the reader goes on banking packets for the stretch the viewer has left, the stretch he is in is harvested by nobody, and the drain has nothing to publish there. That is a dropout of tens of seconds in the middle of otherwise healthy playback, ended by whatever nudges the transport next, which is your step 4 and the up-button observation.

Merged as e8d9ddb, not released yet. A pending move now counts as freshly anchored for the arbitration, which is what the anchor grace already existed for (a reader positioned somewhere new has to fill against a busy video path), and the park breaks on a pending move because that move is what voids the position the park is judging. A seek in flight still wins the link; that rule sits above the grace and is untouched. Two tests in Issue240SideReaderLinkPriorityTests, one per wait.

What to watch for in the next capture: #151 forward prefetch re-anchored in place at Xs should now follow every seek promptly instead of tens of seconds later or not at all, and prefetchLead should not go negative under a live loop. If it does, the reader is being held somewhere I have not found yet and I would want that probe.

[superuser404notfound]

Released in 6.75.0 (f436d89). What to look for in the next capture: #151 forward prefetch re-anchored in place at Xs should now follow a seek promptly instead of tens of seconds later or not at all, and prefetchLead should not go negative under a live loop.

[RadicalMuffinMan]

6.75.0 verifies clean on both of the things you asked to watch for, and the ordinal question is closed with a log line rather than an argument.

The select carries the id we intend. I added a wrapper-side line naming the id that actually goes out and the table it was picked from. Five sessions on the failing item, every one identical:

[AetherPlayerWrapper] addExternalSubtitleTrack id=100000 file=Stream.subrip tableCount=1
[AetherPlayerWrapper] selectSubtitleTrack requested=1 route=ordinal id=2 external=false table=[2e,100000x]

The table is ordered as you would expect, embedded first and the registration appended after, so ordinal 1 resolves to id 2 and the embedded track is what we send. Your appending hypothesis was worth checking and it is not what happened here. Worth noting the table already showed both entries 0.7 ms after the add, so the publisher is not lagging the select either.

Re-anchors follow seeks promptly. A session with 33 seek generations in 49 seconds, plenty of them backward (833 to 807 to 777 to 767 to 748 to 728 to 710 to 690 to 632), produced 23 re-anchors. The longest gap between a new seek generation appearing and its re-anchor was 1.19 s.

#151 forward prefetch re-anchored in place at 833.24s (seek)
#151 forward prefetch re-anchored in place at 806.96s (seek)
#151 forward prefetch re-anchored in place at 776.96s (seek)

prefetchLead never went negative. Not once in the file. The probe under that seek storm reads prefetch=read prefetchLead=45.0s prefetchHarvested=522 prefetchYielded=5s prefetchValve=0. That is also the first non-zero prefetchYielded across any capture we have taken, so the yield path was exercised and released rather than sticking.

harvestHole still appears, six times, and repairs itself immediately. All six sit ahead of the playhead, between 18 and 55 seconds out, and every one is followed on the very next tick by a publish or a duplicate:

hole	next tick
gapAt=678.55 at playhead 623.50	published 7 cues
gapAt=623.54 at playhead 604.20	duplicate, 6 cues admitted
gapAt=426.88 at playhead 382.90	published 5 cues
gapAt=295.88 at playhead 250.30	duplicate, 1 cue admitted
gapAt=258.84 at playhead 241.20	published 7 cues
gapAt=258.84 at playhead 212.90	published 2 cues

The longest gap between delivery ticks across the whole session was 2.58 s. So the shape the issue body described, a detected gap that is never filled, is not what this build does.

The sidecar hijack still has not reproduced. Five sessions now with subtitleStreamIndex=3 at bring-up, no sidecar decode, no source reader, clean sessionStopped exits. I do not have anything new on it beyond what the wrapper line now rules out.

Sanitized log attached, the seek-heavy one.

moonfin-tvos-6.75.0-ae496-seek-storm.log

[superuser404notfound]

Verified from the attached file rather than from the summary: 23 re-anchors against 64 seek generations, worst lag from a programmatic began line to its re-anchor 1.53 s by my pairing (the gap to the 1.19 s is which line the pairing starts from, not the behaviour), 66 delivery ticks with a worst spacing of 2.58 s, and no negative prefetchLead anywhere in the file. So e8d9ddb1 does what it was meant to do, and the shape in the issue body is not in this build.

Two smaller things from the same read, on the record rather than as open questions.

Two ticks report outcome=undecodable (packets=1 events=0, at 09:55:49.297 and 09:55:53.912). Both are a single packet arriving at a seek boundary, which is what a flushed decoder produces, and neither is followed by a gap. Not worth chasing; if that ever shows up with more than one packet in the tick, it is a different animal and I would want the line.

The sidecar takeover has nothing left to chase from this end either. The wrapper line and the engine line now name the id and the stream at both ends of the same call, 0.7 ms apart, so if it returns the next capture names the side that chose the sidecar in one line instead of two rounds of inference.

On closing this one: the two indicators are the mechanism, not the symptom. Once ordinary viewing (no scrub storm) has gone a full film without a dropout, one line here and I will close it. If the sidecar takeover ever reappears it should get its own issue rather than reopening this one, since the mechanisms are unrelated.

Separately, thanks for the seek storm. It made something visible that has nothing to do with subtitles. At 09:55:32.138 the VOD backpressure park declared a wedge and tore down a healthy pump, 91 ms after the consumer had fetched seg181 and in the same millisecond it fetched seg182, discarding a 151 KB partial segment and 10.1 s of muxing work and nudge-seeking AVPlayer in the middle of the scrub. Two things had to be true at once for that. The park counts cache wakeups rather than seconds (parked climbs 12 to 22 in 2.400 s of wall clock, and the 24 s breaker fires inside a pump whose exit line reads elapsed=10145ms), so the busier the consumer, the faster the timer that measures its silence. And the wedge detector keeps a monotone high-water fetch target, so a viewer scrubbing backwards, who declares a lower target on every GET, is indistinguishable from a consumer that stopped fetching. Filed as #528 with the fix shape, and that capture is the whole evidence base for it.