Cast Extension Artwork metadata not working

[robm92]

As of the recent deprecation of CastPlayer.loaditem() , I have updated to using com.google.android.exoplayer2.MediaMetadata.

Previously, I would add artwork like this and it would appear in the system notification media item as well as the Cast Player ExpandedControlsActivity.

val movieMetadata = MediaMetadata(MediaMetadata.MEDIA_TYPE_MOVIE)
movieMetadata.addImage(WebImage(Uri.parse(posterImage)))

I am now attempting to use the functions:
movieMetadata.setArtworkUri() movieMetadata.setArtworkData()

But they do not result in the image being shown.

[marcbaechinger]

On a first sight, it looks like that could be implemented pretty easily at least for the case when an app is using MediaMetadata.setArtworkUri. In such a case the DefaultMediaItemConverter can just add the url by using addImage(WebImage(metadata.artworkUri)) as described above.

We will look into this. Thanks for reporting! Marked as enhancement.

If you want to have this right now you may want to consider to inject your own implementation of MediaItemConverter to the constructor of the CastPlayer.

[dani3l3]

DId you actually solve this?

I am kind of stuck with having to do the same migration due to the deprecation.... I managed to rewire the basics:
changed the loadItems() into setMediaItems() with a bunch of related changes including the MediaItemConverter along the lines of what is described here #7915 got the actual stream to play BUT the whole controller and notification tray is not showing at all/is completely busted... if I click on the cast button while it's playing, it says "no media selected" and knows nothing of what's going on...

Could Google folks please elaborate a bit more on what's needed to get back the original functionality after this breaking change?
Thanks

[marcbaechinger]

From the perspective of the CastPlayer you get the same functionality by using the castPlayer.setMediaItems method instead of the loadItems method. The MediaItems are then converted by the MediaItemConverter to the cast media items. So if you have specific requirements you can create your custom MediaItemConverter that adds more metadata fields than the default according to your requirements.

The notification is not posted by the CastPlayer but by the app. Can you let me know how you think the changes in the CastPlayer affect the way you do the notification. How did you do the notification before?

[dani3l3]

Hi, thanks for the quick reply.
I don't know if I need more fields... it was over a year ago and I relied on a bunch of out of the box/default stuff; I wasn't actually doing a lot of custom work.... which seems to be now required to be built by hand to keep the same functionality?

I can find things like MediaRouteControllerDialog styling (along the lines of
https://stackoverflow.com/questions/38997276/style-dialog-after-click-on-mediaroutebutton ) in the code and calls to RemoteMediaClient, but not a lot more... but I think RemoteMediaClient is what is supposed to keep track of the MediaQueueItems, which are now just MediaItems... and that is probably where it goes wrong (fails silently).

Apologies if I can't explain it better at the moment...

Thanks

[marcbaechinger]

I don't know if I need more fields

In the code before you have built MediaQueueItems and passed them to loadItems(). Now after the deprecated method has been removed, you need to add the fields to the MediaItem when building it with the MediaItem.Builder. This is the same MediaItem that you use with ExoPlayer. So you need to do this only once and you can use the same MediaItem for both players.

When you want to transition playback from ExoPlayer to CastPlayer you can just set the same list of media items again. CastPlayer now has the very same interface like ExoPlayer which over all makes things easier.

Because under the hood, CastPlayer is still using MediaQueueItems we need to convert them when passing it to RemoteMediaClient of the Cast SDK. That's when the MediaItemConverter comes into play.

So you are certainly right that the interface has change. However, I think it's for the benefit of the user who is building an app with ExoPlayer and CastPlayer. Sorry if this causes some more effort than you planned for migrating to the current version. Please accept my apologies.

So if you before have used fields for MediaQueueItem that are not copied over by the default converter, you need to create a custom converter (the artwork is an example of missing properties in the current version. We will push an updated DefaultMediaItemConverter to the dev-v2 branch soon, that supports more fields including the artwork out-of-the-box).

Styling MediaRouteControllerDialog falls under what the cast SDK is doing. CastPlayer does not deal with this so I don't think that changes in the CastPlayer create difficulties with this. Please let me know if you think differently.

[dani3l3]

Thanks, I appreciate the detailed explanation.

In the code before you have built MediaQueueItems and passed them to loadItems(). Now after the deprecated method has been removed, you need to add the fields to the MediaItem when building it with the MediaItem.Builder. This is the same MediaItem that you use with ExoPlayer. So you need to do this only once and you can use the same MediaItem for both players.

Yes I have done this part.

Because under the hood, CastPlayer is still using MediaQueueItems we need to convert them when passing it to RemoteMediaClient of the Cast SDK. That's when the MediaItemConverter comes into play.

Yes, I conceptually understand the back and forth that needs to happen.

So you are certainly right that the interface has change. However, I think it's for the benefit of the user who is building an app with ExoPlayer and CastPlayer. Sorry if this causes some more effort than you planned for migrating to the current version. Please accept my apologies.

I do accept the apologies but yes it does cause more effort. It is something Google keeps doing.... for the same reason I am waiting to update billing library because it also has breaking changes. But I digress.

So if you before have used fields for MediaQueueItem that are not copied over by the default converter, you need to create a custom converter (the artwork is an example of missing properties in the current version. We will push an updated DefaultMediaItemConverter to the dev-v2 branch soon, that supports more fields including the artwork out-of-the-box).

Here I tried following the example you gave in this other thread #7915 .... but it only partially works, nowadays.... that was written a while ago and some more things have changed :-) ... for example the key method .getTag() doesn't work anymore.... that, too, has been since deprecated..... how quickly things change! I tried replacing it with just the .tag property.... which compiles.... only to figure out that the whole playbackProperties (or localConfiguration - they are basically the same stuff, right?) come up as a NULL object at runtime??.... I have not understood why....

return (MediaQueueItem)mediaItem.playbackProperties.getTag();

..... so my coverter doesn't really convert, so far..... I managed to wire up the basics because I have the stream URL in another field mediaId of the MediaItem object.... so in the converter I was able to rebuild a basic MediaQueueItem object.... but indeed it's not really a 'conversion' and I lose all other info/metadata which are needed down the road by the UX....

would you be so kind to point me at a newer example of working code for such a custom converter that would work with the 2.16 version?

Styling MediaRouteControllerDialog falls under what the cast SDK is doing. CastPlayer does not deal with this so I don't think that changes in the CastPlayer create difficulties with this. Please let me know if you think differently.

You are most probably right.... once I manage to have a working converter we will be able to confirm if things are picked up again by the UX elements or not.

Thanks a lot,

[google-oss-bot]

Hey @robm92. We need more information to resolve this issue but there hasn't been an update in 14 weekdays. I'm marking the issue as stale and if there are no new updates in the next 7 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

[google-oss-bot]

Since there haven't been any recent updates here, I am going to close this issue.

@robm92 if you're still experiencing this problem and want to continue the discussion just leave a comment here and we are happy to re-open this.