fix: thumbnail resilience for large collections (#67) - #74
Conversation
- Startup prefetch: warm thumbnail cache in background on boot, auto-retry every 5 min until all thumbnails are cached - Fail-fast batch call: attempts=1 on get_thumbnail_list (~18s vs ~54s) - Shorter prefetch timeout: 5s instead of 10s to reduce lock contention during background fetches, giving user operations more frequent windows - Retry All button: frontend shows button when loading completes with errors, resets circuit breaker and kicks fresh server-side prefetch - POST /api/thumbnails/retry endpoint: resets circuit breaker and schedules background prefetch for specified content IDs - Race condition fix: set _thumb_prefetch_running before create_task at all spawn sites to prevent duplicate prefetch tasks
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8f24b59b6f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if consecutive_failures >= _PREFETCH_MAX_FAILURES: | ||
| remaining_ids = content_ids[i:] |
There was a problem hiding this comment.
Include failed IDs in startup prefetch retries
When the startup prefetch aborts after _PREFETCH_MAX_FAILURES consecutive failures, this retry list starts at the next unattempted ID, so the five IDs that just failed are omitted from every scheduled startup retry. If the TV is temporarily unreachable for those first attempts, the auto-retry loop can eventually cache later thumbnails while permanently leaving the initially failed thumbnails behind until a user explicitly retries them.
Useful? React with 👍 / 👎.
| except Exception as e: | ||
| log.warning("Startup prefetch: could not fetch artwork list: %s", e) | ||
| return |
There was a problem hiding this comment.
Retry startup prefetch after artwork-list failures
If the TV is unreachable during this initial _refresh_art_cache call, _startup_prefetch returns and nothing schedules another attempt, even though lifespan only starts this task once. In the common intermittent-TV-at-boot case, the new background cache warmer never starts, so large collections still depend on the user's page load/retry flow instead of recovering automatically.
Useful? React with 👍 / 👎.
…t failure Address Codex review comments on PR #74: 1. When prefetch aborts after consecutive failures, the IDs that actually failed were excluded from the retry list (only unattempted IDs were included). Now failed_ids are tracked separately and prepended to the retry list so they get another chance on the next cycle. 2. If _startup_prefetch fails to fetch the artwork list (TV unreachable at boot), it now schedules a retry after _PREFETCH_RETRY_COOLDOWN seconds instead of silently giving up. This ensures the background cache warmer eventually starts even with intermittent TV connectivity.
|
I will let this run overnight and see how things fare in the morning. |
Third round of fixes for #67 — thumbnail loading failures on large collections (525+ artworks).
What changed
Backend (server.py)
get_thumbnail_listnow usesattempts=1(~18s max) instead of the default 3 (~54s). Trips the circuit breaker faster.POST /api/thumbnails/retryendpoint: Resets the circuit breaker and schedules a fresh server-side prefetch for specified content IDs._thumb_prefetch_runningis now set beforecreate_task()at all 4 spawn sites, preventing duplicate prefetch tasks from being spawned between scheduling and execution.Frontend (index.html)
Tests
Failure modes addressed
attempts=1→ max ~18screate_taskat all spawn sitesHow it works for a user with 525 artworks
Fixes #67