An audio pick reloads with the raw panelIsInHDRMode, not the handshake's answer: an HDR title drops from the master to the media playlist and loses its AUDIO rendition

[cmcpherson274]

Split out of #459, which is closed.

Measured at 6.81.0 (c7e7adb5) on 2026-09-12, posted today (09-16); upstream is 7.1.0, eleven releases past it (6.82.0 → 7.1.0). Every engine region below is opened at both tags and says which moved. Its own issue rather than a #459 comment: #459 is closed completed and its residual #535 is the opposite direction — a label claiming more than the output carries, where this is a route claiming less after a pick. It borrows #459's vocabulary and nothing else.

The measurement

Office2, Apple TV 4K gen 3, tvOS 26.6 (23L773), Match Content on. At this pin our wrapper stopped asserting panelIsInHDRMode where the engine owns criteria ([Aether] panelIsInHDRMode not asserted …, 12:00:45.619), so the option is false and your readout decides. 3 from Hell (source probe: hevc 3840x2160 23.976fps hdr10 … audio=[1:truehd,2:dca,3:ac3,4:ac3]), resumed at 300 s, one audio pick to stream id 2 at +25 s (DEV-E6-hdr-after-audioswitch-shipped.log). Prefixes trimmed, URLs and unrelated fields elided (…); the rest verbatim.

09-12 12:00:46.158  [DisplayCriteria] panel readout before apply: currentEDR=1.00 potentialEDR=1.00 headroomLimit=unspecified switching=no matching=on hdrEligible=yes provenHDR=no
09-12 12:00:46.158  [DisplayCriteria] SET: format=hdr10 codec=hvc1 rate=23.976 extensions=HDR
09-12 12:00:46.587  [DisplayCriteria] panel proven to engage HDR (headroom 1.20); later sessions trust an accepted HDR write even after the headroom decays
09-12 12:00:48.259  [HLSVideoEngine] serving on …/master.m3u8 (… panelIsHDR=true displaySupportsHDR=true … useMaster=true videoRange=pq … audioLang=eng)
09-12 12:00:49.231  [NativeAVPlayerHost] #1 item videoFormat=hdr10 subType='hvc1' transfer=SMPTE_ST_2084_PQ rate=0.000

Then the pick, 25 s after started (route loopback, 4.2s):

09-12 12:01:14.763  [Aether] audio switch → id 2 (engine pipeline restart)
09-12 12:01:15.320  [HLSVideoEngine] serving on …/media.m3u8 (… panelIsHDR=false displaySupportsHDR=true … useMaster=false videoRange=pq … audioLang=eng)
09-12 12:01:16.205  [NativeAVPlayerHost] #2 item videoFormat=hdr10 subType='hvc1' transfer=SMPTE_ST_2084_PQ rate=0.000

Same panel, same title, still PQ on both sides, and panelIsHDR has gone true → false between them — that field is the panelIsInHDRMode the load was handed (6.81.0 HLSVideoEngine.swift:1972, 7.1.0 :1987, the emit line byte-identical), so the log is printing the gate's own input. The control is the same build, not an inference: JF_AETHER_PANEL_HDR=assert, our DEBUG rig restoring the pre-E-6 unconditional assertion for one launch, and both loads then serve the master (…-audioswitch-assert.log, useMaster=true at 12:02:18.675 and 12:02:45.492). Under our own previous panelIsInHDRMode: true the reload passed the same true and the drop could not happen, so this surfaced only when we stopped claiming — code-read, no audio-pick leg ran at the old pin.

Where it is, at both tags

	fresh load	reloadWithAudioOverride
6.81.0	panelIsInHDRMode: panelHDRAfterHandshake — AetherEngine.swift:4307	panelIsInHDRMode: loadedOptions.panelIsInHDRMode — AetherEngine+Loading.swift:2209
7.1.0	panelIsInHDRMode: routingPanelHDR — AetherEngine.swift:4467	panelIsInHDRMode: loadedOptions.panelIsInHDRMode — AetherEngine+Loading.swift:2234

The reload line is byte-identical across the span while the load term widened. grep -n 'loadNative(' returns three hits at each tag: the two call sites whose argument lists those lines sit in (6.81.0 AetherEngine.swift:4297 and +Loading.swift:2195, 7.1.0 :4457 and :2220) and the definition (+Loading.swift:674 at both). The reload never re-enters the handshake block — no panelHDRAfterHandshake, no currentPanelIsHDR() anywhere inside reloadWithAudioOverride at either tag — so neither the readout nor the latch is consulted.

routingPanelHDR is sessionRoutesAsHDRPanel(panelPresentsHDR: panelHDRAfterHandshake, attemptWhenUnproven: options.attemptsHDRMasterOnUnprovenPanel && !options.isLive, …) (AetherEngine.swift:4122-4126), body if panelPresentsHDR { return true }; return attemptWhenUnproven && displayEligibleForHDR && !panelRefusedHDRMaster (AetherEngine+Probe.swift:738-739) — 7.1.0 only; neither name exists at 6.81.0. Since attemptsHDRMasterOnUnprovenPanel defaults true, from 6.82.0 an unproven-but-eligible VOD panel is served the master on the first load and drops to media on the audio-pick reload, so the population this bites got bigger, not smaller — code-read at the tag. Everything here above 6.81.0 is read, not run: our bench is pinned at 6.81.0, and the attempt fires only on a panel that has not proved itself, which on the evidence above is not this box — so Office2 could not exercise it even at 7.1.0.

The raw option is the master gate one layer down — let panelReadyForHDR = panelIsInHDRMode || (builtInPanelEngagesOnDemand && displaySupportsHDR) … return sourceIsHDR && panelReadyForHDR (7.1.0 HLSVideoEngine.swift:2049-2066, byte-identical to 6.81.0 :2034-2051) — and its only escape, builtInPanelEngagesOnDemand, is #if os(iOS) || os(macOS) (6.81.0 :1982-1988, 7.1.0 :1997-2003), so a tvOS reload has nothing else to answer from. Issue459MasterFirstRoutingTests.swift, added in this span and absent at 6.81.0, has nine @Test cases, none of which mounts an engine: seven call sessionRoutesAsHDRPanel directly, one covers the rejection-code set, one the published label. The file contains no reload, no loadNative and no panelIsInHDRMode.

What it costs

Your own list of what media-direct costs, written under the new term: "not the picture but the manifest: the SUBTITLES rendition, the AUDIO rendition that is the only place AVFoundation reads an HLS language from, and SUPPLEMENTAL-CODECS" (api.md, attemptsHDRMasterOnUnprovenPanel — 7.1.0; no such entry at 6.81.0). A media-direct reload spends the same thing with no refusal to justify it — the master's body is in that slice (12:00:48.277):

#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="aud",NAME="English",LANGUAGE="eng",DEFAULT=YES,AUTOSELECT=YES

The second load asks for media.m3u8 directly and fetches no master at all (zero master.m3u8 and zero EXT-X-MEDIA lines in the slice after the pick), so on our stack what goes is the AUDIO rendition's language — your own AE#458 — at exactly the moment a viewer has just made an audio choice. The audioLang=eng on both serving lines is servedAudioLanguage, what the engine knows, not a tag in the manifest it served second. What AVFoundation then reports for that track we did not read back: unmeasured. Subtitles are painter-drawn on this rung, so the WebVTT half the same gate comment names (#15, 6.81.0 HLSVideoEngine.swift:2041 / 7.1.0 :2056) costs us nothing; it would cost a host reading native renditions. This title is HDR10 (dvVariant=none), so SUPPLEMENTAL-CODECS is not in our slice at all; a P8.1 would lose it here too — code-read: it is written as an EXT-X-STREAM-INF attribute (HLSLocalServer.swift:1375, the same line at both tags), which exists only in a master.

Your own note on hasAudioRendition ends "Routing-safety still decides: an unready HDR panel is a -11848 rejection, and a language is not worth one." (6.81.0 HLSVideoEngine.swift:2007-2014, byte-identical at 7.1.0 :2022-2029.) The reload's routing-safety is computed from a value that never met the handshake, so it declines the language without the rejection risk that would have justified declining it.

Suggestion, not a request

If the reload carried the same routing answer the fresh load computed, this closes with no second readout. That answer is a let local to load and is stored nowhere, so the reload has nothing to read it back from — panelHDRAfterHandshake at 6.81.0 (AetherEngine.swift:3972), and at 7.1.0 routingPanelHDR (:4122), which has exactly three references in the file: declared, compared against the label, passed to loadNative. An audio pick has no other branch: selectAudioTrack always routes through reloadWithAudioOverride (6.81.0 AetherEngine.swift:5948, 7.1.0 :6184). selectTitle and reloadAtCurrentPosition reach that same call only on a custom source; their URL branches re-run the handshake through load (6.81.0 :6005 and :4594, 7.1.0 :6241 and :4754).

Your −11868

"One correction to what I wrote yesterday: the code is -11868, not -11848. Both are in isDisplayRejectionCode so the net caught it either way…" — read as scoped to that run rather than as a counter-reading, and not something our shipped path meets: this panel proves itself on both legs above (panel proven to engage HDR (headroom 1.20)), the master is accepted, and there is no rejection to read. We do hold one -11868 master rejection on Office2, and it is not the shipped path: AVPlayer rejected the master (code=-11868); falling back to media playlist (no CC/subtitle renditions) at 302.30s, under JF_AETHER_CRITERIA=matcher — where our own assertion is in force — on the in-place reload after an audio-route death, whose serving line read displaySupportsHDR=false (DEV-E6-hdr-after-matcher.log, 11:58:29). The engine still names -11848 for this cost at both tags (6.81.0 AetherEngine.swift:3969, 7.1.0 :4112).

[superuser404notfound]

Confirmed as read, and fixed on main in 5448d3f (merge 24f6a4a). Not released yet, it goes out with the next engine release.

What was wrong. Exactly the asymmetry in your table: the fresh load hands loadNative the composed routingPanelHDR, reloadWithAudioOverride handed it loadedOptions.panelIsInHDRMode, and the rebuild runs no handshake to compose anything from. So a panel proven through the readout alone (no host assertion) was served media.m3u8 on the audio pick, and since 6.82.0 the unproven-but-eligible VOD panel dropped the same way.

What changed. The load now keeps the two terms a rebuild cannot take again: the criteria readout (nil when suppressed, as at the load) and the display's HDR eligibility. The reload composes its route through a new reloadRoutesAsHDRPanel from those two, plus:

• the session's current panelIsInHDRMode and attemptsHDRMasterOnUnprovenPanel, so a reloadAtCurrentPosition(applying:) correction still moves the route;
• the refusal latch read at reload time, not carried from the load, so a master the panel refused after the load is not served a second time;
• isLive, which still never attempts on an unproven panel.

I took the route that recomposes over storing the single routingPanelHDR bool, because a stored answer would have frozen out both the correction and a later refusal.

What proves it. Issue541ReloadCarriesHDRRouteTests: your case (no assertion, readout true at load, reload keeps the master), the unproven attempt, the post-load refusal, live, suppressed-without-assertion unchanged, a corrected assertion, and an exhaustive pass over all 96 input combinations asserting the reload reaches the same answer the load's own two-step composition reaches. One more test scans the reload call site so the raw option cannot creep back in. All of it is decision-level; like the #459 file, nothing here mounts an engine, and I have not run an audio pick on a device against this commit.

What to look for on a retest. Whenever the reload's route differs from the raw option, a new line comes out right before the second serving line:

[DisplayCriteria] AE#541 reload routes on the load's panel answer: panelIsHDR=true (hostAsserts=false readoutAtLoad=true eligible=true refusedLatch=false)

On your Office2 leg (option false, readout proven) I expect that line, then serving on …/master.m3u8 (… panelIsHDR=true … useMaster=true …) after the pick, and the EXT-X-MEDIA:TYPE=AUDIO body fetched again. What AVFoundation then reports as the track's language is still the unread half, same as you left it.

On the -11868 section: agreed on the scoping. The engine comment that still names only -11848 for this cost is prose, not a gate (isDisplayRejectionCode holds both), and I left it alone in this change.

[superuser404notfound]

Released in 7.1.2 (77cab2b7), which carries 5448d3f5. Sodalite and AetherPlayer are both pinned to it now. Still open for the retest; the [DisplayCriteria] AE#541 reload routes on the load's panel answer line is the one to look for before the second serving line.

[cmcpherson274]

Retested on 7.1.3 (13a86172), which carries 7.1.2 (77cab2b7) and so 5448d3f5. Office2, Apple TV 4K gen 3, tvOS 26.6 (23L773), Match Content on; same leg as the filing — 3 from Hell (source probe: hevc 3840x2160 23.976fps hdr10 … audio=[1:truehd,2:dca,3:ac3,4:ac3] …), resumed at 300 s, one audio pick to stream id 2 at +25 s. No host assertion, panel proven through the readout: [Aether] panelIsInHDRMode not asserted … 14:30:43.308, [DisplayCriteria] panel proven to engage HDR (headroom 1.20) … 14:30:44.199. It passes. Prefixes trimmed, URLs and unrelated fields elided (…); the rest verbatim.

The arc you named

09-17 14:30:45.919  [HLSVideoEngine] serving on …/master.m3u8 (… panelIsHDR=true displaySupportsHDR=true … useMaster=true videoRange=pq dvVariant=none audioLang=eng)
09-17 14:31:12.216  QA: JF_AUDIO_SWITCH firing — audio 2
09-17 14:31:12.221  [Aether] audio switch → id 2 (engine pipeline restart)
09-17 14:31:12.227  [AetherEngine] reload: loadNative enter audio=2 resumeAt=325.20s
09-17 14:31:12.228  [DisplayCriteria] AE#541 reload routes on the load's panel answer: panelIsHDR=true (hostAsserts=false readoutAtLoad=true eligible=true refusedLatch=false)
09-17 14:31:12.800  [HLSVideoEngine] serving on …/master.m3u8 (… panelIsHDR=true displaySupportsHDR=true … useMaster=true videoRange=pq dvVariant=none audioLang=eng)
09-17 14:31:13.489  [NativeAVPlayerHost] #2 timeControlStatus=playing reason=- t+0.69s

The line lands 7 ms after audio switch → and 572 ms before the second serve, and its four fields are this case exactly: hostAsserts=false, readoutAtLoad=true (proven through the readout alone), eligible=true, refusedLatch=false. That is byte-identical to the line you wrote in the fix comment — all four field values included — predicted without having run an audio pick on a device against this commit, as you said. Both serving lines of the sitting are on the master. AE#541 occurrences in the leg: 1; at 6.81.0, 0 — the literal arrives at 7.1.2.

6.81.0, same rig, same box — the drop as filed

09-12 12:00:48.259  [HLSVideoEngine] serving on …/master.m3u8 (… panelIsHDR=true displaySupportsHDR=true … useMaster=true videoRange=pq dvVariant=none audioLang=eng)
09-12 12:01:14.763  [Aether] audio switch → id 2 (engine pipeline restart)
09-12 12:01:15.320  [HLSVideoEngine] serving on …/media.m3u8 (… panelIsHDR=false displaySupportsHDR=true … useMaster=false videoRange=pq dvVariant=none audioLang=eng)

The negative control

JF_AETHER_PANEL_HDR=assert — our rig for the pre-E-6 unconditional assertion — same title, same pick: host assertion in force: panelIsInHDRMode=true … (observed: panelReadout=true …) 14:32:14.109, then master 14:32:14.191 → master 14:32:41.048, and zero AE#541 lines. That is the emitter agreeing, not missing: 7.1.3 AetherEngine+Loading.swift:2227 gates the emit at :2228-2233 on inequality, and with hostAsserts=true reloadRoutesAsHDRPanel returns at the first line of sessionRoutesAsHDRPanel (7.1.3 AetherEngine+Probe.swift:738), equal to the raw option. The same arm at 6.81.0 also stayed master → master.

Your two open halves

The EXT-X-MEDIA body — fetched again, yes, and by AVFoundation rather than re-served internally:

09-17 14:31:12.807  [HLSLocalServer] GET /c51f602…/master.m3u8 HTTP/1.1 fd=16
09-17 14:31:12.808  [HLSLocalServer] first request headers fd=16: … X-Playback-Session-Id: 95DE80CE-… | … | User-Agent: AppleCoreMedia/1.0.0.23L773 (Apple TV; U; CPU OS 26_6 like Mac OS X; en_us) | …
09-17 14:31:12.809  [HLSLocalServer] master.m3u8 body:
                    #EXTM3U
                    #EXT-X-VERSION:7
                    #EXT-X-INDEPENDENT-SEGMENTS
                    #EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="aud",NAME="English",LANGUAGE="eng",DEFAULT=YES,AUTOSELECT=YES
                    #EXT-X-STREAM-INF:…,CODECS="hvc1.2.4.H153.90,fLaC",RESOLUTION=3840x2160,FRAME-RATE=23.976,VIDEO-RANGE=PQ,AUDIO="aud",CLOSED-CAPTIONS=NONE
                    media.m3u8
09-17 14:31:12.811  [HLSLocalServer] GET /c51f602…/media.m3u8 HTTP/1.1 fd=16

#EXT-X-MEDIA … LANGUAGE="eng" in the leg: 2 at 7.1.3 (fresh load + reload), 1 at 6.81.0 — where the first request after the pick is media.m3u8 and the whole slice after the pick carries 0 master.m3u8 and 0 EXT-X-MEDIA lines.

What AVFoundation reports as the track's language — still unread, exactly where we left it. The slice carries no readback of it: zero matches for extendedLanguageTag, languageCode, locale, or any media-selection line. Case-insensitively, lang appears in exactly three tokens in the whole leg — audioLang ×2 (the engine's servedAudioLanguage on the two serving lines, what the engine knows), LANGUAGE ×2 (the manifest the engine served, quoted above), and Accept-Language ×2 (CoreMedia's request header, the box's UI language, not the track's). The nearest thing either load prints is #2 asset.load(tracks) ok … count=0 (14:31:12.806), which for HLS is expected — the renditions arrive as media selection groups on the item, and there is no audible-group read to log on either side: no code path reads the .audible group — .audible has no match under Sources/ at 7.1.3 — and every loadMediaSelectionGroup call in the engine and in our wrapper is .legible. Reading it wants a host-side AVMediaSelectionGroup/AVMediaSelectionOption dump after the reload, and we have not written one. Scope note while it is open: this pick is stream id 2 (dca) inside the single eng rendition the master declares — a track choice, not a language choice — so what the restored rendition buys here is the group AVFoundation reads a language from, not a different language.

Where that leaves it

The fix does its work on the one configuration of ours that can show it — a panel proven through the readout, with no host assertion — on the box that had the case, and the control is silent for the reason the composition gives. Closeable on our side. Your -11868 note needs nothing further from us. Both retest legs do end in one — #2 failedToPlayToEndTime AVFoundationErrorDomain/-11868 'Cannot open' at t+44.9 s / t+45.0 s, a segment served ~0.5 s earlier and app → background 0.5–0.6 s after — but it is neither new nor these legs': a teardown -11868 sits on twelve of this hold's 62 device legs, from t+26 s to t+107 s, and the same shape opens the 6.81.0 slice above, left there by the leg before it (-11868 at t+57.12s → app → background 0.6 s later → the same #93 item death stage-2 recovery). It predates the fix and it is ours to chase, not yours. Two readings while we are in there: neither arm carries AVPlayer rejected the master (code=…); falling back to … — 0 matches each — and it could not, that branch being inside handleItemFailed's if !hasEverPlayed while these sessions had been playing ~45 s; and what the engine did instead is the last line of each slice — #93 item death (failedToPlayToEndTime) at 0.00s; reloading item through stage-2 recovery (attempt 1, pause guard bypassed) — after which the recording ends.

Open on our side: the language readback above, unmeasured.

[superuser404notfound]

Read, and closing on that sign-off. Thanks for the arc, and for running the control: a green arm on its own would not have separated "the composition agrees" from "the emitter never ran". With hostAsserts=true, reloadRoutesAsHDRPanel returns at the first line of sessionRoutesAsHDRPanel, equal to the raw option, and the emit is gated on inequality, so zero lines there is the code agreeing.

One term has moved under it since the 7.1.3 leg. 7.5.0 (36d4d2b7, #535) makes a session read the display once and keeps that table, and the eligible field the AE#541 line prints now derives from it (AetherEngine.swift:569, sessionObservedDisplayCaps?.supportsHDR ?? false) instead of being a second bool stored beside the readout. The composition is otherwise unchanged and the line reads identically; Issue541ReloadCarriesHDRRouteTests passes on a6c6f8d1 (8 tests, including the exhaustive pass over all 96 inputs and the call-site scan). What that rework buys this issue is that the load's answer and the rebuild's are one value now rather than two that could drift apart.

The language readback is unread on this side too, and it belongs to #458. The grep matches on 7.5.0: .audible has no match under Sources/, every loadMediaSelectionGroup in the engine is .legible, so nothing here reads what AVFoundation resolved. The nearest measurement anywhere is in the test suite rather than on a box, Issue458AudioLanguageMetadataTests, which drives a real AVPlayerItem over a served fixture and reads the audible group (extendedLanguageTag=cnr, displayName=Montenegrin), with the invalid-tag control leaving the group nil. That is a Mac, and a fresh load rather than a reload. The scope note is the right one: id 2 (dca) inside the single eng rendition is a track choice, so what the restored master buys is the group a language is read from, not a different language. If AVKit ever shows "Not Specified" after an audio pick on a master-served title, #458 is where that goes.

On the -11868: agreed, and the code reading holds. The master-rejection hand-off sits inside handleItemFailed's if !hasEverPlayed (NativeAVPlayerHost.swift:926), so after ~45 s of playback it cannot fire and "0 matches" is the only thing that branch could have printed. app -> background half a second behind each one, on 12 of 62 legs across the hold, is the shape of a teardown rather than anything the route decided.