Skip to content
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

Closed
loki666 opened this issue Oct 25, 2019 · 4 comments
Closed

CastPlayer should report Shuffle is disabled #6582

loki666 opened this issue Oct 25, 2019 · 4 comments
Assignees
Labels

Comments

@loki666
Copy link
Contributor

loki666 commented Oct 25, 2019

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));

@AquilesCanta
Copy link
Contributor

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?

@loki666
Copy link
Contributor Author

loki666 commented Oct 25, 2019

maybe I should have added that I'm using the mediasession extension.
My UI is observing the MediaController shuffleMode.

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

@tonihei
Copy link
Collaborator

tonihei commented Oct 25, 2019

Looks as if the shuffle mode (mediaSessionCompat.setShuffleMode) needs to be reset when changing player implementations.

ojw28 pushed a commit that referenced this issue Oct 30, 2019
…tion

Which ensures both get updated when the MediaSessionConnector player
changes.

Issue:#6582
PiperOrigin-RevId: 277254889
@loki666
Copy link
Contributor Author

loki666 commented Oct 30, 2019

looks good

@ojw28 ojw28 closed this as completed Oct 31, 2019
ojw28 added a commit that referenced this issue Nov 5, 2019
- 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
ojw28 added a commit that referenced this issue Nov 5, 2019
- 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
ojw28 pushed a commit that referenced this issue Nov 5, 2019
…tion

Which ensures both get updated when the MediaSessionConnector player
changes.

Issue:#6582
PiperOrigin-RevId: 277254889
@google google locked and limited conversation to collaborators Dec 31, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

5 participants