diff --git a/docs/re/f6-unit9-wrap-period-not-obtained.md b/docs/re/f6-unit9-wrap-period-not-obtained.md new file mode 100644 index 00000000..52f44a02 --- /dev/null +++ b/docs/re/f6-unit9-wrap-period-not-obtained.md @@ -0,0 +1,49 @@ +# F6 unit 9 — the wrap-to-wrap period was NOT obtained: two harness failures, no new data + +**Status: ❔ not answered — the run did not produce data.** 2026-09-02. + +**Question:** what is the leaf's loop period measured wrap-to-wrap? +**Look at:** frames between consecutive wraps. Pass = ≥2 wraps; fail = fewer. +**Not covered:** everything else in F6. + +--- + +## What happened + +Unit 8's rate (**0.514 units/frame**, leaf ≈ ½ × title) rests on **one wrap** — +a start-to-wrap span, not a period. Hardening it needs a longer title capture with +two or more wraps. Two attempts, both failed on the harness rather than the game: + +1. **First launch never started.** The `pgrep … && echo || { … }` guard I wrote + took the wrong branch — the output directory was never created and no process + ran, while a stale emulator from the previous iteration was still up. It looked + like a running capture for several minutes. +2. **Second launch started, armed, pressed Ⓐ — and wrote no draw log.** + `canary.stdout` stayed at **0 bytes** and no `xenia_re_ui_draws_01.log` appeared, + despite the script printing `armed at 8s`. The likely cause is a race with the + orphaned emulator from failure 1, but I did not confirm it. + +## What stands, unchanged + +**Unit 8's two numbers are not affected** — they came from the intact `f6` capture, +which is still on disk. The offset (+40 title units) has two independent supports; +the rate (0.514×) still rests on a single wrap and **the port should not ship on +it**, which is what I told them before this attempt. + +## 🔴 The lesson, since it is the second harness failure in two iterations + +**`armed at 8s` printed while nothing was being logged.** The script's arming step +reports success on sending the keystroke, not on the logger responding — exactly +the silent-failure shape that cost the first F1 probe a whole run, and which I +"fixed" then by making the *window lookup* fatal. That fix was too narrow: the +window was found, the key was sent, and the log still never appeared. + +**The check that would have caught both:** after arming, wait for +`xenia_re_ui_draws_*.log` to exist and be non-empty, and abort loudly if it does +not. A probe that cannot confirm its own instrument is recording is a probe whose +negatives mean nothing — and I have now written that same class of bug twice. + +## Next + +Add that assertion to `title_sweep_probe.sh`, then re-run. The measurement itself +is unchanged and cheap; only the harness needs the guard. diff --git a/tools/re-capture/title_sweep_probe.sh b/tools/re-capture/title_sweep_probe.sh index 7a26e3f4..35a3c8d2 100755 --- a/tools/re-capture/title_sweep_probe.sh +++ b/tools/re-capture/title_sweep_probe.sh @@ -17,7 +17,7 @@ OUT="${1:-/sylph-home/re/f6}"; mkdir -p "$OUT"; rm -f "$OUT"/xenia_re_ui_draws_* pad(){ printf '%s' "$1" > "$XENIA_PAD_FILE.tmp"; mv "$XENIA_PAD_FILE.tmp" "$XENIA_PAD_FILE"; } pad "" ( cd "$OUT" && nohup run-canary --log_ui_draws=true \ - --ui_draw_capture_frames=2500 --ui_draw_capture_max=600000 \ + --ui_draw_capture_frames=6000 --ui_draw_capture_max=1500000 \ >"$OUT/canary.stdout" 2>"$OUT/canary.stderr" & ) sleep 8 win="$(xdotool search --name "Xenia-canary" | tail -1)" @@ -25,6 +25,6 @@ win="$(xdotool search --name "Xenia-canary" | tail -1)" xdotool windowactivate "$win" 2>/dev/null; xdotool key --window "$win" F10; xdotool key F10 echo "armed at ${SECONDS}s" sleep 12; pad "press=A"; sleep 0.4; pad ""; echo "A (skip video) at ${SECONDS}s" -sleep 45 # let the title build in and settle, no further input +sleep 150 # let the title build in and settle, no further input pkill -x xenia_canary echo "done at ${SECONDS}s"; ls -la "$OUT"/*.log 2>/dev/null