Last iteration I said launch_mission died because skip_intro only tests for the title on a static frame, gated at rmse <= 1500, and that run logged 1503 and 1549 just above the cut. I also said the fix was NOT to nudge 1500 but to measure both signals through a boot first. Measured, and the diagnosis does not survive. boot_trace.sh logs the two signals skip_intro decides on -- frame-to-frame RMSE and the is_title.py green-glyph count -- through a clean boot with no presses at all. One run, 29 samples over 484 s: 8 samples had rmse <= 1500, so the gate OPENED eight times 0 samples had glyph > 0, so the title was never seen At t=145 s the RMSE was 1205, comfortably inside the threshold, and the glyph test was called and answered zero. A frame can be perfectly static without being the title -- the intro movie has long quiet stretches, three reading RMSE exactly 0. So 1503/1549 were almost certainly movie frames too, and raising the constant would have admitted two more of them. What is left is narrower and honest: the interactive title never appeared, rather than appearing and being missed by a threshold. The limitation is recorded rather than buried: the tracer intended 1 s sampling and achieved 16.9 s, because each iteration forks two screenshots, ImageMagick compare and a fresh Python. So this does NOT prove the title never appeared -- only that it was absent from 29 samples. A window shorter than ~17 s falls between them. The recorded next step is to make the tracer sample at the rate it claims before concluding anything stronger. Artifact: docs/re/captures/boot-signal-trace.tsv. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE
86 lines
4.0 KiB
Markdown
86 lines
4.0 KiB
Markdown
# The boot-nav title gate — my own diagnosis, measured and withdrawn
|
|
|
|
Status: ❌ **the previous diagnosis is WITHDRAWN.** 🟡 the real failure is
|
|
narrowed but not settled. ❔ the measurement has a limitation that matters, and
|
|
it is stated below rather than buried.
|
|
|
|
## What I claimed last iteration
|
|
|
|
`launch_mission.sh` failed to reach the mission: 381 s of `skip_intro.sh`
|
|
printing "movie … waiting it out", 18 times, and the ready room never arrived.
|
|
`skip_intro.sh` only tests for the interactive title when the frame is **static**,
|
|
gated at `rmse <= 1500`, and that run logged **1503 at 104 s** and **1549 at
|
|
139 s** — just above the cut. I wrote that the gate had therefore blocked the
|
|
title test and eaten the run.
|
|
|
|
I also wrote, correctly, that the fix was *not* to nudge 1500, and that the first
|
|
step was to measure both signals through a whole boot. That is what this is.
|
|
|
|
## The measurement
|
|
|
|
`tools/re-capture/boot_trace.sh` logs, without pressing anything, the two signals
|
|
`skip_intro.sh` decides on: the frame-to-frame RMSE (two grabs 0.6 s apart) and
|
|
the green-glyph pixel count from `is_title.py` — independent tests for "is this
|
|
static" and "is this the interactive title".
|
|
|
|
One clean boot, no input at any point:
|
|
[`captures/boot-signal-trace.tsv`](captures/boot-signal-trace.tsv).
|
|
|
|
```
|
|
29 samples spanning 484 s
|
|
8 samples with rmse <= 1500 (the gate OPENED eight times)
|
|
0 samples with glyph > 0 (the title was never seen)
|
|
```
|
|
|
|
The eight low-RMSE samples: `t=12, 29, 62` (rmse 0), `t=99` (1486), `t=115`
|
|
(1350), `t=145` (**1205**), `t=316` (0), `t=484` (0).
|
|
|
|
## ❌ Why the old diagnosis is wrong
|
|
|
|
The gate is not what stopped it. It **opened eight times**, and at `t=145` the
|
|
RMSE was **1205** — comfortably inside the threshold — so `is_title.py` was
|
|
called and answered **0 glyph pixels**. A frame can be perfectly static and still
|
|
not be the title; the intro movie has long quiet stretches, and three samples
|
|
read an RMSE of exactly 0.
|
|
|
|
So `1503`/`1549` in the failing run were almost certainly *also* not the title,
|
|
and raising the threshold to admit them would have admitted two more movie
|
|
frames, not the title. The instinct to leave the constant alone was right; the
|
|
reason I gave for it was wrong.
|
|
|
|
## 🟡 What the failure actually is
|
|
|
|
Narrowed, not settled: **the interactive title never appeared at all** in 484 s
|
|
of a no-press boot — not "appeared and was missed by the gate". The glyph count
|
|
was 0 in all 29 samples, including the last one at 484 s where the frame was
|
|
completely static (rmse 0).
|
|
|
|
A static frame with no glyph at 484 s is consistent with the attract loop having
|
|
returned to a title that, per `menu_draw_capture.sh`, "accepts nothing at all" —
|
|
but this run never pressed anything, so nothing can have broken it. That points
|
|
at the boot itself, not at the navigation.
|
|
|
|
## ❔ The limitation, stated plainly
|
|
|
|
**The intended sampling rate was 1 s; the achieved rate was 16.9 s.** Each
|
|
iteration takes two screenshots, runs ImageMagick `compare` and starts a Python
|
|
interpreter, and that costs ~15 s per loop in this container. So 29 samples cover
|
|
484 s with big gaps between them.
|
|
|
|
That means this run does **not** prove the title never appeared — only that it
|
|
was absent from every one of 29 samples. A title window shorter than ~17 s could
|
|
fall between two samples. Before concluding anything stronger, the tracer needs
|
|
to get cheap enough to sample at the rate it claims: keep one Python process
|
|
alive and compute the RMSE and the glyph count in it, instead of forking
|
|
`compare` and a fresh interpreter every second.
|
|
|
|
## What this does not settle
|
|
|
|
* Whether the title ever appears on this boot path at all.
|
|
* Whether the earlier "readyroom at 9 s, IN FLIGHT at 37 s" run (recorded
|
|
2026-08-25 in `BACKLOG.md`) used a warm shader cache that this run lacked —
|
|
this one was started after `rm -f /dev/shm/xenia_*`, which the fast run may not
|
|
have been.
|
|
* The live test this was all for — whether the trigger container and the
|
|
coroutine list both collapse at a phase terminator — remains unrun.
|