fix(youtube-stats): stop retrying a failing API once per frame

[ChuckBuilds]

Found by sweeping for network calls reachable from display() — the render thread — after the thread-safety work on #322. Most hits were guarded or false positives; this one is real.

The bug

def update(self):
    self.channel_stats = self._get_channel_stats()   # None on ANY failure

def display(self, force_clear=False):
    if not self.channel_stats:
        self.update()                                 # ...so: every frame

update() assigns the result unconditionally, so a missing key, an HTTP error, an exhausted quota or a dropped network all leave channel_stats empty — and display() gates on that emptiness. The next frame tries again.

That is one requests.get(..., timeout=10) per rendered frame, on the render thread.

Two consequences, both self-sustaining:

• The panel stalls. Each call can block for the full 10s timeout, on the thread that draws frames.
• The quota burns down. The YouTube Data API allows 10,000 units/day by default and channels.list costs 1. A broken key exhausts it in minutes — and quota exhaustion is itself an error, which keeps the result empty, which keeps the loop fed.

The cache inside _get_channel_stats doesn't help: a failed fetch caches nothing, so there's never an entry to serve.

Note the no-key path also logger.error(...)s on every frame before returning.

The fix

• display() gates on whether a fetch has been attempted (_has_fetched), not on whether it produced data. This is the pattern incoming-packages and jellyfin-now-playing already use for their first-paint call, and it's why neither has this bug.
• update() is throttled to update_interval. The core already calls it at roughly that cadence so this is a no-op for the core; it exists to bound the display-driven path so a failing API costs one request per interval rather than one per frame.
• time.monotonic(), not time.time() — these Pis have no RTC, so a wall-clock jump at NTP sync must not make the next attempt look due (or centuries away).

Verification

New test_no_per_frame_api_storm.py (this plugin had no tests at all):

• 200 frames against a permanently failing API cost one call
• the retry lands once the interval has elapsed
• a working API still populates stats, at exactly one call
• display() no longer gates on the result; update() uses monotonic

6 of its 9 checks fail against the pre-fix manager, so it pins the behaviour rather than describing it.

Not verified on hardware — both rigs have been unreachable all session.

plugins.json deliberately omitted; update-registry.yml regenerates it on merge and carrying it conflicts with the other open PRs.

🤖 Generated with Claude Code

https://claude.ai/code/session_01STMbQE4YctTacQXfbYqKuW

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: c6213e27-59f7-4732-ac00-bfc488f13654

---

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.}

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 5 complexity

Metric	Results
Complexity	5

View in Codacy

_{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.}

[ChuckBuilds]

@coderabbitai review

[coderabbitai]

⚠️ Action not completed

Review rate limited.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.