Retry playback on error forever for progressive sources#48
Draft
duvholt wants to merge 1 commit intodoublesymmetry:mainfrom
Draft
Retry playback on error forever for progressive sources#48duvholt wants to merge 1 commit intodoublesymmetry:mainfrom
duvholt wants to merge 1 commit intodoublesymmetry:mainfrom
Conversation
The default behavior stops retrying after a fairly short time
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I'm opening this PR as a discussion on a potential behavior change when playback stops because of exoplayer errors.
When e.g. playing long mp3 files over the network the whole file is usually not buffered which is expected.
The problem is when the user loses network connection and runs out of buffered media ExoPlayer will only retry playback for a fairly short time. After a few retries an error is emitted and the state transitions to idle.
Currently there's no obvious way to resume playback when in idle, but this can be fixed by this related PR #47
However, in my use case it makes sense to retry for a much longer time as the user is likely to regain network connection and then wants to audio to continue playing.
The simplest fix is just to retry forever as I've done is this PR, but it might make more sense to either make this user configurable or just increase the retry count to something bigger. The default is 3.
I only made the change for progressive media sources as I'm not sure if it also makes sense for streaming sources.