Sylpheed/docs/re/boot-nav-title-gate.md

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.

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.