mirror of
https://github.com/screentinker/screentinker.git
synced 2026-08-14 14:23:14 -06:00
fa31eb9cc3
Symptom 1's 'stuck on first load, fixed by toggling the playlist' is stale download backoff. On a fresh device the first downloads fail while the link is settling; DownloadCoordinator escalates an exponential backoff (15s..5min cap), and ensure() then SKIPS those items. The 60s playlist refresh re-fires onPlaylistUpdate but ensure() still skips them, and backoff was only ever cleared by forget() (content-delete) — never by a re-assignment. So the item stays stuck until the 5-min window happens to lapse; toggling the playlist is just a manual way to wait it out. Fix (storm-safe — neither reset fires on the routine same-playlist 60s refresh): 1. DownloadCoordinator.resetBackoff(id) / resetAllBackoff() — clear attempts + nextAttemptAt but KEEP inFlight (single-flight preserved, no duplicate .part). 2. onPlaylistUpdate resets backoff for each item ONLY when the content-id signature changed (first load, reassignment, toggle-back), then ensures — so a genuine (re)assignment retries immediately. Same-signature 60s refresh -> no reset -> the retry-storm guard stays intact. 3. Network onAvailable (was onLost-only) -> resetAllBackoff() + requestPlaylistRefresh, so content that failed while the link was settling retries the moment real connectivity arrives. Tests: DownloadCoordinatorTest — resetBackoff/resetAllBackoff re-attempt a backed-off item before the clock advances; existing backoff/single-flight tests unchanged. :app:testDebugUnitTest green. Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| CacheValidationTest.kt | ||
| ContentDownloadTest.kt | ||
| DownloadCoordinatorTest.kt | ||