A scheduled recording now makes sure the computer is awake for it

[accesswatch]

A listener scheduled a football pregame for 11:00 and Quill Radio announced the recording at 11:03. Nothing failed, nothing was logged, and he lost the first three minutes with no way to find out why.

RecordingScheduler polls every 20 seconds, so 20 seconds is the entire budget — minutes mean the machine slept. A schedule is a thread inside a running app, and a sleeping computer runs no threads. Keep-awake was scoped to (playing or recording), covering every moment except the quiet stretch before a scheduled recording — exactly when an idle computer decides to sleep.

Three defences, weakest to strongest

1. It says so. The scheduling window states the requirement in one line, before anything is set: Quill Radio must be running, and the tray counts.
2. It holds standby off as the moment approaches. schedule_wake.is_imminent, five minutes ahead, consulted by the sleep inhibitor alongside playback and recording — re-evaluated on the existing one-minute tick, because "a recording is now five minutes away" is not a playback state change and would never otherwise reach it.
3. It can wake the machine. Nothing inside a sleeping process can rouse it. recording_wake_task registers a one-shot per-user Task Scheduler entry with WakeToRun two minutes ahead, then starts Quill Radio if it is not running. From XML, because schtasks /Create has no switch for that flag; DisallowStartIfOnBatteries off so a laptop still records; re-registered on every schedule change and at launch, removed when nothing is scheduled.

Two RadioHistory flags, both default true and deliberately separate: inhibiting standby is local and permission-free, waking the machine changes how the computer behaves. Best effort throughout — a machine whose policy blocks schtasks keeps the other two defences and sees no error.

GATE-11 forced two extractions rather than a rebaseline: apps/radio_preferences.py (the whole Preferences dialog out of the at-ceiling app shell) and the new logic into its own module rather than the at-ceiling recording_schedule.py.

Second commit: a test was writing into a real user profile

test_radio_favorites_manual_order patches quill.core.paths.app_data_dir. main_frame_radio imported the name at module scope, so it holds its own binding the patch never touches — and _save_radio_favorites reads that one. The test wrote its fixture stations ("Zeta", "Alpha", "Mu" at example.com) into a real radio_favorites.json, replacing seven actual stations. The suite passed every time; backups show ~two weeks of this, found only because somebody looked at their favorites and asked what "Zeta" was.

The test now patches the binding that is read — and tests/conftest.py refuses the real profile outright, so any write beneath it raises and names the path. _DEV_BUILD + QUILL_DATA_DIR isolates a test that remembers to ask; this catches the test that thinks it did, which is the only kind that loses data quietly. Verified by probing a real-profile write (blocked, no file created) and by a full suite run.

Verification

• 11 new tests over the wake arithmetic against an injected clock, including the exact reported shape: imminent at 10:58, not at 10:50.
• Full CI-shaped suite (-n 4 --dist=loadfile) green; the two failures it surfaced are fixed here.
• ruff, format, mypy (809 files), GATE-11, banned patterns, error codes, docs parity all clean. Dialog/accessible-name/public-surface inventories regenerated: no drift.
• Both apps launch clean.

🤖 Generated with Claude Code