Output switcher appears broken after switching to CastPlayer

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,

@marcbaechinger

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.

@AquilesCanta

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

@NielsMasdorp

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.

@marcbaechinger

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

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.

@AquilesCanta

@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

I'm currently endeavoring to get the output switcher working properly in my app and seeing the same issues (and more; hopefully those are on my end) though since Media3 doesn't cover my use cases, I'm doing a lot more manually. I thought it might be interesting to point out that I'm seeing the Other Device grayed out chip on YouTube's cast sessions as well (Fully updated Pixel 8 Pro).

I figured YouTube would be the premiere consumer experience to measure against for the new output switcher capabilities, but it doesn't seem to have them enabled, it doesn't expose any cast devices within the output switcher. Perhaps YT team is hitting similar issues.

@AquilesCanta

@AquilesCanta seems something went wrong with assigning this issue..

Populate DeviceInfo in CastPlayer using MediaRouter2 info

Hey folks, this should be fixed in 1.9. You can find docs in

https://developer.android.com/media/media3/cast/create-castplayer

and also a ref implementation in the session demo.

Please don't forget to use option setMediaSessionEnabled(false) in your CastOptions.

Navigation Menu

Repository navigation

Output switcher appears broken after switching to CastPlayer #1056

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Output switcher appears broken after switching to CastPlayer #1056

Description

Activity

AquilesCanta commented on Jan 31, 2024

NielsMasdorp commented on Feb 1, 2024

marcbaechinger commented on Feb 5, 2024

NielsMasdorp commented on Feb 6, 2024

AquilesCanta commented on Feb 6, 2024

NielsMasdorp commented on Feb 7, 2024

rezonant commented on Feb 9, 2024

NielsMasdorp commented on Feb 13, 2024

AquilesCanta commented on Dec 18, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions