-
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
MediaSession ACTION_FAST_FORWARD should be disabled if player cannot seekTo #4001
Comments
@marcbaechinger do you have time to look at this or shall I take it? |
Yes, the suggested behaviour sounds like what the connector should do. I look into this. Thanks for reporting! |
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! |
A commit reference will appear here once the push to github is made. Thanks for the lightning-fast fix, @marcbaechinger! |
Issue: #4001 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=189722812
Issue: #4001 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=189722812
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,
The text was updated successfully, but these errors were encountered: