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

MediaSession ACTION_FAST_FORWARD should be disabled if player cannot seekTo #4001

Closed
izderadicka opened this issue Mar 19, 2018 · 4 comments
Closed
Assignees
Labels

Comments

@izderadicka
Copy link

Issue description

I have client using MediaControlerCompat with MediaSession extension from Exoplayer.
When playing media with unknown length (http stream chunk encoded) the seeking is disabled.
(state actions does not allow ACTION_SEEK_TO).
However state does enable action ACTION_FAST_FORWARD, which is implemented in MediaSessionConnector as seeking to current position plus defined offset.
So obviously if seeking is not possible, fast forward is not working too (actually goes to start of the stream).

So my expectation would be that ACTION_FAST_FORWARD should be also disabled when ACTION_SEEK_TO is disabled. Or is there some deeper logic?

Of course it's no big issue to check for both on client side, however I thought that connector should handle this logic, as it is using seek for fast forward. Same also for ACTION_REWIND.

Reproduction steps

Any client using playing http chunk encoded stream - in my case it's transcoded audio in ogg+opus.
Check actions available in PlaybackStateCompact - if ACTION_SEEK_TO is not allowed then ACTION_FAST_FORWARD and ACTION_REWIND should not be allowed too.

Link to test content

Unfortunately my stream are on private server. But I believe any chunk encoded http stream will behave same way.

Version of ExoPlayer being used

2.7.0

Device(s) and version(s) of Android being used

emulated Android 7.0
Samsung A3 with Android 7.0

A full bug report captured from the device

As this is rather question about logic of the connector I do not provide it now.
If necessary for detailed examination I can provide later,

@AquilesCanta
Copy link
Contributor

@marcbaechinger do you have time to look at this or shall I take it?

@marcbaechinger
Copy link
Contributor

Yes, the suggested behaviour sounds like what the connector should do. I look into this. Thanks for reporting!

@marcbaechinger
Copy link
Contributor

This is fixed in the DefaultPlaybackController which now only declares the fast forward and rewind actions if the current window is seekable.

If you need a quick fix for your code you can create a subclass of the DefaultPlaybackController and override the getSupportedPlaybackActions method to only return the required actions. Otherwise the change will land in the next release.

Thanks again for reporting!

@AquilesCanta
Copy link
Contributor

A commit reference will appear here once the push to github is made. Thanks for the lightning-fast fix, @marcbaechinger!

@ojw28 ojw28 added the bug label Mar 20, 2018
ojw28 pushed a commit that referenced this issue Mar 28, 2018
@ojw28 ojw28 closed this as completed Mar 28, 2018
ojw28 pushed a commit that referenced this issue Mar 29, 2018
@google google locked and limited conversation to collaborators Aug 10, 2018
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

4 participants