fix(vegas): refresh scroll buffer on live score updates

[ChuckBuilds]

Summary

• should_recompose() only checked for cycle completion or staging buffer content, but live plugin updates are queued in _pending_updates — not the staging buffer
• The scroll display kept showing the old pre-rendered image until the full cycle ended, even though fresh scores were already fetched (visible in logs as "Vegas update tick: N plugin(s) updated")
• Added has_pending_updates() to StreamManager and wired it into should_recompose() so hot_swap_content() triggers immediately when plugins report new data

Test plan

• Deploy to test device and enable Vegas scroll mode with a live game plugin
• Watch logs for "Vegas update tick: N plugin(s) updated"
• Confirm display visually refreshes shortly after log message rather than waiting for full scroll cycle
• Confirm no visual glitches during mid-scroll hot-swap

Fixes #230

🤖 Generated with Claude Code

Summary by CodeRabbit

• Improvements

  • Periodic live-priority monitoring added so the display automatically switches to higher-priority live modes and shows them immediately.
  • Timing for display loops improved for more reliable scheduling.
  • Rendering pipeline now detects pending updates affecting visible segments, enabling quicker recomposition and visual refreshes.

• Performance

  • Throttling added to limit how often live-priority checks run, reducing unnecessary work.

[coderabbitai]

Warning

Rate limit exceeded

@ChuckBuilds has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 10 minutes and 26 seconds before requesting another review.

Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 10 minutes and 26 seconds.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 706325d3-f1d5-47bd-b3f8-130d691089c9

📥 Commits

Reviewing files that changed from the base of the PR and between 738ba0a and 5cd9023.

📒 Files selected for processing (3)

• src/display_controller.py
• src/vegas_mode/render_pipeline.py
• src/vegas_mode/stream_manager.py

📝 Walkthrough

Walkthrough

Added throttled, periodic live-priority preemption checks into the display controller (using monotonic timing) to allow immediate mode switches from long-running display loops; expanded Vegas render recomposition triggers to consider pending updates for currently visible segments via new StreamManager query methods.

Changes

Cohort / File(s)	Summary
Display controller loop changes src/display_controller.py	Introduced self._next_live_priority_check and switched timing to time.monotonic(). Both high-FPS and normal inner loops now perform a periodic (~30s when not self.on_demand_active) _check_live_priority() call that, if a different live_mode is returned, updates current_display_mode, sets force_change = True, best-effort updates current_mode_index, breaks the inner loop, and the outer loop continues to allow immediate live-mode display.
Render recomposition trigger src/vegas_mode/render_pipeline.py	should_recompose() now also returns True when stream_manager.has_pending_updates_for_visible_segments() reports pending updates affecting currently visible segments, adding visible-segment update detection to recomposition criteria.
StreamManager query accessors src/vegas_mode/stream_manager.py	Added thread-safe methods has_pending_updates() and has_pending_updates_for_visible_segments() that check _pending_updates (under _buffer_lock) and whether any pending updates target plugin IDs present in the active buffer's visible segments, respectively.

Estimated Code Review Effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

• fix: live priority now interrupts long display durations (#196) #298: Modifies the same display controller live-priority polling and in-loop preemption behavior.
• fix(vegas): keep plugin data and visuals fresh during Vegas scroll mode #291: Related changes in the Vegas update/StreamManager flow that interact with the new pending-update query methods.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Linked Issues check	❓ Inconclusive	The PR addresses issue #230's LED board initialization reliability by implementing hot-swap on live updates and using monotonic clock timing to prevent NTP-induced issues, though the direct causation is not explicitly documented.	Clarify how hot-swap triggering on live updates and monotonic clock timing directly resolve the LED board initialization failures described in #230, or update the issue link if this addresses a different problem.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately summarizes the main change: adding live score update detection to trigger immediate buffer refresh in Vegas mode.
Out of Scope Changes check	✅ Passed	All changes are directly scoped to implementing live-update detection and monotonic timing for Vegas mode refresh, with no unrelated modifications detected.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/vegas-live-score-refresh

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

src/display_controller.py (1)

82-82: Use one monotonic helper for this 30s live-priority gate.

These two blocks are enforcing elapsed-time throttling, not wall-clock timestamps. On Raspberry Pi, time.time() can step when the system clock syncs, which can delay or bunch the next probe; moving this behind one helper backed by time.monotonic() keeps both loops consistent. If you make that switch, seed the loop start_time from the same clock as well.

Also applies to: 1794-1811, 1876-1890

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/display_controller.py` at line 82, Replace wall-clock time.time() uses
for the 30s live-priority gate with a single monotonic clock: initialize
self._next_live_priority_check using time.monotonic(), and change every
comparison and seeding of start_time/start_time-like variables used by the
live-priority gating logic to use time.monotonic() as well (or add a small
helper monotonic_now() and call it everywhere). Update the code paths that
set/compare self._next_live_priority_check and any start_time variables (the
live-priority probe loops mentioned in the comment) so they are all based on the
same monotonic clock to avoid clock-stepping issues on Raspberry Pi.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/vegas_mode/render_pipeline.py`:
- Around line 268-270: The current hot-swap check in render_pipeline (the call
to self.stream_manager.has_pending_updates()) triggers recomposition for any
queued plugin update; change this to only trigger when a pending update affects
visible segments by adding a StreamManager method like
has_pending_updates_for_visible_segments that checks whether any plugin_id in
self._pending_updates intersects the set of plugin_ids present in
self._active_buffer (only consider segments with images), and then replace the
render_pipeline call to has_pending_updates() with
has_pending_updates_for_visible_segments() so hot_swap_content() runs only for
updates that can change the current scroll.

---

Nitpick comments:
In `@src/display_controller.py`:
- Line 82: Replace wall-clock time.time() uses for the 30s live-priority gate
with a single monotonic clock: initialize self._next_live_priority_check using
time.monotonic(), and change every comparison and seeding of
start_time/start_time-like variables used by the live-priority gating logic to
use time.monotonic() as well (or add a small helper monotonic_now() and call it
everywhere). Update the code paths that set/compare
self._next_live_priority_check and any start_time variables (the live-priority
probe loops mentioned in the comment) so they are all based on the same
monotonic clock to avoid clock-stepping issues on Raspberry Pi.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 819c8ffd-56fd-459e-8a5e-1ceb91a35ebf

📥 Commits

Reviewing files that changed from the base of the PR and between 5ddf8b1 and 211ff59.

📒 Files selected for processing (3)

• src/display_controller.py
• src/vegas_mode/render_pipeline.py
• src/vegas_mode/stream_manager.py