Hi @JosephSanjaya,

Thanks for your feedback on the preload manager! Please allow me to clarify more details:

• How frequently did see this issue on the demo-shortform app?
• If you tried DefaultPreloadManager in your app, what preloadLooper did you inject? Is it the same looper that is injected as playbackLooper to the ExoPlayer?

Looking forward your reply!

Hi @tianyif , thanks for fast response

Issue Frequency: I have encountered the issue once in shortform demo, but its really rare in the demo.

PreloadLooper: In our app, we’re using the same looper for the preload manager as the one injected for the ExoPlayer’s playbackLooper.

Looking forward to any further insights you might have!

Hi @JosephSanjaya,

Thanks for the feedback! Could you please also specify what media (DASH, HLS, and etc.) your app is preloading / playing when you saw this issue?

Hello @tianyif, we are using HLS media and DASH for DRM Short

Hi @JosephSanjaya,

Thanks so much for the precious information!

When the device is offline, the Loader will be handling the exception thrown from the LoadTask. From the linked code you can see, at L498, it informs the callback on the load error, and then attempts to retry at L505. The callback at L498 varies in implementation for different streams.

• For HLS stream, it does some operations like checking if the error code is suitable for retry, excluding the failed track for a while, and then it either continues loading the new track if it is prepared otherwise loads to prepare it. In both the cases, I see how this bug happens.

  • For not-prepared case, it will soon ask the loader to start the loading task, then the currentTask will be set non-null, the loading will be really started on another thread and this method returns. Then traveling back to where we departed, in the initial Loader code at L505, it then initiates another load start, then hit this exception because the currentTask is non-null, given that all the above logic are running synchronouly.

  • For prepared case, it will request the callback if loading should be continued. Then PreloadMediaSource also initiates the continueLoading in a sync way, then the following story is the same.

• The DASH stream is the same as the second sub-case above.

In fact, upon handling message in Loader, we will set the currentTask to null in this finish method, but later onLoadError accidentally sets a new currentTask. We will be looking at all the other stream implementations, and then provide a fix for this issue.

Thank you again for reporting this issue!

Hello @tianyif
Even I am facing the same issue,
Media3 Version: 1.4.0
As I open my app, and start preloading media using PreloadMediaSource and I switch off my internet my app crashing with the following crash log:
FATAL EXCEPTION: playback-thread-collection Process: com.indus.appstore, PID: 2292 java.lang.IllegalStateException at androidx.media3.common.util.Assertions.checkState(Assertions.java:85) at androidx.media3.exoplayer.upstream.Loader$LoadTask.start(Loader.java:367) at androidx.media3.exoplayer.upstream.Loader$LoadTask.handleMessage(Loader.java:505) at android.os.Handler.dispatchMessage(Handler.java:106) at android.os.Looper.loopOnce(Looper.java:226) at android.os.Looper.loop(Looper.java:313) at android.os.HandlerThread.run(HandlerThread.java:67)

@tianyif Is there any way to avoid this crash? The number of crashes is increasing, leading to user drop-offs.

Hi @akash1296-dev,

I'm working on the fix of this issue and it will be included in the 1.4.1 release. Meanwhile if you hope to avoid the crash I'd suggest you to temporarily rollback your app to the version before adopting 1.4.0, and roll-forward when 1.4.1 is available.

@JosephSanjaya,

I pushed a change for fixing the PreloadMediaSource (corresponding to the second sub bullet point in #1568 (comment)), if possible, could you please try this with our development branch main? For the first sub bullet point, I'll still need to discuss with my team to see why it was never seen in the player.

OKay got it, will check on it

Thanks! @tianyif

The fix is with 1.4.1.

The theory I initially stated was incorrect, however, the real theory is similar. I happened to reproduce this issue and found out the crash was only encountered when loading the HLS media playlist. In such case, MediaPlaylistBundle being the onLoadError callback, and on the path of notifyPlaylistError, it will further call listener.onPlaylistError. HlsMediaPeriod being the listener will further call callback.onContinueLoadingRequested, and then the following story is the same as the previous theory (PreloadMediaSource handles the MediaPeriod.Callback methods synchronously).

Please note that in such case the returned exclusionFailed will be true as this is an UnknownHostException without an fallback option, so the action will be RETRY, then the Loader will start retry, and here comes this issue that the currentTask is already set from PreloadMediaSource.continueLoading.

The code paths in the previous theory will not cause this issue because for the SampleStream, its corresponding track will be either excluded and we will "continue loading" another track, then we will not RETRY loading this Loadable, or the track is not able to be excluded and then we RETRY, but in between we are not requesting continueLoading.

Sorry for being verbose here! Now that the pushed fix should solve the crash, I'm closing this issue, but do let me know if there is anything wrong when trying out 1.4.1.

Hello @tianyif, we just finished implementing new features using v1.4.1, and its flawless.

Thank you really much for your effort