Claude 6e9a1f9711 Drop an image decode that finished after the screen moved on ... A remote image is decoded on a background thread and mounted on the main thread, and it was mounted unconditionally — nothing checked it was still wanted. ImageLoader allows 10s connect plus 30s read, against a slot that is typically 10s, so a slow or briefly unreachable host finished long after the playlist had advanced and painted itself over whatever was playing. When that was a video the mount also called exoPlayer.stop(), which lands in STATE_IDLE — and the advance listener only fires onVideoComplete on STATE_ENDED or a playback error. Nothing scheduled the next item, so the playlist stopped permanently. The routine refresh could not rescue it: the playlist signature was unchanged, so the update returned early, and content was still on screen so nothing looked wrong from the server's side. The failure branch had the same shape more mildly — onImageError posts next(), cutting short whatever had since started playing. Every path that takes the screen now bumps a generation, and a decode applies only if the value it captured is still current. PipOverlay.loadImageInto has always carried this token; the fullscreen path was the one place a background result was applied with no staleness check. 4 tests over the guard, kept as pure arithmetic so they need no Android runtime, including that only the latest of several queued decodes wins and that the error branch is gated too. 134 Android JVM tests green. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Uaeo9MvzKoyXuN6ZsbhtkL		2026-07-30 21:01:37 -05:00
..
src	Drop an image decode that finished after the screen moved on	2026-07-30 21:01:37 -05:00
build.gradle.kts	chore(release): v1.9.27	2026-07-30 19:16:55 -05:00
proguard-rules.pro	Initial open source release	2026-04-08 12:14:53 -05:00