iOS: Certain headphones can't pause ABS when playback speed is above 1x #946

New Issue

2026-04-24T23:43:59+02:00

adam commented

2026-04-24 23:43:59 +02:00

Originally created by @indiefan on GitHub (Apr 14, 2024).

Originally assigned to: @indiefan on GitHub.

Steps to reproduce

Install Bose Music app with compatible headphones
Begin playback in ABS with playback speed set to something above 1x
Try to pause via headphone controls

Expected behaviour

Tell us what should happen
ABS should pause playback

Actual behaviour

Tell us what happens
Nothing. Playback continues as if no command was registered.

Environment data

Audiobookshelf Version: 2.8.1

Android App?
iOS App?

iOS Issue

iOS Version: 0.9.73-beta

iPhone model: iPhone 15 Pro Max

Originally created by @indiefan on GitHub (Apr 14, 2024). Originally assigned to: @indiefan on GitHub. ### Steps to reproduce 1. Install Bose Music app with compatible headphones 2. Begin playback in ABS with playback speed set to something above 1x 3. Try to pause via headphone controls ### Expected behaviour - Tell us what should happen - ABS should pause playback ### Actual behaviour - Tell us what happens - Nothing. Playback continues as if no command was registered. ### Environment data Audiobookshelf Version: 2.8.1 - [ ] Android App? - [X] iOS App? #### iOS Issue iOS Version: 0.9.73-beta iPhone model: iPhone 15 Pro Max

adam added the bug label 2026-04-24 23:43:59 +02:00

adam closed this issue

2026-04-24 23:44:00 +02:00

adam commented

2026-04-24 23:44:01 +02:00

@indiefan commented on GitHub (Apr 14, 2024):

So I can confirm that this issue is mitigated if I change automaticallyWaitsToMinimizeStalling to false. Obviously that's probably not a viable fix since it probably impacts streaming use-cases, but it helps narrow down the interaction between ABS and Bose Music (my guess is that it comes down to timeControlStatus: https://developer.apple.com/documentation/avfoundation/avplayer/1643485-timecontrolstatus)

I also discovered that the player is using an outdated api for controlling rate (pre-defaultRate introduced in iOS 16+). I'm a bit curious if cleaning up the rate issues also resolves this bug, or if they're separate issues.

I suspect (though haven't confirmed) that the rate issue is related to https://github.com/advplyr/audiobookshelf-app/issues/973 and have confirmed that it's trivial to repro issues similar to https://github.com/advplyr/audiobookshelf-app/issues/622 (when you change rate to anything over 0, the player starts playing, but our state-logic hasn't been executed, so the next time you toggle play/pause from the commandCenter, it thinks it needs to start playing and does a short seek as if it was playing from a paused state).

@indiefan commented on GitHub (Apr 14, 2024): So I can confirm that this issue is mitigated if I change `automaticallyWaitsToMinimizeStalling` to `false`. Obviously that's probably not a viable fix since it probably impacts streaming use-cases, but it helps narrow down the interaction between ABS and Bose Music (my guess is that it comes down to `timeControlStatus`: https://developer.apple.com/documentation/avfoundation/avplayer/1643485-timecontrolstatus) I also discovered that the player is using an outdated api for controlling `rate` (pre-`defaultRate` introduced in iOS 16+). I'm a bit curious if cleaning up the `rate` issues also resolves this bug, or if they're separate issues. I suspect (though haven't confirmed) that the `rate` issue is related to https://github.com/advplyr/audiobookshelf-app/issues/973 and have confirmed that it's trivial to repro issues similar to https://github.com/advplyr/audiobookshelf-app/issues/622 (when you change `rate` to anything over 0, the player starts playing, but our state-logic hasn't been executed, so the next time you toggle play/pause from the `commandCenter`, it thinks it needs to start playing and does a short seek as if it was playing from a paused state).

adam commented

2026-04-24 23:44:03 +02:00

@indiefan commented on GitHub (Apr 14, 2024):

Ended up being slightly different issue. We're always reporting a defaultRate of 1.0. This doesn't currently impact actual playback, because we always immediately override the defaultRate by setting a temporary rate. But when the user listens at a rate above 1x, the Bose Music app sees the reported temporary rate being faster than the reported defaultRate and interprets it as a srubbing event, waiting to reinstate 'pause' until after it completes (which it never does).

The solution to this specific bug is to report the correct defaultRate (which I believe we're holding onto statefully as tmpRate).

A follow up CL should refactor the internal rate-management code to use defaultRate and the new notification for rate changes (https://developer.apple.com/documentation/avfoundation/avplayer/3746584-ratedidchangenotification) instead of the generic keyChange observer approach we currently use.

@indiefan commented on GitHub (Apr 14, 2024): Ended up being slightly different issue. We're always reporting a `defaultRate` of 1.0. This doesn't currently impact actual playback, because we always immediately override the `defaultRate` by setting a temporary `rate`. But when the user listens at a rate above 1x, the Bose Music app sees the reported temporary rate being faster than the reported defaultRate and interprets it as a srubbing event, waiting to reinstate 'pause' until after it completes (which it never does). The solution to this specific bug is to report the correct `defaultRate` (which I believe we're holding onto statefully as `tmpRate`). A follow up CL should refactor the internal rate-management code to use `defaultRate` and the new notification for rate changes (https://developer.apple.com/documentation/avfoundation/avplayer/3746584-ratedidchangenotification) instead of the generic keyChange observer approach we currently use.

adam commented

2026-04-24 23:44:03 +02:00

@advplyr commented on GitHub (May 21, 2024):

Fixed in v0.9.74-beta

@advplyr commented on GitHub (May 21, 2024): Fixed in [v0.9.74-beta](https://github.com/advplyr/audiobookshelf-app/releases/tag/v0.9.74-beta)

adam commented

2026-04-24 23:44:04 +02:00

@KaiStarkk commented on GitHub (Nov 8, 2024):

Thanks for finding these edge cases for #622 , nice stuff.
FWIW, this bug still exists on the YouTube app, so hopefully someone from Google comes across this and fixes it 😂

@KaiStarkk commented on GitHub (Nov 8, 2024): Thanks for finding these edge cases for #622 , nice stuff. FWIW, this bug still exists on *the YouTube app*, so hopefully someone from Google comes across this and fixes it 😂

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/audiobookshelf-app#946