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

Pressing Play/Pause button twice on remote devices triggers Command_Seek_To_Next #962

Closed
1 task
charlesEnigma opened this issue Jan 11, 2024 · 11 comments
Closed
1 task
Assignees
Labels

Comments

@charlesEnigma
Copy link

charlesEnigma commented Jan 11, 2024

Version

Media3 1.1.1

More version details

No response

Devices that reproduce the issue

Fire Tv Stick 4k Max (2nd Gen) running Fire OS 8.1.0.2 = Android 11
Sony Bravia A95L running Android 12
Sony Bravia A95K running Android 11

Devices that do not reproduce the issue

Devices without Play/Pause button

Reproducible in the demo app?

No

Reproduction steps

Issue is the same as this issue: #233

We're seeing the issue on devices with a Play/Pause button on their remote. The issue is pressing the Play/Pause twice is triggering the COMMAND_SEEK_TO_NEXT command inside Media3 MediaSession. Originally we created a workaround for this issue since this was a known bug: androidx/media#233. Our workaround is causing an issue on FireTV for the Next voice command so we are removing the workaround but notice this issue persists.

Our app is using Media3 version 1.1.1.

Any suggestions on how to prevent MediaSession from triggering COMMAND_SEEK_TO_NEXT when Play/Pause button is pressed twice?

Expected result

Pressing Play/Pause multiple times plays or pauses playback.

Actual result

The next episode command is triggered.

Media

Not applicable

Bug Report

@charlesEnigma
Copy link
Author

Closing ticket. This issue is resolved with 1.2.0

@charlesEnigma
Copy link
Author

Sorry, for the confusion. When updating to version 1.2.0 our workaround was re-enabled so it appeared to be fixed but after removing the workaround we are seeing the issue in version 1.2.0 as well.

@tianyif tianyif self-assigned this Jan 12, 2024
@tianyif
Copy link
Contributor

tianyif commented Jan 12, 2024

Hi @charlesEnigma,

Starting from 1.2.0, MediaSession.Callback.onMediaButtonEvent has been added so you can override the default implementation and handle media buttons in a custom way. Could you please try this and see if it can solve your problem?

@tianyif
Copy link
Contributor

tianyif commented Jan 12, 2024

I'm re-tagging it as "bug" as we should figure out why the remote device doesn't resolve the double tap as next, because if it does, the remote device can define the behaviour of the tapping rather than the library or apps.

@tianyif tianyif assigned marcbaechinger and unassigned tianyif Jan 15, 2024
@marcbaechinger
Copy link
Contributor

marcbaechinger commented Jan 16, 2024

I think the issue is related to TV remotes that sends key events over Bluetooth. This may be a GoogleTV remote or a generic D-pad TV remote like for instance for a Sony Bravia.

The double-click detection seems to be most useful on mobile devices when a user has connected a BT headset to the device. I think it's justifiable to simply disable double-click detection on TV devices.

@charlesEnigma Any thoughts whether this would help for your case?

@charlesEnigma
Copy link
Author

@tianyif,

I will try overriding MediaSession.Callback.onMediaButtonEvent and see if we can handle the media buttons in a custom way.

@marcbaechinger,
Yes, disabling double-click detection on TV devices would help our use case. By disabling double-click detection on TV devices we would simply be preventing the users from rapidly pressing buttons correct? For example, the user presses the "play/pause" button waits at least 2 seconds, and presses the "play/pause" button again triggering the "play/pause" functionality.

copybara-service bot pushed a commit that referenced this issue Jan 16, 2024
Issue: #962
PiperOrigin-RevId: 598876214
@marcbaechinger
Copy link
Contributor

marcbaechinger commented Jan 17, 2024

By disabling double-click detection on TV devices we would simply be preventing the users from rapidly pressing buttons correct?

The library doesn't swallow events after this change. All events will be delivered but the events won't be translated to a skip next event but the events arrive at the player resulting in pausing then playing again which is what the user intended to do with pressing twice.

@marcbaechinger
Copy link
Contributor

I'm closing this issue as it is fixed with the commit above. Please open a new issue if required.

@charlesEnigma
Copy link
Author

charlesEnigma commented Jan 18, 2024

@tianyif and @marcbaechinger ,

I was able to override KEYCODE_MEDIA_PLAY_PAUSE using [MediaSession.Callback.onMediaButtonEvent].

override fun onMediaButtonEvent(
            session: MediaSession,
            controllerInfo: MediaSession.ControllerInfo,
            intent: Intent
        ): Boolean {

            val keyEvent: KeyEvent? = intent.getParcelableExtra<KeyEvent>(Intent.EXTRA_KEY_EVENT)
            val keyCode = keyEvent?.keyCode
            when (keyCode) {
                KeyEvent.KEYCODE_MEDIA_PLAY_PAUSE  -> {
                    if(keyEvent.action == KeyEvent.ACTION_UP) {
                        if (session.player.playWhenReady) {
                            session.player.pause()
                        } else {
                            session.player.play()
                        }
                    }
                    return true
                }
                else ->  return super.onMediaButtonEvent(session, controllerInfo, intent)
            }
        }

Questions:

  1. Disable double-click detection on TV devices is this something the developer is expected to implement or will this be included in future versions of media3?

@marcbaechinger
Copy link
Contributor

The commit referenced above implements this and this will be part of the next release.

@charlesEnigma
Copy link
Author

@marcbaechinger,

Awesome and thank you. The team will be looking forward to the next release. :-)

@androidx androidx locked and limited conversation to collaborators Mar 18, 2024
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