Seeking to an invalid item repeatedly crashes the plugin without logs

[kmod-midori]

Which API doesn't behave as documented, and how does it misbehave? seeking to an invalid item repeatedly crashes the plugin without logs

Minimal reproduction project https://github.com/chengyuhui/just_audio/tree/error-flood Just replaced URLs

To Reproduce (i.e. user steps, not code) Steps to reproduce the behavior:

1. Click on the second item (which has https://127.0.0.1/)
2. See it jumps to the third (https://127.0.1.1/)
3. Click on the second item again, and keep clicking it if the player jumps to the next one
4. Do this until the player does not jump anymore
5. Notice that the underlying player no longer responds to any calls

Error messages

E/ExoPlayerImplInternal(29938): Playback error
E/ExoPlayerImplInternal(29938):   com.google.android.exoplayer2.ExoPlaybackException: Source error
E/ExoPlayerImplInternal(29938):       at com.google.android.exoplayer2.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:579)
E/ExoPlayerImplInternal(29938):       at android.os.Handler.dispatchMessage(Handler.java:103)
E/ExoPlayerImplInternal(29938):       at android.os.Looper.loop(Looper.java:228)
E/ExoPlayerImplInternal(29938):       at android.os.HandlerThread.run(HandlerThread.java:67)
E/ExoPlayerImplInternal(29938):   Caused by: com.google.android.exoplayer2.upstream.HttpDataSource$HttpDataSourceException: Unable to connect
E/ExoPlayerImplInternal(29938):       at com.google.android.exoplayer2.upstream.DefaultHttpDataSource.open(DefaultHttpDataSource.java:356)
E/ExoPlayerImplInternal(29938):       at com.google.android.exoplayer2.upstream.DefaultDataSource.open(DefaultDataSource.java:201)
E/ExoPlayerImplInternal(29938):       at com.google.android.exoplayer2.upstream.StatsDataSource.open(StatsDataSource.java:84)
E/ExoPlayerImplInternal(29938):       at com.google.android.exoplayer2.source.ProgressiveMediaPeriod$ExtractingLoadable.load(ProgressiveMediaPeriod.java:1015)
E/ExoPlayerImplInternal(29938):       at com.google.android.exoplayer2.upstream.Loader$LoadTask.run(Loader.java:415)
E/ExoPlayerImplInternal(29938):       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
E/ExoPlayerImplInternal(29938):       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
E/ExoPlayerImplInternal(29938):       at java.lang.Thread.run(Thread.java:919)
E/ExoPlayerImplInternal(29938):   Caused by: java.net.ConnectException: Failed to connect to /127.0.0.1:443
E/ExoPlayerImplInternal(29938):       at com.android.okhttp.internal.io.RealConnection.connectSocket(RealConnection.java:147)
E/ExoPlayerImplInternal(29938):       at com.android.okhttp.internal.io.RealConnection.connect(RealConnection.java:116)
E/ExoPlayerImplInternal(29938):       at com.android.okhttp.internal.http.StreamAllocation.findConnection(StreamAllocation.java:186)
E/ExoPlayerImplInternal(29938):       at com.android.okhttp.internal.http.StreamAllocation.findHealthyConnection(StreamAllocation.java:128)

This is the last error that the player produces, nothing can be done after this unless the application is restarted.

Expected behavior The plugin should continue to work after that many errors.

Flutter SDK version

Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 2.0.3, on Linux, locale zh_CN.UTF-8)
[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
[✓] Chrome - develop for the web
[✓] Android Studio
[✓] IntelliJ IDEA Ultimate Edition (version 2020.3)
[✓] Connected device (2 available)

• No issues found!

Additional context There seems to be similar behavior on iOS according to one of my friends, but I don't personally own an iPhone, so I can't test that out.

[ryanheise]

Related to #353

[ryanheise]

The Android implementation was programmed to automatically skip to the next item on an error, but if there are too many errors (> 5) then it assumes something underlying must be wrong and it aborts making further connections, e.g. to prevent an infinite loop of errors.

This behaviour is not ideal so it is just a matter of choosing a better behaviour and implementing it. To keep the discussions of how to approach this in one place, let's have the discussions on #353 .