forked from unom/punktfunk
enricobuehler
8216f1d92d
The host's recovery-cadence detector warns that "client keyframe recoveries are METRONOMIC — a periodic host/display disturbance (display-topology churn, display-poller software, virtual-display timing) is the likely cause, not random network loss". In a 2026-08-13 field log it fired at period_s=2.0 and sent the investigation at three innocent host subsystems. 2.0 s is `punktfunk_core::client::FLUSH_COOLDOWN`. The client's receive-backlog guard sheds a standing queue with a flush plus a keyframe request and is rate-limited to one per cooldown, so a client that cannot sustain the stream asks for a keyframe at EXACTLY that spacing for as long as it stays behind — the constant's own doc says it "degrades into a periodic skip + a logged warning", which is the behaviour the detector then read as physical. Perfect periodicity argues FOR a fixed software cooldown, not against it. In the field case the host was blameless and the chain ran the other way: the client refused the negotiated codec on its Vulkan rung, demoted to a slower decode path, could not hold 4K120 there, and built the standing queue. Three layers between the symptom the host reported and the cause. So the detector now routes: a period on the client's cooldown names the client and says where to look in ITS log (`receive backlog stopped draining`, and a demoted decode rung); anything else keeps the display-disturbance wording it had. The comparison reads FLUSH_COOLDOWN itself — now `pub` for exactly this, documented as such — rather than a copy of the number, so the two cannot drift. ±10 % absorbs scheduling jitter and the request's trip without being wide enough to swallow the disturbance cadences the other branch exists to report. Verified: 18/18 native::stream::tests on linux/amd64 (container), including the new case, which derives its inputs from FLUSH_COOLDOWN so it survives a retune; clippy --all-targets -D warnings clean; cargo check clean on the Windows CI runner.