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

Re-prepare player when user triggers play via UI components with the player in an error state #7882

Open
fonebinary opened this issue Sep 10, 2020 · 5 comments
Assignees

Comments

@fonebinary
Copy link

Hi,

I am facing an issue transportControls.xxx() not working after network error.

Please help me out

@marcbaechinger
Copy link
Contributor

marcbaechinger commented Sep 10, 2020

I think we need some more info to help you with this. Like what do you mean with transportControls.xxx not working anymore.

At a first sight it may be that there was a playback error because the network was not working and you need to make the player prepare again? You should see a stack trace or similar in you log in this case.

I assume you are using the MediaSessionConnector with ExoPlayer and you are using a MediaController to send transport commands to the media session which then is received by the connector to call appropriate methods on the ExoPlayer instance in your app. Can you confirm that or if I'm mistaken explain in a bit more detail what your app is doing?

If my assumption is right, can you please put a breakpoint somewhere in the MediaSessionConnector to see whether these command still arrive? This would be around here.

Please clarify/confirm my assumption and make a bug report right after you reproduced the failure and upload here. That would be the information which would enable us to help you some further.

@google-oss-bot
Copy link
Collaborator

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

@google-oss-bot
Copy link
Collaborator

Since there haven't been any recent updates here, I am going to close this issue.

@fonebinary if you're still experiencing this problem and want to continue the discussion just leave a comment here and we are happy to re-open this.

@nagendrasaavn
Copy link

I solved this issue by Re-Prepare exoplayer in PlaybackPreparer onPrepare(). Thanks

@ojw28
Copy link
Contributor

ojw28 commented Oct 11, 2020

@marcbaechinger - I think this is to do with what MediaSessionConnector (and other components such as PlayerControlView) do when the play button is pressed with the player in an error state. Currently, they use the PlaybackPreparer if one is set, and else they do nothing. For example:

So in the situation described in this issue, the play button (or play command received via MediaSession) is a no-op unless the application has set a PlaybackPreparer.

The way this works pre-dates the existence of Player.prepare(). Now that we have Player.prepare(), I think it would be a good idea to call it, via a ControlDispatcher.dispatchPrepare method, in the case that a PlaybackPreparer hasn't been set. This will make it so that the play button will retry playback rather than doing nothing. If we do this, it also becomes possible to deprecate PlaybackPreparer, since the ability to implement/override ControlDispatcher.dispatchPrepare provides equivalent functionality (including the ability to add a MediaItem in the case that the playlist is empty when the button is pressed).

@ojw28 ojw28 reopened this Oct 11, 2020
@ojw28 ojw28 changed the title transportControls.play() not working after network error Re-prepare player when user triggers play via UI components with the player in an error state Oct 11, 2020
kim-vde pushed a commit that referenced this issue Nov 11, 2020
Issue: #7882
PiperOrigin-RevId: 341394254
icbaker pushed a commit that referenced this issue Nov 30, 2020
Issue: #7882
PiperOrigin-RevId: 341394254
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants