currentMediaItem is empty when a CastPlayer is being used

[spun]

I'm using a MediaLibraryService that switches the player from ExoPlayer to CastPlayer when a CastSession is available. When the ExoPlayer is active, calling getCurrentMediaItem() from a MediaController returns the correct MediaItem, but if the same call is done when the CastPlayer is the active one, I receive an empty MediaItem.

The method getWindow(...) inside CastTimeline is the one creating and using an empty MediaItem instead of the expected currentMediaItem.

[marcbaechinger]

This is a known issue which becomes more sever with AndroidX Media3 MediaSession. Implementing the Player interface properly is more important when we aim to be able to build a MediaSession with a MediaSession.Builder.

For right now I'm afraid I can't really give a better advice than that you need to maintain your own list of MediaItems that represents the playlist and from where you can lookup the media item by index with the given window index.

Somewhat aside: I think an approach to have a MediaSession with a Player that can change (local vs. remote playback with Cast) would be to have a custom Player implementation that delegates to an actual Player implementation and that allows to swap the actual implementation. It may for instance have a setPlayer(Player) method for swapping the current player with another. This way you can build a MediaSession with a MediaSession.Builder and delegate commands sent by a MediaController to either of the implementations under the hood. If you do that, that custom Player implementation would be the best place to maintain the list of MediaItems that is the playlist. It can also help you to work around #26 that is related to the CastPlayer not properly implementing the Player interface in the current state.

--
Some comments for context when someone is going to fix this (I stick with the bug label because I agree this is now a bug in context of AndroidX Media3):

There is an unwritten contract that a Player should provide an equal MediaItem with Player.getMediaItemAt(int index) that have been passed to the set/addMediaItem(MediaItem) methods. The same should be the case for Timeline.getWindow(...) as well.

CastPlayer currently fails to do that which we need to improve. At the very least CastPlayer should propagate the mediaId correctly which would be a first step although if we fix this that way we probably should comply with the whole MediaItem because the mediaId is not necessarily unique. There is a commit in the ExoPlayer repo for the dev2 branch which includes the mediaId when un/marshalling which is a first step towards this. CastTimeline is another step as mentioned above in the user's post.

[spun]

Thank you very much @marcbaechinger for the idea of the custom Player. I was able to fix the empty MediaItem problem with a modified CastTimeline, CastTimelineTracker and a custom MediaItemConverter (like you already said, the default is a bit limited), but your idea is way better than calling MediaSession#setPlayer(...) each time the player changes. By the way, something like that inside the media3-cast would be awesome.

Thanks again!

[NielsMasdorp]

@spun Could you elaborate how you managed to solve the empty MediaItem? I am currently relying on onMediaItemTransition and onMediaMetadataChanged callbacks inside my MediaController and I need the mediaId and mediaMetadata in said callbacks. Obviously this doesn't work when I switch to the CastPlayer in the MediaSessionService.

[spun]

Hi @NielsMasdorp. Unfortunately, I decided to wait until the issue is fixed. I'm currently running a modified version of the library with some changes made to CastTimeline (I could link you a Gist with the changes if you want) to fix the empty MediaItem problem until something is implemented in media3.

You could try the custom Player that switches between local and cast and also maintains the list of MediaItems. It's still a promising solution but, when I tried to do it, I was a bit overwhelmed with the RemoteMediaClient also being able to change the list of MediaItems and I don't have a working implementation yet.

If you can wait, when this issue is fixed, we should be able to at least retrieve the mediaId from the "empty" MediaItem. I think there was already a first step, but CastTimeline still returns the empty one, so we'll have to wait a bit longer.

[NielsMasdorp]

@spun Thanks for the update. In the meantime i've decided to tackle the problem as well. I am currently working on my own implementation of a custom Player which indeed switches from local to cast internally. It works, but it is tailored to my use case. I don't have a list of items but only playback a single MediaItem at a time, so the solution is just to keep a reference to the current MediaItem and that's that. But I am sure i've missed some edge cases. After that I will wait for updates in the media3 implementation (or at least a CastPlayer which implements the Player correctly).