Commit Graph
3 Commits
Author SHA1 Message Date
ChuckBuildsandClaude Opus 5 36c420c872 fix(vegas): use a monotonic clock for the frame-rate timers
Self-review catch. The heartbeat added in this PR compared wall-clock
timestamps, which is the defect CodeRabbit flagged on the metrics throttle and
which I had already fixed there: these devices have no RTC, so the clock jumps
by however wrong boot time was when NTP first syncs. A backward jump would
suppress the heartbeat, a forward one fire it early.

The same value also divides the frame count to produce the frame rate, so a
jump corrupted the reported fps as well -- a pre-existing problem this makes
worth fixing rather than working around.

last_fps_log_time was seeded from start_time, which is wall clock and is used
further down to report the iteration duration. Switching only the reads would
have made every delta hugely negative and silenced frame-rate reporting
completely, so the seed moves to time.monotonic() and start_time is left alone
for the duration reporting it exists for.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01STMbQE4YctTacQXfbYqKuW
2026-08-21 10:27:48 -04:00
ChuckBuildsandClaude Opus 5 a4290e8a28 perf(vegas): report the frame rate when it is worth reporting
Two Vegas telemetry lines were 37% of a running rig's entire log volume:
"Vegas FPS" every five seconds and "Scroll progress" on its own five-second
timer, 712 lines in half an hour, every one a journal write to an SD card.

The FPS line is the interesting one, because almost none of it was news.
Measured over two hours on that rig: 1410 samples, 98.5% of them within 10%
of target. What the other 1.5% contained was a reading of 8.6fps against a
target of 60 -- a real stall, sitting invisible inside 1389 lines that read
"59.6".

So it now reports at INFO when the frame rate falls short of target, when it
recovers from a shortfall, and on a five-minute heartbeat so a healthy
marquee still shows a pulse. Everything else drops to debug.

Replaying the same two hours of real samples through the committed logic:
1410 -> 53 INFO lines, a 96% reduction, and all 21 degraded samples are
retained, worst reading included. The signal survives; the wall of "fine"
does not.

Scroll progress is demoted outright. It reports how far along a marquee is,
which is what you turn debug on to watch, not something an operator needs in
the journal on a device that scrolls all day.

543 vegas and scroll tests pass.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01STMbQE4YctTacQXfbYqKuW
2026-08-20 20:26:34 -04:00
ChuckBuildsandClaude Opus 5 183e23edb3 docs(changelog): record the compatibility gate in 3.2.0
The 3.2.0 section described the unified sports library but none of the
install-path work that landed in #428 and #431 -- which matters more than a
normal changelog omission, because the sunset rule keys on this section to
tell plugin authors what a given floor buys them.

The headline addition: 3.2.0 is the first release that *enforces*
ledmatrix_min_version. Before it the floor was advisory, so a plugin could
declare one and still be delivered to a core that could not run it. That is
the property B6 waits on, and it is now stated where a plugin author will
look for it -- along with the caveat that a core reporting below 2.0.0 is
treated as unknown rather than old and is never blocked.

Also records compatibility.py (and that it does not yet read
compatible_versions), check_release_version.py and its workflow, the
install-preservation fix, the reentrant-lock deadlock fix, and the
web_interface version re-export.

No version bump: 3.2.0 is unreleased, so this describes the release being
cut rather than a new one.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Udr6MfaFLUPhX5Fgo67Jf5
2026-08-03 16:54:53 -04:00