fix(baseball-scoreboard): show the full slate in Vegas mode, not one game - #229
fix(baseball-scoreboard): show the full slate in Vegas mode, not one game#229ChuckBuilds wants to merge 1 commit into
Conversation
…game get_vegas_content() returned get_all_vegas_content_items(), the union of every scroll display's cached items. Those displays are populated by the standalone rotation as it renders each mode, so Vegas inherited whichever mode had rendered last. With one live game in progress that reduced the entire ticker entry to a single card; it also meant a game held by two displays could appear twice. The combined live/recent/upcoming set was only built when the union happened to come back empty, which is true just after a restart — so the plugin looked correct on boot and silently degraded. Vegas now reads a dedicated 'mixed' scroll display that the standalone modes cannot clobber, added as ScrollDisplayManager.get_vegas_content_items_for(). Measured on a 512x64 panel: 1 game before, 15 games after (5 live, 5 recent, 1 upcoming at the time of the first check). Two further fixes fall out of this: - Building the slate called update(), putting network I/O on the Vegas render path and freezing the ticker for seconds. The slate is now rendered from whatever data the plugin already holds, and is rebuilt only when the games actually change — fingerprinted on the game set plus score, inning, count and final flag. Refreshing data stays the update cycle's job. - Rendering went through prepare_and_display(), which also repoints the manager's active scroll display. Building the Vegas slate would therefore hijack an in-progress standalone scroll, so the next frame rendered the Vegas slate instead of the mode the rotation was showing. Added prepare_content(), which renders without switching the active display. Also corrects the game_card_width guidance, which advised lowering the value on multi-panel chains. That is backwards: on a wide panel cards need to be wider to stay readable. Now suggests roughly display width / 3. Verified with the safety harness at all sizes (all PASS; the extent-0% fill warnings on the larger panels are pre-existing and reproduce on origin/main), plus live on hardware with real MLB data. Co-Authored-By: Claude <[email protected]> Claude-Session: https://claude.ai/code/session_01KEZK1P1Q1fu5pcuVrkrCFZ
|
Warning Review limit reached
Next review available in: 31 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (6)
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. Comment |
Up to standards ✅🟢 Issues
|
| Metric | Results |
|---|---|
| Complexity | 0 |
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
2 participants
Problem
In Vegas scroll mode the baseball plugin showed a single game. On a 512px panel that was one 152px card in a ticker that had room for several.
The cause is subtle.
get_vegas_content()returnedget_all_vegas_content_items()— the union of every scroll display's cached items. Those displays are populated by the standalone rotation as it renders each mode, so Vegas inherited whichever mode had rendered last. With one live game in progress, that reduced the whole ticker entry to that one card. A game held by two displays could also appear twice.Worse, the combined live/recent/upcoming set was only built when the union came back empty — which is true just after a restart. So the plugin looked correct on boot and silently degraded once the rotation had run, which is exactly the kind of bug that survives a quick check.
Fix
Vegas now reads a dedicated
'mixed'scroll display that the standalone modes cannot clobber, via a newScrollDisplayManager.get_vegas_content_items_for(game_type).get_all_vegas_content_items()is kept for compatibility.Measured on a 512×64 panel with live MLB data: 1 game before, 15 after (5 live, 5 recent, 1 upcoming at the time of the first check).
Two further fixes fall out of this
Network I/O was on the render path. Building the slate called
update(), which froze the Vegas ticker for seconds while it fetched. The slate is now rendered from whatever data the plugin already holds, and is rebuilt only when the games actually change — fingerprinted on the game set plus score, inning, count and final flag. Refreshing data stays the update cycle's job. Every field is read with.get()since game dicts vary by league and completeness.Building the slate hijacked the standalone scroll. Rendering went through
prepare_and_display(), which also repoints the manager's active scroll display. So building the Vegas slate would leave_current_game_typepointing at'mixed', and the next standalone frame rendered the Vegas slate instead of the mode the rotation was showing. Addedprepare_content(), which renders into a display without making it active.Also
Corrects the
game_card_widthdescription, which advised lowering the value on multi-panel chains. That is backwards — on a wide panel cards need to be wider to stay readable. It now suggests roughly display width / 3.Testing
extent 0%x0%fill warnings on the larger panels are pre-existing — I verified they reproduce identically onorigin/mainwith my changes stashed.scripts/check_module_collisions.py: OK across 41 plugins.Note for reviewers
This overlaps #228 (
fix(baseball-scoreboard): stop rendering game start times in UTC), which bumps to 1.20.0 and also touchesmanager.py,config_schema.jsonandCHANGELOG.md. I versioned this 1.20.1 so it sequences after #228, but whichever merges second will need a rebase for those three files. Happy to rebase this one once #228 lands.Companion core-side work is ChuckBuilds/LEDMatrix#423, which reworks Vegas mode dead space and pacing; this fix is what makes baseball fill the space that PR reclaims.
🤖 Generated with Claude Code
https://claude.ai/code/session_01KEZK1P1Q1fu5pcuVrkrCFZ