media [Cast] Playback stops in 1.8.0 (1.7.1 works fine) when switching to CastPlayer instance

After updating from 1.7.1 to 1.8.0, playback stops inside Media3 (with no exception in log) when switching from local (ExoPlayer) to CastPlayer instance. After some debugging, I found which change causes the issue, but I don't know why it causes playback to stop internally in Media3.

In PR #2279, this change was added to the availableCommands:

.addIf(COMMAND_GET_VOLUME, isSetVolumeCommandAvailable())
.addIf(COMMAND_SET_VOLUME, isSetVolumeCommandAvailable())

If I comment out these two lines, playback works fine as before. The issue occurs after sending this event three lines below:

listeners.queueEvent(
    Player.EVENT_AVAILABLE_COMMANDS_CHANGED,
    listener -> listener.onAvailableCommandsChanged(availableCommands));
}

I tried removing all our listeners and the problem persists. The only listener left is the one that is automatically added inside Media3 when creating a MediaLibrarySession (MediaSession).

class MediaSessionImpl {

    ...

    private void setPlayerInternal(@Nullable PlayerWrapper oldPlayerWrapper, PlayerWrapper newPlayerWrapper) {
        ...
        PlayerListener playerListener = new PlayerListener(this, newPlayerWrapper);
        newPlayerWrapper.addListener(playerListener);
        this.playerListener = playerListener;
        ...
    }

    ...

}

And this is, in my opinion, the reason why it works in the Demo app, because the Demo Cast sample does not use a Session.

I'm posting this as a question because I'm not 100% sure if this is a Media3 bug or if there's a problem somewhere in our implementation that I can't think of at the moment :)

Any ideas @MGaetan89 or @marcbaechinger or @AquilesCanta ?

Nov 21 '25 19:11 TomasValenta

Hey thanks for reporting. We've added support for Cast in the Session demo app. But I don't think we've observed the issue you describe.

With the info I have in this ticket, this looks like an integration issue. For us to help we'll need you to pinpoint the event that's causing your cast playback to pause. This can happen during the initialization of the media queue (e.g. in setMediaItems) or during a call to remoteMediaClient.pause(). If you have a dependency by source, it should be relatively easy to identify the difference between both versions.

Another way to proceed is if you can provide a minimal reproducible example app.

Please do try playing with the session demo at tip of tree and see if you can repro the issue. The session demo supports cast and uses a media session, so it should have everything you mention as necessary conditions.

Nov 21 '25 20:11 AquilesCanta

Hello Santiago,

Thanks for the quick response!

I understand your points, but I'd like to clarify a few things:

Our Cast integration works perfectly fine with 1.7.1. The issue appears immediately after updating to 1.8.0 without any changes to our code. Shouldn't the report be investigated, especially if the problematic commit and new code has already been identified (PR #2279)?
Regarding the Session demo: I see now that Cast support was added to the Session demo, but only in main branch (so currently 1.9.0-alpha01 and 1.9.0-beta01), which is not stable releases yet. The "issue" I'm reporting is in the latest stable 1.8.0 release.
The specific event: As I mentioned in my initial report, the issue occurs immediately after the EVENT_AVAILABLE_COMMANDS_CHANGED is dispatched after adding the volume commands in PR #2279. The playback stops (not pause and also the session notification disappears) internally in Media3 when this event is processed by the PlayerListener that's automatically added by MediaSessionImpl. On our side, the event is not being processed, as I wrote, I tried removing all our listeners - the playback simply stops after this event is fired.

I've already pinpointed the exact change that causes the issue. If I comment out those two lines from PR #2279, everything works as expected. The question is: why does adding these volume commands to availableCommands cause the CastPlayer to stop playback when a MediaSession is present?

Would it be possible to look into this specific interaction between the volume commands and MediaSession's internal PlayerListener or suggest any possible connections?

Nov 21 '25 20:11 TomasValenta

Shouldn't the report be investigated, especially if the problematic commit and new code has already been identified (PR https://github.com/androidx/media/pull/2279)?

Yes, but we cannot rule out the possibility of an app issue either. And because I cannot see a logical link between the two problematic lines and a playback interruption, I'm leaning to an app code issue. But I don't have sufficient info to confirm nor deny, hence I need your help to narrow down the issue. An important note: We have a reference implemenation of an app that uses media session, and we are not able to repro the issue.

why does adding these volume commands to availableCommands cause the CastPlayer to stop playback when a MediaSession is present?

The answer is: It shouldn't. And, in the context of the session demo: It doesn't.

Would it be possible to look into this specific interaction between the volume commands and MediaSession's internal PlayerListener or suggest any possible connections?

We have an integration in the session demo, which as far as I can tell works fine.

On our side, the event is not being processed, as I wrote, I tried removing all our listeners - the playback simply stops after this event is fired.

A few questions:

Can you try the latest alpha release, and see if you can repro the issue. If only for the sake of investigating this issue?
If you have a source dependency, can you please log all (relevant) interactions with RemoteCastPlayer / RemoteMediaClient to try to find out which one might be the problematic one. Once we identify the problematic (stop() or pause(), for example) call, it will be trivial to find the root cause.

As things stand now, we only know that two seemingly harmless lines have an unexpected consequence in an app whose code I don't have visibility over (please don't share your full app, but we'd be ok with a minimal reproducible example). And I'm not able to repro in the apps we use for development.

Nov 24 '25 14:11 AquilesCanta

Hey @TomasValenta. 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!

Dec 11 '25 18:12 google-oss-bot

Hey @google-oss-bot. Once the stable 1.9.x version is released, we’ll try to re-implement the Cast client and hopefully identify the root cause of this issue. At the moment, I don’t have any more time allocated to this.

Dec 12 '25 17:12 TomasValenta