The warm's head is dropped by the cue prewarm and then re-fetched by playback's first read

[superuser404notfound]

Measured while fixing AE#551 round 2 (PR #584), on a 63 MB MKV served by a Range-logging origin.

A warm adopts an 8 MB head, and AVIOReader keeps that span past the parse on purpose (#281 retest: "the head has now done the job it was kept past the parse for"). The drop rule is the first read that lands outside it:

if !openPhaseActive, !headSpan.isEmpty, spanPos < 0 || spanPos >= Int64(headSpan.count) {
    headSpan = Data()
}

The open phase ends at probeStreams, and the very next thing the native path does is HLSVideoEngine's cue prewarm: a seek to the middle of the title. That read is outside the head, so it drops the span. Playback's first read then goes BACKWARD to the head of the file (the anchored connection sits at the end after a trailing-index parse), and the bytes the warm paid for are fetched again:

3792ms REQ bytes=8388608-41943039      <- pump, starting at the warm frontier
3895ms REQ bytes=0-4194303             <- re-fetching the warm head
4085ms REQ bytes=4194304-8388607       <- and the rest of it

8 MB re-downloaded per session on this path, and the whole warm head is spent on nothing but the parse. The same shape is in the pre-fix log, so this is not from PR #584; the warm just makes it easy to see, and it is the one remaining cost between a warmed session and a cold one.

The rule reads "playback has either moved beyond it or started nowhere near it", and neither is true here: the read that drops it is index work, not playback, and it is followed immediately by a read at offset zero. Worth deciding whether the phase that may drop resident spans should end after the index pass rather than after probeStreams, since the cue prewarm is bounded and known-short.

[superuser404notfound]

Fixed on main in 8ac5c256 (merge a5feb45a, PR #596), not in a release yet.

The premise of #281's drop rule is that the read is playback's. The index pass states that it is not, and the rule is unchanged around it: AVIOReader holds resident spans while the pass is active, HLSVideoEngine brackets from decideCompositionOffsetRepair to the step 6 cursor reset, and AVIOProvider gets no-op defaults so no other provider changes behaviour.

Measured on a 46,738,174 B MKV with Cues at the end, over a Range-logging origin with 50 ms before every response header, aetherctl play --prewarm --seconds 12:

arm	requests	bytes fetched
before	5	50,334,221
after	3	41,945,613

The two that disappear are bytes=0-4194303 and bytes=4194304-8388607, which is the warm head a second time, and the line that could not appear before now does: retained file head served playback's first read at 752; no reconnect for it. A cold session without a warm is unchanged, 3 requests on both arms.

One thing left deliberately alone, since it is a sizing question rather than this defect: the adoption takes the warm head whole (default warm budget 8 MiB) while the reader's own self-collected head is capped at 4 MiB, which is why the re-fetch in the report was two requests rather than one. Worth deciding once whether the cap should follow the budget, but the head that is kept now is the one that was paid for.

Issue585IndexPassKeepsTheHeadTests pins both halves, including that the release works again once the pass ends, which is the way this could have quietly cost footprint instead of saving round trips.

[superuser404notfound]

Released in 7.12.0 (8ac5c256, merge a5feb45a). Both consumers are pinned to it, so the next build of either carries it.