[iOS Bug]: Seeking sometimes stops playback and is very janky #411

New Issue

2026-04-24T23:20:19+02:00

adam commented

2026-04-24 23:20:19 +02:00

Originally created by @jramer on GitHub (Jan 24, 2023).

Saw this old issue that is similar (and fixed) but I'm experiencing issues in the latest build and also when building latest master.

Started looking at the code and I've found the issue but need some help to be sure not to break other stuff.

In AudioPlayer.swift -> seek() the player rate decides whether to continue playing when done with the seek.

public func seek(_ to: Double, from: String) {
    let continuePlaying = rate > 0.0

    self.pause()
    ...

But since the player is paused self.pause() during seek and there is an observer on AVPlayer.rate that updates self.rate we will get a zero rate on a later seek that happens while paused.

So one fix would be to improve how to decide the value for continuePlaying but I can't really understand why it needs to pause() during seek? It makes the player less responsive and works as expected if the pause is omitted.

I can see that PlayerProgress.shared.syncFromPlayer() is being run on play/pause and it might be important to sync on seek but isn't it enough that pause() runs on destroy?

Steps to reproduce

Start playing an audiobook. Stream or download doesn't matter
Tap seek (using the time step buttons) multiple times in the same direction.

Expected behaviour

Player should seek correct amount of seconds (taps times amount of seconds) and keep playing.

Actual behaviour

Player pauses, seeks and sometimes resumes play. And usually misses a tap or two.

Environment data

Audiobookshelf Version: Testflight 0.9.6.0 (17) and also tried this commit on master

Android App?
iOS App?

iOS Issue

iOS Version: 16.2

iPhone model: iPhone 12 Pro

Originally created by @jramer on GitHub (Jan 24, 2023). Saw [this old issue](https://github.com/advplyr/audiobookshelf-app/issues/354) that is similar (and fixed) but I'm experiencing issues in the latest build and also when building latest master. Started looking at the code and I've found the issue but need some help to be sure not to break other stuff. In [AudioPlayer.swift -> seek()](https://github.com/advplyr/audiobookshelf-app/blob/master/ios/App/Shared/player/AudioPlayer.swift#L351) the player `rate` decides whether to continue playing when done with the seek. ``` public func seek(_ to: Double, from: String) { let continuePlaying = rate > 0.0 self.pause() ... ``` But since the player is paused `self.pause()` during seek and there is an observer on `AVPlayer.rate` that updates `self.rate` we will get a zero rate on a later seek that happens while paused. So one fix would be to improve how to decide the value for `continuePlaying` but I can't really understand why it needs to `pause()` during seek? It makes the player less responsive and works as expected if the pause is omitted. I can see that `PlayerProgress.shared.syncFromPlayer()` is being run on play/pause and it might be important to sync on seek but isn't it enough that `pause()` runs on `destroy`? ### Steps to reproduce 1. Start playing an audiobook. Stream or download doesn't matter 2. Tap seek (using the time step buttons) multiple times in the same direction. ### Expected behaviour Player should seek correct amount of seconds (taps times amount of seconds) and keep playing. ### Actual behaviour Player pauses, seeks and sometimes resumes play. And usually misses a tap or two. ### Environment data Audiobookshelf Version: Testflight 0.9.6.0 (17) and also tried [this commit on master](https://github.com/advplyr/audiobookshelf-app/commit/a8c66ff808f114ade47c39efb6abe37ce74c8683) - [ ] Android App? - [x] iOS App? #### iOS Issue iOS Version: 16.2 iPhone model: iPhone 12 Pro

adam added the bug label 2026-04-24 23:20:19 +02:00

adam closed this issue

2026-04-24 23:20:19 +02:00

adam commented

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

@hobesman commented on GitHub (Jan 24, 2023):

I'm pretty sure this or something similar happens on Android too. It's as if it wants to wait for playback to resume before acknowledging additional taps on the skip button, and some of those taps seem to get lost along the way.

@hobesman commented on GitHub (Jan 24, 2023): I'm pretty sure this or something similar happens on Android too. It's as if it wants to wait for playback to resume before acknowledging additional taps on the skip button, and some of those taps seem to get lost along the way.

adam commented

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

@advplyr commented on GitHub (Jan 26, 2023):

I'm not as familiar with iOS as I am with the Android side, but for Android when you perform a seek the audio player pauses and resumes. Behind the scenes the audio has to be stopped momentarily to seek and I imagine this is the same for iOS.

I'm still focused on the Android side at the moment so it may be a bit before I dig into the iOS code again. Feel free to make a PR and I can do testing.

@advplyr commented on GitHub (Jan 26, 2023): I'm not as familiar with iOS as I am with the Android side, but for Android when you perform a seek the audio player pauses and resumes. Behind the scenes the audio has to be stopped momentarily to seek and I imagine this is the same for iOS. I'm still focused on the Android side at the moment so it may be a bit before I dig into the iOS code again. Feel free to make a PR and I can do testing.

adam commented

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

@advplyr commented on GitHub (Feb 20, 2023):

Fixed in v0.9.62-beta

@advplyr commented on GitHub (Feb 20, 2023): Fixed in [v0.9.62-beta](https://github.com/advplyr/audiobookshelf-app/releases/tag/v0.9.62-beta)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/audiobookshelf-app#411