Repository navigation
Requests for multiple video playlists at the same time #3254
Description
Version
Media3 1.8.0
More version details
When we upgraded from media3 1.3.1 to 1,8.0 we noticed that in some cases the player requests several playlists for different video variants (almost) simultaneously. In 1.3.1 it happens that at the point of variant change the old and the new variant playlist are requested. However, in 1.8.0 we see cases of 3 video playlists requested at the same time. This often happens when the playback is experiencing network issues and by making more requests than required makes the network problem worse.
From our analysis of what might be causing the additional playlists requests the main suspect is the call to maybeActivateForPlayback() in
DefaultHlsPlaylistTracker,getPlaylistSnapshot() which was added in media3 1.4.0.
Devices that reproduce the issue
Proprietary Android device with API level 34.
Devices that do not reproduce the issue
No response
Reproducible in the demo app?
Not tested
Reproduction steps
An HLS playback with several video variants on a network which causes playlist HTTP transactions to fail with timeouts/
Expected result
Single video playlist requested at each moment of time.
Actual result
3 different video playlists requested in parallel.
Media
There is no specific media on which it happens,
It seems to happen on any live stream given mentioned network conditions.
Activity
tianyif commentedon Jun 30, 2026
I tried to reproduce the your issue from a working HLS live stream, with setting a network download rate limit (simulate a bad network environment). I'm not sure I hit exact the reproduction that you faced, but I did have some observations:
setActiveForPlayback(false)), and new track (B) as active (setActiveForPlayback(true)). However, after the old track A was set inactivate, I could still spot track A being loaded for one more time.The problem in above observation 2) is because - Upon a success of a playlist load, we will check if it is still primary playlist or active for playback, if yes, then we call this method [1]. Inside this method, we may delay the refresh if the regular refresh interval hasn't fully passed. But, if the playlist is set inactive while waiting, then we don't know that, and when it is the time, we will go ahead to load in spite of its being inactive for playback.
I have a guess for your issue, which maybe the combination of the above two observations. Assume that you're originally playing track A, and then due to the network, you switch to track B, then track A will still load one more time at some point later, and meanwhile due to the unstable network again, you quickly switch from B to C. So there are chances that you are seeing track A, B and C are being loaded "almost at the same time".
I can create a change for fixing my observation 2). Hopefully this will exactly fix your issue.
[1] https://github.com/androidx/media/blob/release/libraries/exoplayer_hls/src/main/java/androidx/media3/exoplayer/hls/playlist/DefaultHlsPlaylistTracker.java#L1016
sruditsky commentedon Jun 30, 2026
@tianyif
Thanks.
Can you please share the change.
Skip scheduled HLS playlists refreshes if no longer primary or active
tianyif commentedon Jul 3, 2026
Hi @sruditsky, the fix is 520a024 and it's included in our upcoming 1.11.0-beta01. Please do have a try after beta01 is released.
sruditsky commentedon Jul 8, 2026
@tianyif
Thanks.
We applied this change to the ExoPlayer release we are using and applied also some additional code changes.
We are going to test it and will be back with a comment.
tianyif commentedon Jul 29, 2026
Closing due to inactivity. Feel free to reopen if there is still an issue.
Skip scheduled HLS playlists refreshes if no longer primary or active