tianyif
commented
8 months ago Hi @signumnova,
However, I never seem to get a player error picked up by my onPlayerError handler, even after a long time
How long did you observe while waiting for the onPlayerError event? Yes, there is a readTimeout on the data source, which is 8000ms by default. Once the exception is caught by the Loader, the loader will do the retry. There is a retryDelay before the retry actually starts, which is provided by the LoadErrorHandlingPolicy. The default logic is min((loadErrorInfo.errorCount - 1) * 1000, 5000), in milliseconds.
Also, there is a minimumLoadableRetryCount, which defines "minimum number of times to retry loading data prior to propagating the error", the default value is 3.
So with considering the retry delay and the retry count before propagating, the duration added up before seeing an error can be much longer than 8000ms.
Could you please let us know if that's the case based on your observation?
signumnova
Referring to Question #726 for context, I have a quick and dirty player app built with ExoPlayer 1.3.0-rc01
My player is playing an HLS stream and I am using DefaultHttpDataSource with HLSMediaSource.
Compiled with SDK 34 (since the 1.3.0 release needs that) but testing on API 29 emulator since my target is Android 10.
The player is working fine, and self recovers if I deliberately stop the flow of packets (by enabling a silent drop rule in my firewall).
However, I never seem to get a player error picked up by my onPlayerError handler, even after a long time. I have the connection and read timeouts at default on the data source which is 8000 mS. One the flow of packets stops, I see a change of state to "Buffering" but that is the last thing logged in logcat until I re-enable the flow.
Your reply to that earlier question implies that there are internal retries, so an http error doesn't immediately 'bubble up', but wondering how long that should take in practice before is gives up and generates an error?
Thanks SN