Ed reported the service pulling his volume to 20% repeatedly. Diagnosis from the
service logs: NOT a runaway timer - one service process ran untouched for 36 hours,
proving there's no periodic restart. The volume-to-20 punches came from GENUINE
service restarts (deploys, the one self-update, profile saves, handovers during
active use), each re-applying because the mode was "every service restart". Two real
faults found and fixed:
1. Re-apply burst guard. "Every service restart" (and boot-only as belt-and-braces)
now skips a re-apply within ReapplyCooldown (5 min) of the last successful apply,
persisted as startup-volume-last.txt. This kills the double-apply we saw in the
log at 08:20:48 then 08:21:02 (a self-update restart immediately followed by a
follow-on start, 14s apart, both punching the volume), and any rapid churn from
self-update / profile-save / deploy. ShouldApply gains lastApplied+now params;
future-dated stamp (clock moved back) can't wedge it.
2. Misleading log. ServiceSendHost.Suspend() hard-coded "interactive app present" on
EVERY suspend, including plain shutdown - which sent this very investigation
chasing phantom app-handovers. Suspend now takes a reason; the run-loop-ending
path says so, only a real app yield says "interactive app present".
readme: recommend "first start after boot" as the set-and-forget mode and explain
that "every restart" also fires on routine internal restarts (and is now burst-
guarded). Self-test extended: cooldown skip in both modes, 14s double-apply guard,
future-stamp safety. Gate 71/71 + 7 relay tests.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Feature (requested 2026-07-26): Additional service options gains 'Set the machine's
volume when the service starts' - a checkbox, a percent field (0-100, also unmutes),
and a WHEN list: 'Only the first start after each boot' (default) or 'Every time the
service starts'. For an unattended machine that boots muted or turned down, the
service makes it audible again with nobody at the keyboard; boot-only mode means a
mid-day manual service restart never blasts the volume while someone's using the box.
Mechanics: settings live machine-wide beside the service logging flag (the service
reads them fresh each start - no restart needed to change them); boot identity comes
from now-minus-uptime persisted in a marker file, so 'first start after boot'
survives same-boot service restarts and re-fires after a real reboot; the marker is
only written on a SUCCESSFUL apply, so a boot-time audio-stack race retries on the
next qualifying start. Applies via the same endpoint-volume helper the remote-control
commands use (master endpoint volume is device-global, so session 0 works). Outcome
logged to the always-on service events log.
The new round-trip test immediately caught SaveLoggingEnabled clobbering the volume
fields in the shared settings file - rewired both savers to load-modify-save. The
dialog audit picks up the new controls (mnemonics + names) automatically.
Gate 65/65.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
EdnunpandClaude Fable 5