Repository navigation
Will getDeviceInfo() ever be supported for CastPlayer? #142
Description
Describe your question in detail.
I'm developing a podcast app which supports chrome cast and we recently moved to media3. We are using MediaController to handle all playback and doing some UI changes regarding of what player is currently being used (exo/cast). For that we thought using onDeviceInfoChanged() in Player.Listener and doing changes according to playbackType would be a way to go, but it didn't seem to work so after some debugging I've noticed that CastPlayer doesn't support getDeviceInfo() method and always returns DeviceInfo.UNKNOWN with playbackType DeviceInfo.PLAYBACK_TYPE_LOCAL.
So my question is will getDeviceInfo() method ever be supported for CastPlayer and is there any other way to tell where playback is happening (exo/cast) from MediaController?
Activity
marcbaechinger commentedon Aug 15, 2022
I think it should be easy to provide a
DeviceInfowithPLAYBACK_TYPE_REMOTEand min/maxVolume set to 0 (seeCastPlayer.getVolume()that always returns 0 due to setting the volume not being supported with cast player). Marking as an enhancement.If you are using
ExoPlayerandCastPlayeronly you should be able to doIf it delivers true, playback is happening on the cast player. It's a bit hacky but should work. After the change you should be able to check for
PLAYBACK_TYPE_REMOTEas you suggest.Add device info to CastPlayer
Add device info to CastPlayer
Add device info to CastPlayer
Add device info to CastPlayer
Chore/bump exo 2.18.2 (#66)
ziem commentedon Jan 4, 2023
@JaCobbMedia does
onDeviceInfoChangedwork for you out of the box? When is it triggered?marcbaechinger commentedon Jan 4, 2023
On what event would you expect the
onDeviceInfoChangedto be called?In the context of the
CastPlayerthis issue is about, the device info only changes ifMediaSession.setPlayer()is called and the player is changed for instance fromExoPlayertoCastPlayer(or vice versa). In this case thePlayerInfois updated and sent to the controller.MediaControllerImplwould then receive the newPlayerInfo, find that itsDeviceInfois different and callonDeviceInfoChanged.If this is not working for you, can you add some more details about how you change the
DeviceInfoof the session?ziem commentedon Jan 5, 2023
@marcbaechinger thanks for the description you provided. Thanks to it, I think I know where my problem is.
In my case
MediaSession.setPlayer()is called once as I'm using a similar approach to the one described in #39. I implementedPlayerand the switch betweenExoPlayerandCastPlayerhappens internally without additionalMediaSession.setPlayer()calls.The composite player thing initialy seemsed like a good solution but do you see any other problems with it that I may encounter in the future?
marcbaechinger commentedon Jan 5, 2023
I think the
DeviceInfois a special case because it is kind of a static property of the player that actually never changes.The composite approach makes IMO sense if a player is replaced by another player and this new player should continue the playback of the former player. Like when you want to transfer the playlist,
mediaItemIndexandpositionMsfrom the old to the new player.For the special
DeviceInfocase, you'd have to call the listeners from your compositeForwardingPlayer. Assumed you already have overriddenaddListener/removeListener, callingonDeviceInfoChange()should solve the issue. I can't think of a similar case where such a static property needs to be notified.JaCobbMedia commentedon Jan 5, 2023
@ziem I went with UAMP approach with
ReplacableForwardingPlayer(because I needed a bit more control rather than just fully rely onMediaController) and basically callonDeviceInfoChange()whenever I switch players. But as @marcbaechinger saidMediaControllernow callsonDeviceInfoChange()when session player gets changed andDeviceInfodoesn't match with previous, so if you're usingMediaControllerit should work out of the boxziem commentedon Jan 9, 2023
This helps a lot. Thank you both @JaCobbMedia & @marcbaechinger for your answers and solutions.
marcbaechinger commentedon Jan 9, 2023
Ok, cool. I close again as this is working as intended.
Chore/merge canary in (#74)