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.
67 lines
2.9 KiB
Markdown
67 lines
2.9 KiB
Markdown
# 🔴 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.
|