mirror of
https://github.com/jellyfin/jellyfin-android.git
synced 2026-10-30 18:52:03 +01:00
Kyle FarnungandNiels van Velzen
b4d4837fda
**Changes** When Exoplayer is used on the Android app it lets the server decide which mode to use (direct play, direct stream, or transcode) based on the device and content. If the content contains formats incompatible with ExoPlayer (like compressed PGS subtitles), it will fail to load the source. On the Android TV app it shows a similar source error in this case, but still plays successfully. Checking the server shows that the content is being remuxed without the subtitles, resolving the issue. Similarly, enabling subtitles in the player forces a transcode that allows the content to play. This change adds similar fallback behavior, but it attempts to play the highest quality stream on transient errors (like network flakiness). This approach is based on https://github.com/jellyfin/jellyfin-androidtv/pull/3916 and the follow-up fix https://github.com/jellyfin/jellyfin-androidtv/pull/4999. The retry workflow: 1. Try again without restrictions: it might have been a transient error 2. Try disabling direct play: maybe the container was an issue 3. Finally try transcoding when nothing else worked The last error time is captured to reset the retry count after 30 seconds have elapsed. This should hopefully be enough time to avoid falling back unnecessarily for transient issues. Retries will always start with unrestricted again to maximize the quality and minimize the stress on the server. Intentional track changes (audio or subtitle) also reset the retry budget, since those are user-initiated reloads rather than errors. There's a race condition between retries in which the queue could try to change the source. This is handled via coroutine cancellation. There's still a small race which could cause the media from the current retry to load briefly before the source change starts. This should be self-correcting in practice. **Issues** Fixes #1931