Output switcher appears broken after switching to CastPlayer

[NielsMasdorp]

So, I am using media3 version 1.2.1 and have a ForwardingPlayer like the UAMP demo app.

When I start local playback this is my media notification:

When I use the output switcher in the top right corner of the notification or use the casting button inside my app and switch to a casting device the output switcher breaks and shows "Other device".

This does not change when I switch back to local playback, so the output switcher remains in a non working state.

I am using the same MediaSession when casting, like UAMP does via setMediaSessionEnabled(false) in the CastOptionsProvider.

What would be the cause of this? For reference, you can find my implementation here: https://github.com/NielsMasdorp/Nederadio-Android/tree/master/app/src/main/java/com/nielsmasdorp/nederadio/playback

Thank you,

[AquilesCanta]

Ultimately, the behavior you observe is caused by MediaSession being configured as remote with invalid (or absent) remote device information (hence the "Other Device" text). Such device info is populated:

• When playing locally, by calling MediaSession.setPlaybackToLocal(...).
• When playing remotely, by calling MediaSession.setPlaybackToRemote(...), where the volume provider should link your session to a routing session (see here).

I believe media3 takes care of this plumbing for you, via onDeviceInfoChanged using the device info of each player (see here for instance). You probably want a reply from @marcbaechinger, but at least this should give you an idea on how to debug if you are in a hurry. He won't reply before Monday.

[NielsMasdorp]

@AquilesCanta Thanks. While debugging and starting a casting session I see setPlaybackToRemote being called but with VolumeProvider with null volumeControlId.

Also your link to the CastPlayer implementation of getDeviceInfo() just returns a hardcoded DeviceInfo instance without the routingControllerId being set. Could that not be related to this problem? Like this issue #142.

[marcbaechinger]

Yeah, I think you are both right.

AFAICT the required calls on the framework session are issued correctly in MediaSessionLegacyStub. CastPlayer though isn't aware of routes and doesn't know the routing controller ID.

Given it's really only the missing controller ID and if the Cast SDK offers an API to to get the routing controller ID for instance on RemoteMediaClient this can be easily added to the device info of a CastPlayer. I haven't found that API though.

@NielsMasdorp If you integrate with your app to support remote-to-local and local-to-remote and you already have the controller ID we could probably add a CastPlayer.setRouteControllerId(id) method and make the static device info update accordingly.

We need to investigate how to improve routing support with a Media3 session and/or with CastPlayer.

[NielsMasdorp]

@marcbaechinger I'm not sure I follow. How would I know the routeControllerId for the specific device I am casting to? Should this be forwarded to the Cast SDK team?

Also that leaves the issue of the output switcher not working after switching back to local playback as well, that does work before the first casting session is started.

[AquilesCanta]

I think we are mixing up things. There are two different milestones here, let's say:

• Milestone 1: I deem this to be a bugfix: Make the device chip stop saying "Other device" when you are playing locally. So, when you are playing locally, you'd get something like:
  

  Considering this works properly in UAMP (as per comment#1), I'm inclined to think this is a bug in the app. But it could potentially be a bug in media3. Once you fix this, you'll get the screenshot above for local, and for remote:

• Milestone 2: Make the device chip be populated properly when doing remote playback. This is a "feature request", and I think it's out of the scope of this ticket.

How would I know the routeControllerId for the specific device I am casting to?

We are working on adding support for this in media3. If this is really urgent for you, please file a fresh ticket once you've fixed "milestone 1" and we can provide some further guidance.

[NielsMasdorp]

@AquilesCanta I agree with your assessment. It seems like the first issue is a bug, but I am not sure the bug is on my end. So let's try to tackle that one first. It seems to be working in uamp demo, but uamp demo also shows 2 media notifications when a remote casting session is active.

and

Im using the same option provider:

class StreamOptionsProvider : OptionsProvider {

    @SuppressLint("VisibleForTests")
    override fun getCastOptions(context: Context): CastOptions {
        return CastOptions.Builder()
            .setReceiverApplicationId(APP_ID)
            .setCastMediaOptions(
                CastMediaOptions.Builder()
                    .setMediaSessionEnabled(false)
                    .setNotificationOptions(null)
                    .build()
            )
            .setStopReceiverApplicationWhenEndingSession(true)
            .build()
    }

    override fun getAdditionalSessionProviders(context: Context): MutableList<SessionProvider> {
        return mutableListOf()
    }

    companion object {
        private const val APP_ID = "A12D4273"
    }
}

So there should be only one media session at all times. I've attached a screen recording of the current behaviour while switching to remote and back to local.

https://photos.app.goo.gl/E5UJ5WjRG1Noe2Vz6

Findings:

• When the app starts all is fine, local playback shows correct notification with chip.
• When I switch to cast, for a very brief moment interestingly it actually shows the cast device in the chip and then the notification dissapears (this is visible in the screen recording) and reappears in another spot in the media center. When I am not so quick in swiping the notification panel it just shows on the correct first spot again. Or when I close the notification panel and reopen it also appears in the first spot as well.
• Switching back to local doesn't remove/reorder/recreates the notification, but the chip remains non working.

Is this anything to go by? I am kind of stumped at the moment why this is happening and not with uamp. For reference my relevant classes are here: https://github.com/NielsMasdorp/Nederadio-Android/tree/master/app/src/main/java/com/nielsmasdorp/nederadio/playback