Skip to content

Add methods for replacing playlist items in Player #8046

Closed

Description

@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.

Activity

  1. marcbaechinger commented on Oct 6, 2020

    @marcbaechinger
    Contributor

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

  2. tonihei commented on Oct 6, 2020

    @tonihei
    Collaborator

    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.

  3. georgi-neykov-hub commented on Oct 6, 2020

    @georgi-neykov-hub
    Author

    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.

  4. georgi-neykov-hub commented on Oct 6, 2020

    @georgi-neykov-hub
    Author

    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?

  5. marcbaechinger commented on Oct 7, 2020

    @marcbaechinger
    Contributor

    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?

  6. georgi-neykov-hub commented on Oct 9, 2020

    @georgi-neykov-hub
    Author

    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.

  7. marcbaechinger commented on Oct 9, 2020

    @marcbaechinger
    Contributor

    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.

  8. 1 remaining item

  9. emagombe commented on Dec 24, 2022

    @emagombe

    I have the same need.
    But I got a writing this code
    int count = exoPlayer.getMediaItemCount();
    exoPlayer.addMediaSources(count, mediaSources);
    exoPlayer.seekTo(count, 0);
    if(count > 0) {
    exoPlayer.removeMediaItems(0, count);
    }
    exoPlayer.prepare();
    Basically it adds a list of mediasources below the current list, changes the index to the first item of the new list and then removes all the items above and reindex to 0.
    It works fine. I tried exoPlayer.clearMediaItems() but for me it crashes the notification so this method works better.

  10. marcbaechinger commented on Jan 3, 2023

    @marcbaechinger
    Contributor

    I'm not sure I understand what is the difference of the code above and this line

    exoPlayer.setMediaSources(mediaSources, /* startIndex= */ 0, /* startPositionMs= */ 0);
    

    The above line seems to do the same, but with less code. Is there a difference in behaviour with your approach?

  11. emagombe commented on Feb 8, 2023

    @emagombe

    Lol, yeah, it works the same way. Thanks!

  12. Mohammad3638363 commented on Aug 3, 2023

    @Mohammad3638363
  13. Mohammad3638363 commented on Aug 6, 2023

    @Mohammad3638363

    شكرا جزيلا

  14. locked and limited conversation to collaborators on Oct 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions