Add methods for replacing playlist items in Player

[georgi-neykov-hub]

[REQUIRED] Use case description

In Exoplayer v2.12.0 the new playlist/MediaItem API is missing methods for replacing an existing item(s) at a given position.
The feature is needed if someone needs to refresh the metadata/clipping data/duration/... of an item already in the playlist. In my case I am using a diffing library to update the playlist via a change script which results in add/remove/change/move calls. Yes, one can always do a remove/add, but calling Player.addMediaItems() then Player.removeMediaItems() results in multiple playlist change notifications. I was a bit amazed that there's even a bulk move method (Player.moveMediaItems()), but nothing for changing an existing item.

Proposed solution

Add Player.replaceItem(int, MediaItem) and Player.replaceItems(Int, List<MediaItem>) methods or something similar.

[marcbaechinger]

Yes, that's a very reasonable request. Thanks for filing!

[tonihei]

but calling Player.addMediaItems() then Player.removeMediaItems() results in multiple playlist change notifications

Out of interest, why is getting multiple playlist change notifications a problem for your case? I think we discussed replaceItem at some point and concluded you can always use remove+add to achieve the same goal. Note that this is different from moveMediaItem that provides additional functionality to ensure even the currently playing item can move without interrupting playback.

[georgi-neykov-hub]

With the new media2 extension each player timeline change notification triggers notifications for media session's playlist changes which involve posting on a Handler, submitting (and allocating) Runnable s to an Executor and so on. Adding and using the requested methods during calls to SessionPlayerConnector.replacePlaylistItem () or direcly calling Player.replaceItem() on an instance hooked to a SessionPlayerConnector would reduce the overhead significantly.

[georgi-neykov-hub]

Note that this is different from moveMediaItem that provides additional functionality to ensure even the currently playing item can move without interrupting playback.

@tonihei , how can the MediaItem for the currently playing item be updated? With the current properties it's basically the title of the item?
Would the playback be interrupted if the currently played item's MediaItem is replaced with a new one with the same mediaId, but with possible differences in other fields?

[marcbaechinger]

Replacing the media item would mean replacing the underlying MediaSource and this would interrupt the currently playing media when replaced and prepare the new media source that's created for the new media item internally.

Do I understand correctly that you actually would rather want to only update the MetaData part (currently only holding the title) or the MediaItem.PlaybackProperties.tag?

[georgi-neykov-hub]

Do I understand correctly that you actually would rather want to only update the MetaData part (currently only holding the title) or the MediaItem.PlaybackProperties.tag?

Well, not explicitly, but I am also interested how this can be achieved with the current API.

The reason for the request is to be able run any player playlist updates though a diffing library and apply a list of minimal changes so that bigger playlists can be updated in a efficient manner. The obvious choice is DiffUtil in the androidx.recyclerview library, which uses E. Myers' algorithm and builds a change script with add/remove/change/move operations.

Not that the setup doesn't work with the current APIs, I'm just worried about the unnecesary playback state updates and notifications done on each step and searching for ways to reduce them.

I'm even considering of adding a feature request for methods for controlling these notifications or the ability to do batches of changes and report them as a single change.

[marcbaechinger]

Ok, thanks for clarification. If you are going to replace items in the queue in that sense 'blindly' by just running the recorded changes of another object graph, you can probably not know in advance whether this will remove or replace the playing media item which would led to a interruption of playback. This will be the case with a replaceMediaItems(...) method as well, when the range of replaced items contains the playing item.

I suggest we leave this issue being an enhancement about this request around adding a method replaceMediaItems to keep things manageable.