Stats can name Dolby Vision when the output is parked in 4K HDR: the capability table answers what the panel CAN present, not what it is presenting

[superuser404notfound]

Split out of #459, which is closed: the defect that issue was filed on (HDR and Dolby Vision titles labelled as converted to SDR on a box whose output is locked to HDR) is fixed in 6.82.0 and confirmed on two boxes. This is the residual classicjazz found while running the full matrix on build 30, and it is the opposite direction: a label that claims MORE than the HDMI output carries.

The case

Apple TV 4K, output parked in 4K HDR (not 4K Dolby Vision), Match Dynamic Range off, Match Frame Rate on, source is Dolby Vision Profile 7, panel is a DV-capable LG OLED.

The TV reports HDR10 for the title. Stats read Dolby Vision P7, with no arrow. By the label's own rule the honest value is Dolby Vision P7 -> HDR10.

Why it happens

The Dolby Vision term in the capability clamp is AVPlayer.availableHDRModes, which answers what the DISPLAY can present. It does not follow the box's current output-format setting, exactly as eligibleForHDRPlayback does not: the pair of force-quit readouts on #459 read byte-identical with the output locked to 4K Dolby Vision and to 4K SDR, two configurations whose correct answers are opposite.

effectiveVideoFormat therefore resolves .dolbyVision, and the acceptance readout added in 6.82.0 cannot supply the missing half. Acceptance proves the panel presents HDR, never which HDR mode: with the output parked in 4K HDR the Apple TV takes the Dolby Vision master and converts it, so there is no -11868 refusal to read. Compare a panel with no Dolby Vision in its EDID at all (Samsung HDR10+, DrHurt): the table names no .dolbyVision, the clamp resolves .hdr10, and the arrow appears correctly.

So the row names the best format the chain can carry, and in this one configuration that is one step above what leaves the HDMI port.

Why the obvious narrowing is not the fix

Publishing the base layer whenever the HDR proof came only from acceptance would relabel every Dolby Vision title on a box parked in 4K Dolby Vision with Match Dynamic Range off. That is the configuration both reporters on #459 actually run, and most likely the common one. It trades a rare wrong arrow for a frequent one.

Any real fix needs the value no public API exposes: the output mode the box is currently in. isDisplayCriteriaMatchingEnabled is a single combined flag covering Match Dynamic Range and Match Frame Rate, so it cannot even tell the two configurations apart, and currentEDRHeadroom is measured silent on a parked box (#459, three boxes, three OS versions).

What would confirm the mechanism

One diagnostic line, taken with the output locked to 4K HDR on a DV-capable panel:

[HLSVideoEngine] serving on ... (dvModeAvailable=... effectiveDvMode=... useMaster=...)

dvModeAvailable=true there is the table answering capability rather than presentation, which is what this issue assumes.

Status

Known limitation, kept open as the anchor for the Feedback Assistant report, not as work in flight. Nothing here affects the picture: the Apple TV converts, and the title plays in the mode the output is parked in either way.

[cmcpherson274]

Data for the Feedback Assistant report, not a second reading of the defect above — and first, what we cannot give you.

Your diagnostic line wants that serving on … line taken with the output locked to 4K HDR on a DV-capable panel, in a case whose other half is Match Dynamic Range off. Match Dynamic Range is on here — matching=on on 88 of our 91 distinct panel readouts is your combined flag, and the Dynamic Range half of it shows in the panel engaging the engine's HDR criteria — so the output follows the source and there is nothing for the table to diverge from. Our closest leg is a P8.4 title, served as master.m3u8 with dvModeAvailable=true: the engine wrote SET: format=dolbyVision codec=dvh1 rate=default(24) extensions=HDR and the panel took it — panel proven to engage HDR (headroom 1.20), then switch settled via modeSwitchEnd (… panel 24.001Hz, the requested rate). That is the configuration your issue contrasts with, not the one it is about. Turning Match Dynamic Range off is a by-hand tvOS Settings flip on a shared bench box that no driver of ours can script; we have not run it.

What we do hold is the same property reading two different answers, twice, on one Apple TV.

Bench: Apple TV 4K gen 3, tvOS 26.6 (23L773), a DV-capable panel, AetherEngine 6.81.0 (c7e7adb5), measured 2026-09-12. Upstream is 7.1.0 today; every anchor below is opened at both tags.

Corpus, recounted for this comment: 58 retained device slices from that bench session, carrying 103 [DisplayCapabilities] observed: lines. 102 read hdr=true hdr10=true hlg=false dv=true; one reads all-false. The slices overlap (our harness keeps re-cuts), so deduplicated that is 75 distinct readings against the one. matching= reads on 122 / off 4 raw, 88 / 3 deduplicated — the three off readings are the two episodes below.

Episode A — 12:51, across a process boundary

The outgoing process, mid-teardown:

09-12 12:51:13.752  [session] app → background
09-12 12:51:16.283  audio route died — in-place Aether reload at position (budget-free)
09-12 12:51:16.290  [DisplayCapabilities] observed: hdr=true hdr10=true hlg=false dv=true
09-12 12:51:16.396  [DisplayCriteria] panel readout before apply: currentEDR=1.00 potentialEDR=1.00 headroomLimit=unspecified switching=no matching=off hdrEligible=no provenHDR=no

Same process, 106 ms apart, both sites reading the identical expression — AVPlayer.eligibleForHDRPlayback at AetherEngine.swift:1325, feeding supportsHDR: at :1328, composed once per load at :3516 and printed at :3523; and the same expression again at Display/DisplayCriteriaController.swift:1185. At 7.1.0 the read, the compose and the emit are byte-identical (:1352, :3659, :3666), and so is the criteria readout (:1209). The one line that moved is :1328 — the table is assembled elsewhere now, below.

The next process — a fresh launch whose first log line is 10.4 s after that background, tuning at .309 — read all-false. Our own call to AVPlayer.availableHDRModes had come back EMPTY 85 ms earlier, from a second call site in our process rather than a second source (one of its 69 readings in the corpus, and its only false one):

09-12 12:51:24.280  display DV capability: false (G-HDR7 — drives the DOVI advertisement); display HDR modes present: false (drives the P2 HDR-remux reroute)
09-12 12:51:24.365  [DisplayCapabilities] observed: hdr=false hdr10=false hlg=false dv=false
09-12 12:51:24.418  [AetherEngine] load url=… source-format=dolbyVision effective-format=sdr rate=59.940
09-12 12:51:24.421  [DisplayCriteria] panel readout before apply: … headroomLimit=unspecified switching=no matching=off hdrEligible=no provenHDR=no
09-12 12:51:24.425  [HLSVideoEngine] serving on …/media.m3u8 (dvModeAvailable=false effectiveDvMode=false panelIsHDR=false displaySupportsHDR=false matchContent=true sourceIsHDR=true useMaster=false videoRange=pq dvVariant=profile5 audioLang=none)

A Profile 5 title clamped to effective-format=sdr and served media-direct, master withheld, on a box that reads dv=true on the other 102 readings. The item itself still reported #1 item videoFormat=dolbyVision subType='dvh1' transfer=SMPTE_ST_2084_PQ — P5 carries its DV in-band. What mode the panel was actually in is unmeasured; the frame we captured cannot say.

Episode B — four hours earlier, one process, an HDR10+ title

One launch, no second process, and the flip falls either side of the background transition:

09-12 08:49:54.184  [DisplayCapabilities] observed: hdr=true hdr10=true hlg=false dv=true
09-12 08:49:54.235  [DisplayCriteria] panel readout before apply: … headroomLimit=unspecified switching=no matching=on hdrEligible=yes provenHDR=no
09-12 08:53:24.129  [session] app → background
09-12 08:53:26.526  audio route died — in-place Aether reload at position (budget-free)
09-12 08:53:26.539  [DisplayCapabilities] observed: hdr=true hdr10=true hlg=false dv=true
09-12 08:53:26.616  [DisplayCriteria] panel readout before apply: … headroomLimit=unspecified switching=no matching=off hdrEligible=no provenHDR=yes

The first readout is 0.4 s after launch, the last 3 m 32 s later; the closing pair is 77 ms apart, and that readout contradicts itself on its own line — hdrEligible=no provenHDR=yes. Both loads resolve source-format=hdr10 effective-format=hdr10.

What does and does not explain it

headroomLimit reads unspecified on all 126 readouts in the corpus (91 distinct) — never active, never inactive — so the term you print for precisely this class says nothing here. Your own doc block, quoting the header, names an app's windows being in the background as a case where HDR headroom use is disabled, and an ACTIVE limit as what caps the headroom properties (Display/DisplayCriteriaController.swift:641-644 at 6.81.0; the same text at :669-672 at 7.1.0).

7.1.0 moves it neither way. DisplayCapabilities.observedPerModeTable (PlayerState.swift:295-298) floors HDR10 and HLG on eligibility, so on an all-false reading it computes false || false twice and the table is byte-identical to 6.81.0's; and supportsHDR: hdrEligible was already the rule at 6.81.0, so an || floor can only add.

The bracket the two same-process contradictions share: each sits inside an audio-route-death reload that opened 2.53 s (A) and 2.40 s (B) after [session] app → background. Episode B is the sharper half — matching=on hdrEligible=yes at its first load, matching=off hdrEligible=no after it backgrounded, one process, one expression. Two candidates, neither established: (a) a backgrounded or not-yet-frontmost app being answered for its own UI state rather than for the display; (b) an HDMI re-handshake after the previous session's teardown-time criteria reset.

The corpus's third route-death reload (11:58:28.878) is the nearest thing to a control, and not a clean one. Its process launched 9.8 s after the previous leg's app → background — Episode A's shape — and read hdr=true at both call sites (.796 ours, .896 yours); the reload 4.3 s later read hdr=true again, with no backgrounding inside that process. So the launch shape alone does not produce the all-false reading. But that leg ran under our own JF_AETHER_CRITERIA=matcher rig — the host asserts panelIsInHDRMode, you answer panelReadout=suppressed, the slice carries no hdrEligible term at all — so criteria ownership differs from both episodes and we do not read it as a control.

What we did not read. We emit app → background (50 distinct lines) and no foreground or active counterpart anywhere in the corpus, so neither episode can be placed against our own lifecycle at the instant; and we never read the panel's actual mode.

Not a reproduction. One box, two episodes, one day. A leg is queued for our next bump: a deep-link tune 2–15 s after a backgrounded teardown, the capability line read against app lifecycle lines we have to add first, repeated enough to say whether it recurs. The real-world analogue is live in our Release build — a Top Shelf tevemate://play/<id> deep link during a cold launch, where an HDR title would start media-direct. We will report either way.

[superuser404notfound]

Thank you, this is useful well beyond what the issue asked for. Every anchor checks out at both tags: c7e7adb5 is 6.81.0, and the read, compose and emit sit at :1325/:3516/:3523 there and :1352/:3659/:3666 at 7.1.0, with DisplayCriteriaController.swift:1185 → :1209. Understood on Match Dynamic Range: with it on there is no parked output to diverge from, and your P8.4 master leg is the contrasting case. #535 stays as it was, waiting on that one line.

On the two episodes, one term in your own readouts narrows the candidates more than the eligibility flip does: matching=off.

isDisplayCriteriaMatchingEnabled answers a tvOS Settings preference. An HDMI re-handshake has no way to change it, and nobody changed it by hand. Yet across your 91 distinct readouts it reads off only 3 times, and all 3 sit in your two episodes, each next to hdrEligible=no: Episode A's outgoing readout, the fresh process in Episode A, and Episode B after the background transition. When a user preference and a display property flip together, the display didn't change. What changed is whether the process is allowed to ask. That points at candidate (a), the app being answered for its own non-frontmost state, and away from (b). It doesn't settle it: the fresh process in Episode A still has no lifecycle line.

Two more details from the same lines:

• In both episodes the flip lands mid-load, not between loads. The engine's [DisplayCapabilities] observed: line read hdr=true dv=true (A .290, B .539), and the criteria readout of the same load read hdrEligible=no matching=off 106 ms and 77 ms later. Both sit about 2.4 to 2.5 s after app → background. So the revocation lags the transition by a couple of seconds and doesn't happen at the notification. A read taken right at didEnterBackground would probably still see the old answers.
• Episode B never reached routing. Its load composed from the true reading and resolved hdr10 → hdr10. Only Episode A's fresh process composed from an all-false table, which is how a Profile 5 title ended up effective-format=sdr and media-direct.

The engine side of this, stated plainly: on tvOS, a video session that exists at didEnterBackground (no PiP) is torn down, and the host is expected to reload on return. A load() issued after that, while still backgrounded, isn't caught by that policy. It composes its route and applies criteria from whatever the platform answers in that state, and nothing re-reads the table at didBecomeActive. Episode B's route-death reload is exactly that shape. I'm not changing behaviour on one box and one day. If your queued leg shows the all-false reading recurring on a load issued before the app is active, that gap is where the fix goes, in the engine and not in a host.

For that leg, the term that decides it is UIApplication.shared.applicationState (or the scene's activationState) read on the same run loop turn as each capability read, not just lifecycle notifications around it. A notification can only tell you a transition happened. It can't tell you whether a read 30 ms after launch came before activation. A control with the app already frontmost when the deep link arrives would separate "launched by a deep link" from "read before active".

[cmcpherson274]

The line is in. And before the leg meant to exercise it ran, the transient recurred on its own.

Bench: Apple TV 4K gen 3, tvOS 26.6 (23L773), a DV-capable panel; pin 7.1.3 (13a86172), measured 2026-09-17. Corpus: 57 retained device slices at 7.1.3 — 88 [DisplayCapabilities] observed: lines, 87 panel readout before apply lines (104 readouts of both kinds), 58 app → background, 2 audio route died — plus 5 slices from a 6.81.0 control build of our app, run on the same box the same afternoon (dev-e7-control.stdout.log:3, revision": "c7e7adb5). Unlike the E-6 corpus, these slices do not overlap: for all four line types above the raw and deduplicated counts are equal.

1. The lifecycle line exists. App/RootView.swift:203 emits app → active (fresh process) when scenePhase goes .active with no recorded background transition. 56 of the 57 slices at 7.1.3 carry exactly one, none carries two, and the 57th is 0 bytes — our harness lost that launch. The five 6.81.0 control slices carry none. Examples: DEV-E7-440-rejoin-u12.log:340 at 15:27:27.898, DEV-E7-sdrvod-attempt.log:148 at 14:33:40.714.

Its limit is the one you named. In the slice below, that process's first capability read is ours at 14:54:19.755 (App/DisplayModeMatcher.swift:315, off the AVPlayer.availableHDRModes query at :307), your [DisplayCapabilities] observed: follows 90 ms later, and the lifecycle line lands at 14:54:20.645 — 890 ms after the first read. A notification cannot bracket a read that early.

2. The same-turn state read is not wired. grep -rn 'applicationState\|activationState' App/ returns one hit, App/DisplayModeMatcher.swift:93, a scene lookup for AVDisplayManager — not a read beside our own capability read at App/DisplayModeMatcher.swift:307. It is queued with the leg (a deep-link tune 2–15 s after a backgrounded teardown, repeated, plus the already-frontmost control). None of that ran this session.

3. It recurred at 7.1.3, incidentally rather than by design. One process, in DEV-E7-audiosync-reset-a.prev-145735.log, during an audio-sync leg. The app backgrounded at 14:54:35.095 — the log does not say what backgrounded it, and our next leg did not launch until 14:55:20 (DEV-E7-audiosync-reset-b.prev-145835.meta) — and the route died 696 ms later (App/AetherPlayerEngine.swift:1787 guards oldDeviceUnavailable, :1799 emits the line):

09-17 14:54:35.095  [session] app → background
09-17 14:54:35.791  audio route died — in-place Aether reload at position (budget-free)
09-17 14:54:35.793  [DisplayCapabilities] observed: hdr=false hdr10=false hlg=false dv=false
09-17 14:54:35.814  [DisplayCriteria] panel readout before apply: … headroomLimit=unspecified switching=no matching=off hdrEligible=no provenHDR=no
09-17 14:54:35.814  [DisplayCriteria] skipped: Match Content disabled (both Dynamic Range AND Frame Rate off)

Those are :159, :169, :175, :190, :191. One engines: line in the file (:3), so everything from :3 on is one process; 15.9 s before that all-false read the same process had read hdr=true hdr10=true hlg=true dv=true (:32) and matching=on hdrEligible=yes (:50), and served a master (:75). A second reload at 14:54:37.910, our own audio-delay correction, read all-false again (:280, :298). Deltas from app → background: +696 ms, +698 ms, +719 ms. The two episodes were +2.53 s and +2.40 s, so the lag is not fixed at a couple of seconds, and here the answers were already revoked at ~0.7 s.

And it came back. The same process logged app → active (backgrounded 37s) at 14:55:12.569 — DEV-E7-audiosync-reset-b.prev-145835.log:3; that slice's first 146 lines are still this process, the next engines: is :147, and the (backgrounded 37s) form renders only when a background transition was recorded inside the same process (App/RootView.swift:193-195). 8 ms after it, the panel readout before reset reads matching=on hdrEligible=yes (:6); 133 ms after it, hdr=true hdr10=true hlg=true dv=true (:29). One process, one expression, revoked while backgrounded and reading true again 133 ms after the app came back — both directions in one process, which the E-6 episodes could not give. When it was restored is unread: the 34.8 s between the last false read and that one carries no capability read at all.

The control the E-6 corpus lacked. The other route death at 7.1.3 — DEV-E7-dv-p5.log:192, 15:48:21.634 — sits 28.7 s after its own process's app → active (fresh process) (:68), with no background transition inside that process before it (the slice opens with the previous process's background at :1; this process begins at :14). It reads hdr=true hdr10=true hlg=true dv=true (:198) and matching=on hdrEligible=yes provenHDR=yes (:211). And the sweep behind it: across the 58 app → background lines in the 57 slices, exactly one process took any [DisplayCapabilities] observed: read while backgrounded — no app → active and no engines: in between — and it took two, both all-false, at +0.698 s and +2.82 s after the transition. The other 86 split three ways against our own lifecycle lines, and the largest part is unread: 38 follow an app → active line in the same slice; the other 48 are taken 0.66–0.87 s before their own process's app → active (fresh process) (median 0.795 s, 0 exceptions) — the window your applicationState term is for, and one a lifecycle line cannot resolve. All 86 read hdr=true hdr10=true hlg=true dv=true. Consistent with candidate (a); one box, and not the reproduction.

What the revoked flag is taken to mean. Every matching=off readout we hold — 2 at 7.1.3, 4 raw / 3 distinct in the 09-12 corpus, none in the five 6.81.0 control slices — is followed on the same millisecond or the next by [DisplayCriteria] skipped: Match Content disabled (both Dynamic Range AND Frame Rate off). The revoked read is consumed as the user's setting.

4. There are two capability reads on a native load, and twice they disagreed. On "Episode B never reached routing": the table you print is composed at AetherEngine.swift:3516 (6.81.0), :3659 (7.1.0), :3669 (7.1.3) — and AetherEngine+Loading.swift:739, that same line at all three tags, re-reads Self.displayCapabilities for the HLS session it constructs inside loadNative (:674 at 7.1.3), printing only its derived dvModeAvailable= and displaySupportsHDR=. A load that never reaches the HLS server takes only the first read — §6's three software-route loads. Two E-6 loads disagree across that pair. The first is Episode B: 08:53:26.539 observed: … dv=true → 08:53:26.742 serving on …/media.m3u8 (dvModeAvailable=false … displaySupportsHDR=false … sourceIsHDR=true useMaster=false videoRange=pq …), 203 ms apart (DEV-E6-rewound-hold.prev-121530.log:2649/:2715) — so that HDR10+ title did lose its master. The second is 11:58:28.938 → 11:58:29.477, 539 ms apart (DEV-E6-hdr-after-matcher.log:211/:270) — the matcher-rig leg, whose criteria ownership differs and which we do not read as a control; it kept its master (useMaster=true), and nothing above depends on it. On tvOS displaySupportsHDR is inert for that decision — builtInPanelEngagesOnDemand is false, HLSVideoEngine.swift:1997-2003 — so the withheld master follows panelIsHDR=false; what the second read does change on tvOS is dvModeAvailable (AetherEngine+Loading.swift:744), false there on a box reading dv=true on 102 of 103 lines that day.

5. AE#459's HLG floor, on one panel. 86 of the 88 readings at 7.1.3 are hlg=true; the other two are the all-false pair. 14:08:35.023 through 15:51:23.743. The five 6.81.0 control slices, same panel, straddled in time by those, read hlg=false 6 of 6, 14:44:23.296 to 14:49:02.262. observedPerModeTable (PlayerState.swift:291-299, byte-identical at 7.1.0 and 7.1.3) against 6.81.0's AetherEngine.swift:1327-1332. Nothing we ran turns on it, and your own doc block says why: PlayerState.swift:287-290 records that supportsHLG is consulted only for a DV source with an HLG base layer — Profile 8.4 — and that a plain HLG title was never clamped by any of it. Recorded as a reading, not a report.

6. The E-6 gate and 6.82.0's attempt at 7.1.3. panelIsInHDRMode not asserted … 59 times across the 7.1.3 slices (plus 6 in the 6.81.0 controls — it is our gate, not the engine's, so it reads the same at both pins); the only three assertions are our own assert / matcher rig legs. The unproven-panel attempt does fire on ordinary SDR VOD here — 09-17 14:33:39.956 [DisplayCriteria] panel unproven but HDR-eligible: serving the master and letting AVPlayer answer (refusal costs one in-place media fallback) (DEV-E7-sdrvod-attempt.log:52), 54 lines, none of them in the 6.81.0 control slices. The route is unchanged on all 54, by three paths: 51 reach routing and every one of them is videoRange=sdr, 49 of those already forced to the master by the audio rendition and 2 by videoCodecNeedsMasterSignaling (HEVC, HLSVideoEngine.swift:1964; DEV-E7-axis-seek-4200.log:55→:89, DEV-E7-axis-cues-pgs.log:68→:105, both audioLang=none); the other 3 never reach the HLS server at all and take the software route (DEV-E7-vod-hevc.log:66 with :84, DEV-E7-escape-native.log:222 with :237, DEV-E7-escape-real2.log:212 with :224). HLSVideoEngine.swift:2064-2065 carries all three terms. It is absent on live (DEV-E7-live-attempt-control.log, 0 hits; panelIsHDR=false … useMaster=false on media.m3u8 at :180). Neither refusal line (AetherEngine.swift:2326, :2342) appears in the device corpus — both do appear on the simulator, in our own assert / matcher rig legs: 12:53:46.491 panel refused an HDR master (code=-11868); this process routes HDR sources media-direct until it restarts → .492 AVPlayer rejected the master (code=-11868); falling back to media playlist … at 0.00s (SIM-E7-hdr-assert-matcher.log:170/:171). The eleven -11868 lines in the 7.1.3 slices, plus the one in the 6.81.0 control (DEV-E7-ctrl-vod-hdr10-dts.log:285), are all failedToPlayToEndTime 'Cannot open' at leg teardown, e.g. DEV-E7-vod-hdr10plus-eac3.log:260, with t+70.11s on :262, 466 ms before app → background (:263).

The leg still owes you the applicationState read on the same run-loop turn as the capability read. We will report either way.

[superuser404notfound]

Your §4 is a defect, and it was mine, not the platform's. Shipped in 7.5.0 (36d4d2b7).

The two reads are one read now. You anchored it exactly: AetherEngine.swift:3669 composes the table, AetherEngine+Loading.swift:739 re-read the property for the session it builds, and the comment over that second read said it was the first one's table. It was not, and the comment over the FIRST read is worse, because it states the guarantee outright: "Composed once, so the format clamp below and the served DV route cannot disagree about the same display." Two reads of a property that answers at call time are not one table, and your Episode B is what that costs: observed: … dv=true at 08:53:26.539, dvModeAvailable=false displaySupportsHDR=false … useMaster=false at .742. The table now travels as a loadNative parameter, so the compiler asks every caller which table it means, and a second read beside the session is a red test rather than a comment that lies again.

The rebuild routes on the load's table. Your 7.1.3 recurrence is the case I said the fix would go into, and it arrived with more than I asked for: one process, both directions, revoked at +0.696 s and reading hdr=true hdr10=true hlg=true dv=true again 133 ms after app → active (backgrounded 37s). That is the same shape AE#541 already settled for the panel readout, one level down, so it follows the same rule: an in-place rebuild is not a fresh look at the display, and it composes from the table its load composed. When the carried table and a read taken now differ, the rebuild says so:

[DisplayCapabilities] AE#535 rebuild routes on the load's table: hdr=true hdr10=true hlg=true dv=true (reading now: hdr=false hdr10=false hlg=false dv=false)

That second read exists for that line and never for the route. Your two audio-sync reloads at 14:54:35.793 and 14:54:37.910 are exactly where it should appear.

What this does not reach, stated plainly so the next leg is not spent on it: a process whose FIRST read falls in that window. Episode A's fresh process has nothing behind it to carry, and no table to fall back on. The real-world analogue you named, a Top Shelf deep link into a cold launch, is that case and not this one.

Two things in your data changed my reading of it.

matching=off and the all-false table are now measured moving together in one process and coming back together, which is as close to settling candidate (a) as a single box gets. An HDMI re-handshake cannot restore a Settings preference 133 ms after a foreground transition and leave it alone for the 34.8 s before.

And the window is narrower than "before the process is active". All 48 of your reads taken 0.66 to 0.87 s BEFORE their own app → active (fresh process) read hdr=true, with no exceptions. So a read that merely precedes activation is not revoked. The only revoked reads in 104 readouts sit inside a process that had backgrounded. That distinction matters for the leg: the control worth running is not "before active" but "launched without ever being frontmost", which is what a deep-link tune after a backgrounded teardown produces and what an already-frontmost launch does not. If applicationState reads .background on the same turn as an all-false table and .inactive on the same turn as a true one, that is the whole answer and the fix has a place to sit.

On your §5, the HLG reading: observedPerModeTable floors HLG on eligibility since 6.82.0, so a panel that read hlg=false at 6.81.0 and hlg=true at 7.1.3 with eligibility true is the floor working, not the panel changing its mind. Nothing routes on it for a non-DV source, as the doc block says, so I read your six control lines the same way you filed them: a reading.

On §6, the unproven-panel attempt firing on SDR VOD: the route being unchanged on all 54 is the intended shape rather than a lucky one. The attempt only ever moves panelIsHDR, and an SDR source resolves videoRange=sdr either way. It is noise in the log on those legs and I would rather have it than gate the line on a term that would hide the case it exists for.

#535 stays open, on your queued leg. Nothing in this release touches Match Dynamic Range being off, which is still what the issue itself is about.