Media item downloaded repeatedly when repeat mode is Player.REPEAT_MODE_ONE

[REQUIRED] Issue description

In 2.12.0, ExoPlayer will repeatedly download MediaItem until released, wasting user bandwidth.

https://i.imgur.com/nZDROLY.png All these requests happened within 10 seconds of playing.

[REQUIRED] Reproduction steps

Simply prepare a SimpleExoPlayer like so and check the network logs using your favorite MITM inspector.

exoPlayer.setMediaItem(MediaItem.fromUri("https://i.imgur.com/dgNL2jK.mp4"))
exoPlayer.prepare()
exoPlayer.repeatMode = Player.REPEAT_MODE_ONE
exoPlayer.seekTo(playbackTime)

This only happens with the new .setMediaItem() & .prepare() API. The deprecated .prepare(MediaSource) still works correctly.

[littledot]

Thanks for working on caching, I appreciate the 2.12.0 changes that makes setting up a cache for SimpleExoPlayer much easier. But I’m talking about no-cache players, and I think you might be confusing Progressive vs Adaptive streams. 😃

Behavior <2.12.0, with no cache configured: Progressive streaming, using .prepare(MedisSource) -> only downloads once DASH, HLS using .prepare(MediaSource) -> downloads non-stop (I understand the difference and expect that this is normal)

Behavior >= 2.12.0, with no cache configured: Progressive streaming, using .setMediaItem(MediaItem) & .prepare() -> downloads non-stop Progressive streaming, using .prepare(MediaSource) -> only downloads once DASH, HLS using .prepare(MediaSource) -> downloads non-stop

But let me spell out why I think this is a big deal. 😃

.setMediaItem(MediaItem) + .prepare() - a new API in 2.12.0 - is meant to deprecate .prepare(MediaSource), yet they yield radically different behaviors when dealing with Progressive media types. This is a huge foot gun for anyone thinking this might just be another minor update. Especially since the javadocs for .prepare(MediaSource) make it sound like a simple find-and-replace refactor, but there’s actually an undocumented breaking change when a Progressive media source is being passed in to .setMediaItem(MediaItem).

If this inconsistency between prepare(MS) and prepare() is the way forward, I think it should at least be called out in the Javadocs.

[marcbaechinger]

Cool! I’m glad it’s working! 😃

It seems that okHttpClient does the caching (TIL). It probably caches files in a behaviour similar to a web browser (honouring cache-control, max-age headers and the like). The DefaultMediaSourceFactory that is in charge for doing the media item to media source conversion uses the DefaultDataSourceFactory that makes HTTP requests with a plain http connection which is stateless and does not cache anything.

If you want to have the media item API use okhttp, you can inject the OkHttpDataSourceFactory into the default media source factory when building your player (not compiled and tested that code below, beware, but it should work that way).

DefaultMediaSourceFactory defaultMediaSourceFactory = new DefaultMediaSourceFactory()
    .setDataSourceFactory(new OkHttpDataSourceFactory(okHttpClient, null));

SimpleExoPlayer player = new SimpleExoPlayer.Builder(context)
    .setMediaSourceFactory(defaultMediaSourceFactory)
    .build();