pocket-casts-android
pocket-casts-android copied to clipboard
Automattic
Pixel headphones double/triple tapping to go forward/back does not work
Description
It doesn't seem that double/triple tapping to go forward and backward works like it should (at least on Pixel phones). I did some testing of that functionality on different phones and different apps to see where it worked/didn't-work and this is what I found.
| Pixel 8 | Samsung A13 | |
|---|---|---|
| Pocket Casts ⏩ | ❌ | 🟢 |
| Pocket Casts ⏪️️ | ❌* | ❌ |
| YouTube Music ⏩️️ | 🟢 | 🟢 |
| YouTube Music ⏪️️ | 🟢 | 🟢 |
| Spotify ⏩️️ | 🟢 | ❌ |
| Spotify ⏪️️ | 🟢 | ❌ |
| Castbox ⏩ | 🟢 | ❌ |
| Castbox ⏪ | 🟢 | ❌ |
| Podbean ⏩ | 🟢 | ❌ |
| Podbean ⏪ | 🟢 | ❌ |
- I did notice that with Pocket Casts I would occasionally get a skip back to work, particularly if I just tapped the button a ton of times, but it basically never happened with normal use. It also looked like the playback might be updating it's position and then immediately jumped back to the previous playback position. If that's the case, we might be dealing with a race condition.
We do have some reports of this functionality working fine with Pixel Buds too, so not sure why it's working for some people and not others.
References
- Pocket Casts Forums - Skip function from Bluetooth device not working properly – Beta 7.52-rc-2 (9162)
- 7382261-zd-a8c
- 7353758-zd-a8c
Step-by-step reproduction instructions
- Play an episode on pocket casts
- Connect a pair of Pixel headphones (I was using wired, but we have quite a few reports from users having the issue with Bluetooth pixel buds)
- Double tap to go forward
- Observe the the audio pauses and unpauses but the playback position does not change
- Triple tap to go backwards
-
- Observe the the audio pauses and unpauses but the playback position does not change
Screenshots or screen recording
No response
Did you search for existing bug reports?
- [X] I have searched for existing bug reports.
Device, Operating system, and Pocket Casts app version
Samsung A13, Android 13, Pocket Casts 7.53 pre-release build Pixel 8, Android 14, Pocket Casts 7.52-rc-4
Same issue here with 7.53-rc5 on Android 14 AP11.231020.016.A1 on Pixel 6a but oddly only with my Sony WH-1000XM4 headphones, my Pixel Buds A Series work perfectly fine.
The Pixel Buds always work while the Sony headphones very rarely work too but 95% of the time don't. Play/Pause doesn't work either, the headphones make a sound that it recognizes the gesture, but nothing happens. Every other media app works fine, it's only Pocket Casts.
Same issue with Pixel Buds A and Pixel 4A, specifically with PocketCasts (I haven't checked anything else yet). Thanks for writing this up.
Same--pixel buds A and pixel 6A. PocketCasts v7.52 (9168). Android version 14 w/November 2023 security update.
@mchowning Do you know if this likely to get fixed soon? It's frustrating enough that I'll likely sideload 7.51 if it's gonna be a while, but I'll just deal with it if it's expected to be fixed quickly. Thanks.
👋 @hmayer00
Do you know if this likely to get fixed soon?
I'm planning to work on it this week.
It's frustrating enough that I'll likely sideload 7.51 if it's gonna be a while, but I'll just deal with it if it's expected to be fixed quickly. Thanks.
Are you saying this wasn't an issue in 7.51? I didn't realize this was a recent-ish regression.
FWIW, I've only noticed the issue for a couple of weeks. Thanks for looking into it.
I have the same situation with Pixel buds A and a Pixel 7 and pocketcasts.
We believe we have a fix for this in the 7.54-rc-3 beta release, which we've submitted to Google for review. If you get that version, please let me know if it fixes the issue for you.
W're still working on getting 7.54-rc-3 approved by Google.
Also, there is a separate issue that many apps seem to have where Pixel Buds cannot resume playback intermittently. When that is happening, the Pixel Buds also cannot skip forward or backward, although voice commands through the Pixel Buds to skip forward/backward seem to work even when that is happening.
I am closing this one since we don't have more reports related to this issue. We believe this PR fixed it.
