-
Notifications
You must be signed in to change notification settings - Fork 6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CastPlayer should report Shuffle is disabled #6582
Comments
I don't really see how this can happen. CastPlayer doesn't currently support shuffle mode. Plus player control view seems to update the button state accordingly. The notification is not necessary because it should never change. Can you state exactly what's going on? Perhaps provide a set of minimal changes to reproduce in the demo app? |
maybe I should have added that I'm using the mediasession extension. When i switch from ExoPlayer (with shuffle enabled) to CastPlayer, the shuffleMode of the MediaController is not set to false, because CastPlayer doesn't report it through the onShuffleModeEnabledChanged() method |
Looks as if the shuffle mode ( |
…tion Which ensures both get updated when the MediaSessionConnector player changes. Issue:#6582 PiperOrigin-RevId: 277254889
looks good |
- This is for consistency with PlayerControlView. - Also update PlayerNotificationManager notification if shuffle mode changes. This is for consistency with what happens when the repeat mode changes. By default the notification will be unchanged, but custom implementations can extend and then override createNotification, and given these modes change infrequently it feels like we can just do this. The alternative for achieving consistency would be to remove handling of repeat mode changes. Issue: #6582 PiperOrigin-RevId: 277925094
- This is for consistency with PlayerControlView. - Also update PlayerNotificationManager notification if shuffle mode changes. This is for consistency with what happens when the repeat mode changes. By default the notification will be unchanged, but custom implementations can extend and then override createNotification, and given these modes change infrequently it feels like we can just do this. The alternative for achieving consistency would be to remove handling of repeat mode changes. Issue: #6582 PiperOrigin-RevId: 277925094
…tion Which ensures both get updated when the MediaSessionConnector player changes. Issue:#6582 PiperOrigin-RevId: 277254889
Use case description
When switching from ExoPlayer to CastPlayer, I have an UI inconstancy on the Shuffle state when ExoPlayer was shuffle enabled.
The UI is still reporting that CastPlayer queue is shuffled.
Proposed solution
in CastPlayer::updateInternalState() add something like
notificationsBatch.add(new ListenerNotificationTask(listener -> listener.onShuffleModeEnabledChanged(false));
The text was updated successfully, but these errors were encountered: