Files
Sylpheed/tools/re-capture/wait_plate_pulse.py
sylph-decoder 969b816aad re: WITHDRAW the (A)-press finding -- three emulators were live at once
While chasing the draw-stream question I found THREE xenia instances running
simultaneously (started 15:39, 15:44, 16:12), which violates the "one emulator at
a time" hard rule and confounds the finding I recorded last iteration.

All three read the same /tmp/xenia_pad.txt and share display :98. A press written
to that file is delivered to EVERY instance, while `screenshot` grabs whichever
window is topmost -- not necessarily the one that acted on it. So "(A) was
delivered and the screen did not change" may simply be two different emulators,
and the keystroke-level confirmation proves only that SOME instance received it.
The navigation.md entry claiming the boot title's "2 of 2" is no longer 2 of 2 is
withdrawn as unsupported, pending a clean re-run.

The cause was mine. run-canary's lockfile is the IMPLEMENTATION of the one-at-a-
time rule; a kill -9 orphans it, and the obvious unblock -- rm -f the lock --
also disables the guard for every later launch. I did that more than once today.

METHOD gains two entries. A lockfile is the rule, not an obstacle to it: clear a
stale lock only after confirming zero live instances, and COUNT them rather than
trusting a kill landed, because a plain kill is asynchronous and a -9 on a stuck
process can take seconds. When a guard blocks you, the question is whether the
condition it guards against is present, not how to remove the guard.

And a third instance of pgrep -f matching the shell that runs it -- this time it
killed a cleanup command halfway through, leaving the emulators alive and the
lock in place. Already recorded for wait-loops; promoted to "reach for -C first".

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 16:20:24 +00:00

53 lines
1.7 KiB
Python
Executable File

#!/usr/bin/env python3
"""Block until the title's Ⓐ-plate says the screen has SETTLED, then exit 0.
The same gate `jp_title_capture.py` uses: the green plate glyph count inside a
band, HELD for 12 consecutive samples (~3 s at 4 fps). A single `screen_id.py`
classification is not enough -- it fires on the ATTRACT loop's title, which
accepts no input, and a probe that pressed Ⓐ there concluded nothing for 484 s.
Exit 0 when settled, 2 on timeout.
wait_plate_pulse.py [wait_s]
"""
import subprocess
import sys
import time
import numpy as np
W, H = 1280, 720
NEED, CEIL, HOLD = 500, 2500, 12
WAIT = float(sys.argv[1]) if len(sys.argv) > 1 else 900
def _open():
return subprocess.Popen(
["ffmpeg", "-loglevel", "error", "-f", "x11grab", "-draw_mouse", "0",
"-video_size", f"{W}x{H}", "-i", ":98", "-r", "4",
"-f", "rawvideo", "-pix_fmt", "rgb24", "-"],
stdout=subprocess.PIPE, bufsize=W * H * 3 * 2)
def glyph(a):
r, g, b = a[:, :, 0], a[:, :, 1], a[:, :, 2]
return int(((g > 130) & (g - r > 45) & (g - b > 45)).sum())
T0 = time.time()
p, n, seg, streak = _open(), W * H * 3, time.time(), 0
while time.time() - T0 < WAIT:
if time.time() - seg > 30:
p.kill(); p = _open(); seg = time.time()
buf = p.stdout.read(n)
if len(buf) < n:
p.kill(); p = _open(); seg = time.time(); continue
c = glyph(np.frombuffer(buf, np.uint8).reshape(H, W, 3).astype(int))
streak = streak + 1 if NEED <= c <= CEIL else 0
if streak >= HOLD:
print(f"[{time.time()-T0:7.1f}s] TITLE SETTLED (plate pulse, glyph {c})", flush=True)
p.kill(); raise SystemExit(0)
p.kill()
print("TIMEOUT — the title never settled", flush=True)
raise SystemExit(2)