cc4e5e04a7
Four consecutive runs failed to reach the interactive title, across two locales, two launch paths and two display-gamma settings. I attributed it in turn to a stale oracle, to the locale, and to the attract loop. It was none of those. one `screenshot` call, emulator running: 10.8 s one `screenshot` call, emulator killed: 0.117 s 92x, measured at a 1-minute load average of 1.80 -- so it is contention with the emulator through the X server, not background load. skip_intro.sh takes two grabs per iteration plus a numpy import, giving a median sampling interval of 41 s in the last run (38/82/41/20/30/30/35/ 47/46/45/44/43/21/19). The title lasts "a few seconds" before the attract loop reclaims it -- wait_title.sh's own header says so. The harness was sampling slower than the event it was waiting for. That also explains why runs at 16:43-18:05 the same day succeeded. Withdrawn as CAUSES, though the observations stand: "the JP run never reaches the interactive title", "neither locale reaches it without a pad press", and "the game sat in the attract loop for 604 s". The English control did control for locale -- it just shared the same defect. Also recorded: I set kernel_display_gamma_type = 0 for the gamma control run, which brightens the frame (mid-attract mean 122.8 vs 52.5/82.8 at type 2) -- and skip_intro classifies movie-vs-static on an ABSOLUTE rmse threshold, so the gamma change biased the very classifier the run depended on. Changing a display setting and a capture behaviour in one run confounds both. Config restored to type 2. The fix is not applied: make the probe cheap enough to outpace the title window (small region, no convert round trip, one long-lived process). Every remaining emulator-side question is waiting on that.
2.9 KiB
🔴 Why the boot harness stopped reaching the title — screenshot costs 10.8 s
Status: ✅ diagnosed, with a control. Four consecutive runs on 2026-08-28/29 failed to reach the interactive title, across two locales, two launch paths and two display-gamma settings. The cause is none of those.
The measurement
| condition | one screenshot call |
|---|---|
| while Xenia Canary is running | 10.8 s |
| immediately after killing it | 0.117 s |
92×. The 1-minute load average at the slow measurement was 1.80, so this is contention with the emulator (both go through the same X server), not general system load.
Why that breaks the harness
skip_intro.sh takes two grabs 0.6 s apart per iteration, plus an
is_title.py numpy load. Its actual sample timestamps in the last run:
57, 95, 177, 218, 238, 298, 333, 380, 426, 471, 515 → intervals
38, 82, 41, 20, 30, 30, 35, 47, 46, 45, 44, 43, 21, 19 median 41 s
A 41-second sampling interval against a title screen that the corpus already
documents as lasting "a few seconds" before auto-returning to the attract loop
(wait_title.sh's own header). The harness is not seeing a stuck game; it is
blinking slower than the thing it is looking for.
That is also why runs at 16:43–18:05 the same day succeeded and later ones did not — nothing about the game changed.
🔴 What this retracts
Three earlier conclusions were built on these runs and are withdrawn as causes, though the observations stand:
- "the Japanese-locale run never reaches the interactive title" — it may well have appeared, unsampled.
- "neither locale reaches the interactive title without a pad press" — the English control shared the same defect, so it controlled for locale but not for the sampling rate.
- "the game sat in the attract loop for 604 s" — what was observed is that every one of ~15 samples landed on movie content, which at a 41 s interval is a much weaker statement than it reads as.
⚠️ A confound I introduced
Setting kernel_display_gamma_type = 0 makes the frame substantially brighter
(a mid-attract frame measured mean 122.8 against 52.5 and 82.8 on
comparable phases at type 2). skip_intro.sh classifies movie-vs-static on an
absolute rmse threshold of 1500 between two grabs, so a brighter output
inflates that difference and biases every frame toward "movie". The capture
harness's tuning is coupled to the display settings — changing gamma and
capture behaviour in one run confounds both.
The fix, not applied here
Make the probe cheap enough to sample faster than the title window: grab a small
region rather than the full surface, drop the ImageMagick convert round trip,
or keep the glyph test in one long-lived process instead of re-importing numpy
per sample. None of that is done — this page is the diagnosis, and it is what
every remaining emulator-side question is waiting on.