Resuming playback sometimes jumps to wrong time #442

New Issue

2026-04-24T23:23:30+02:00

adam commented

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

Originally created by @JakobTischler on GitHub (Feb 12, 2023).

Steps to reproduce

Play and pause (via Bluetooth)
Some time later, resume (via Bluetooth)

Expected behaviour

Resume from time that was paused at.

Actual behaviour

Sometimes (not always) ABS seeks to wrong time, sometimes multiple times directly after another (see screenshot)
1. At 13:11, I resume playback at position 09:40:23
2. It immediately jumps to 06:37:10, then again to 04:35:47, then again to 04:14:46
I think that has only happened when pausing/resuming via Bluetooth, but I can't be certain, and I'm also not sure this would have anything to do with the problem.

Environment data

Audiobookshelf Version:

Android App? v0.9.61-beta
iOS App?

Android Issue

Android version: 13
Device model: Pixel 7
Stock or customized system: Stock

Originally created by @JakobTischler on GitHub (Feb 12, 2023). ### Steps to reproduce 1. Play and pause (via Bluetooth) 2. Some time later, resume (via Bluetooth) ### Expected behaviour - Resume from time that was paused at. ### Actual behaviour - Sometimes (not always) ABS seeks to wrong time, sometimes multiple times directly after another (see screenshot) ![image](https://user-images.githubusercontent.com/748857/218310994-25007202-dd09-4669-9ddf-91d8562242fc.png) 1. At 13:11, I resume playback at position 09:40:23 2. It immediately jumps to 06:37:10, then again to 04:35:47, then again to 04:14:46 - I _think_ that has only happened when pausing/resuming via Bluetooth, but I can't be certain, and I'm also not sure this would have anything to do with the problem. ### Environment data Audiobookshelf Version: - [x] Android App? v0.9.61-beta - [ ] iOS App? #### Android Issue - Android version: 13 - Device model: Pixel 7 - Stock or customized system: Stock

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

adam closed this issue

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

adam commented

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

@hobesman commented on GitHub (Feb 12, 2023):

Just to narrow down, is it streaming or a downloaded book?

@hobesman commented on GitHub (Feb 12, 2023): Just to narrow down, is it streaming or a downloaded book?

adam commented

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

@JakobTischler commented on GitHub (Feb 12, 2023):

It's a downloaded book.

@JakobTischler commented on GitHub (Feb 12, 2023): It's a downloaded book.

adam commented

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

@milesian01 commented on GitHub (Feb 17, 2023):

Same problem here. Just as OP reported, this also happens to me when pause/resume via Bluetooth on stock Android, Pixel 6 Pro.

@milesian01 commented on GitHub (Feb 17, 2023): Same problem here. Just as OP reported, this also happens to me when pause/resume via Bluetooth on stock Android, Pixel 6 Pro.

adam commented

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

@tvaupo commented on GitHub (Feb 17, 2023):

Noticed the issue when playback is stopped for a while (5mins or more). I'm using 1.2x speed increase, downloaded book.

@tvaupo commented on GitHub (Feb 17, 2023): Noticed the issue when playback is stopped for a while (5mins or more). I'm using 1.2x speed increase, downloaded book.

adam commented

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

@mrburns-42 commented on GitHub (Feb 26, 2023):

Same problem here on iOS without Bluethooth, with and without AirPlay. It always happens to me with audiobooks that are downloaded and sometimes with audiobooks that I stream. I use Version 0.9.62.

@mrburns-42 commented on GitHub (Feb 26, 2023): Same problem here on iOS without Bluethooth, with and without AirPlay. It always happens to me with audiobooks that are downloaded and sometimes with audiobooks that I stream. I use Version 0.9.62.

adam commented

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

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

I think this is fixed for Android in the latest release 0.9.62-beta

Let me know if you can still reproduce this.

@advplyr commented on GitHub (Feb 26, 2023): I think this is fixed for Android in the latest release 0.9.62-beta Let me know if you can still reproduce this.

adam commented

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

@lkiesow commented on GitHub (Feb 27, 2023):

Still seems to happen sometimes with the latest release. With both streaming and downloaded books.

@lkiesow commented on GitHub (Feb 27, 2023): Still seems to happen sometimes with the latest release. With both streaming and downloaded books.

adam commented

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

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

Let me know if you can find reproducible steps. I'm not sure I've had this happen on the latest

@advplyr commented on GitHub (Feb 27, 2023): Let me know if you can find reproducible steps. I'm not sure I've had this happen on the latest

adam commented

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

@externl commented on GitHub (Mar 13, 2023):

This happens to me all the time on iOS as well. With both downloaded and streamed books. Not sure of a good way to reproduce it reliably, but it's still an issue.

@externl commented on GitHub (Mar 13, 2023): This happens to me all the time on iOS as well. With both downloaded and streamed books. Not sure of a good way to reproduce it reliably, but it's still an issue.

adam commented

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

@mrburns-42 commented on GitHub (Mar 13, 2023):

I also have the problem under iOS, use here the version 0.9.63. With me there is also no way to make this reproducible, it happens sometimes when I want to start an audiobook. However, not every time.

@mrburns-42 commented on GitHub (Mar 13, 2023): I also have the problem under iOS, use here the version 0.9.63. With me there is also no way to make this reproducible, it happens sometimes when I want to start an audiobook. However, not every time.

adam commented

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

@Mega-Volti commented on GitHub (Mar 23, 2023):

I just found this one and reading through it, it does sound very much like the one I opened recently: https://github.com/advplyr/audiobookshelf-app/issues/638

Might it be the same root cause? "Rounding errors" in the playback position would explain the weird jumps when seeking or pausing/resuming. Have you checked whether length of the audio file matters in your case?

@Mega-Volti commented on GitHub (Mar 23, 2023): I just found this one and reading through it, it does sound very much like the one I opened recently: https://github.com/advplyr/audiobookshelf-app/issues/638 Might it be the same root cause? "Rounding errors" in the playback position would explain the weird jumps when seeking or pausing/resuming. Have you checked whether length of the audio file matters in your case?

adam commented

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

@JakobTischler commented on GitHub (Mar 26, 2023):

I encountered this again, and I have a clue that might be connected.

I listened on the phone and paused.
I resumed on the desktop.
Tried to resume on phone, sync seems successful.
Phone still tries to play from its last save point.

@JakobTischler commented on GitHub (Mar 26, 2023): I encountered this again, and I have a clue that _might_ be connected. ![image](https://user-images.githubusercontent.com/748857/227779013-225672b8-a1c5-4f52-9fa8-60d8763693a2.png) 1. I listened on the phone and paused. 2. I resumed on the desktop. 3. Tried to resume on phone, sync seems successful. 4. Phone still tries to play from its last save point.

adam commented

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

@rightaditya commented on GitHub (Apr 27, 2023):

@JakobTischler nailed it, at least in terms of what I've experienced. I use both the web interface and the Android app (updated to 0.9.63 as per the Play Store) on a Pixel 7. The Web interface always resumes at the right spot, but the Android interface frequently (if not always) doesn't resume from the correct spot if I've listened to it in the meanwhile via the Web interface. Exactly as in @JakobTischler's screenshot, I see from the Android app that it syncs and sees the new time, but then the player resumes wherever it was originally paused from. Without looking at the code myself it kinda seems as though the player's timestamp isn't getting updated, even if the app is noting the the new timestamp somewhere else internally.

This is for a downloaded book. Not sure if this is relevant, but the Web interface shows me the "canonical" timestamp (i.e., according to the audiobook length when played at 1x) while the Android app shows me my "actual" timestamp (i.e., according to how much time has passed/is left for my listening to it at my usual 1.5x).

@rightaditya commented on GitHub (Apr 27, 2023): @JakobTischler nailed it, at least in terms of what I've experienced. I use both the web interface and the Android app (updated to 0.9.63 as per the Play Store) on a Pixel 7. The Web interface always resumes at the right spot, but the Android interface frequently (if not always) doesn't resume from the correct spot if I've listened to it in the meanwhile via the Web interface. Exactly as in @JakobTischler's screenshot, I see from the Android app that it syncs and sees the new time, but then the player resumes wherever it was originally paused from. Without looking at the code myself it kinda seems as though the player's timestamp isn't getting updated, even if the app is noting the the new timestamp somewhere else internally. This is for a downloaded book. Not sure if this is relevant, but the Web interface shows me the "canonical" timestamp (i.e., according to the audiobook length when played at 1x) while the Android app shows me my "actual" timestamp (i.e., according to how much time has passed/is left for my listening to it at my usual 1.5x).

adam commented

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

@Alistair1231 commented on GitHub (Jul 3, 2023):

The Web interface always resumes at the right spot, but the Android interface frequently (if not always) doesn't resume from the correct spot if I've listened to it in the meanwhile via the Web interface. Exactly as in @JakobTischler's screenshot, I see from the Android app that it syncs and sees the new time, but then the player resumes wherever it was originally paused from. Without looking at the code myself it kinda seems as though the player's timestamp isn't getting updated, even if the app is noting the the new timestamp somewhere else internally.

This is for a downloaded book. Not sure if this is relevant, but the

I have exactly this issue on v2.2.23 with docker and 0.9.65-beta. I am using downloaded book.

@Alistair1231 commented on GitHub (Jul 3, 2023): > The Web interface always resumes at the right spot, but the Android interface frequently (if not always) doesn't resume from the correct spot if I've listened to it in the meanwhile via the Web interface. Exactly as in @JakobTischler's screenshot, I see from the Android app that it syncs and sees the new time, but then the player resumes wherever it was originally paused from. Without looking at the code myself it kinda seems as though the player's timestamp isn't getting updated, even if the app is noting the the new timestamp somewhere else internally. > > This is for a downloaded book. Not sure if this is relevant, but the I have exactly this issue on v2.2.23 with docker and 0.9.65-beta. I am using downloaded book. ![image](https://github.com/advplyr/audiobookshelf-app/assets/26165288/a4509def-6c51-4741-b139-23009cb073fb) ![image](https://github.com/advplyr/audiobookshelf-app/assets/26165288/a9c15cca-85a1-4ef8-9b3a-b44b570fc34b) ![image](https://github.com/advplyr/audiobookshelf-app/assets/26165288/2f1e6c73-ccd1-46dc-bc58-7ff9e1fe3680)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/audiobookshelf-app#442