[Bug]: iOS: Frequently losing progress #1085

New Issue

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

adam commented

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

Originally created by @kylehendricks on GitHub (Nov 19, 2024).

What was the Problem?

I've been using audiobookshelf for about 6 months quite heavily. I often move between airpods and my car while listening to an audiobook. Fairly often I will pause, switch to airpods/car, hit play and nothing will happen. When I open the app on the phone I see a red toast error at the bottom (I will update with a screenshot once I see it again) and all of my recent progress is lost. This has happened probably 30 times since I've started using the app.

Steps to Reproduce the Issue

Sorry, this is not consistently reproducible.

Just today I noticed something interesting. Here's how my day went:

Listen in car on drive to work, paused with car button.
Put in airpods, clicked the airpod button to continue playing while walking from car to office.
Paused by clicking the airpod button.
Worked 8 hours without any listening.
Started walk back to car, put in airpods, hit airpod button to "resume" as I did not listen to any other media that day, it started playing the audiobook.
Once I got to my car, I knew this bug often happens at this point so I decided to open the app while the audiobook was playing and the app did not have the player visible at the bottom of the screen and the book I was listening to had a big play button even though the audiobook was currently playing. The iOS "media notification" was visible and accurate, as far as I could tell.
Paused with airpod button.
Got into car, all progress from my walk from the office to the car was lost.

What was Expected?

My progress would be saved as I switched between airpods and car.

Phone Model

iphone 15 Pro Max

Phone OS

iOS 18.1

Audiobookshelf App Version

iOS App - 0.9.77

Installation Source

Testflight

Additional Notes

This has happened on every iOS version I've been on for the last 6 months. (17 and 18?) It's also happened on every version of audiobookshelf since I've started using it.

Originally created by @kylehendricks on GitHub (Nov 19, 2024). ### What was the Problem? I've been using audiobookshelf for about 6 months quite heavily. I often move between airpods and my car while listening to an audiobook. Fairly often I will pause, switch to airpods/car, hit play and nothing will happen. When I open the app on the phone I see a red toast error at the bottom (I will update with a screenshot once I see it again) and all of my recent progress is lost. This has happened probably 30 times since I've started using the app. ### Steps to Reproduce the Issue Sorry, this is not consistently reproducible. Just today I noticed something interesting. Here's how my day went: 1. Listen in car on drive to work, paused with car button. 2. Put in airpods, clicked the airpod button to continue playing while walking from car to office. 3. Paused by clicking the airpod button. 4. Worked 8 hours without any listening. 5. Started walk back to car, put in airpods, hit airpod button to "resume" as I did not listen to any other media that day, it started playing the audiobook. 6. Once I got to my car, I knew this bug often happens at this point so I decided to open the app while the audiobook was playing and the app did not have the player visible at the bottom of the screen and the book I was listening to had a big play button even though the audiobook was currently playing. The iOS "media notification" was visible and accurate, as far as I could tell. 7. Paused with airpod button. 8. Got into car, all progress from my walk from the office to the car was lost. ### What was Expected? My progress would be saved as I switched between airpods and car. ### Phone Model iphone 15 Pro Max ### Phone OS iOS 18.1 ### Audiobookshelf App Version iOS App - 0.9.77 ### Installation Source Testflight ### Additional Notes This has happened on every iOS version I've been on for the last 6 months. (17 and 18?) It's also happened on every version of audiobookshelf since I've started using it.

adam added the bug iOS progress sync labels 2026-04-24 23:48:04 +02:00

adam closed this issue

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

adam commented

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

@SakerCobalt commented on GitHub (Nov 22, 2024):

This is also happening to me. Android 15.

Doesn't happen every time, but when I pause the app and the app is then closed, it doesn't always record the latest progress. So far if it does not save, it has reverted to the last save. Funny thing though, if I open the app, listen, pause, and then close the app, it will revert often. However, if I then reopen the app and try to reproduce the error right away, it seems to do the save correctly.

@SakerCobalt commented on GitHub (Nov 22, 2024): This is also happening to me. Android 15. Doesn't happen every time, but when I pause the app and the app is then closed, it doesn't always record the latest progress. So far if it does not save, it has reverted to the last save. Funny thing though, if I open the app, listen, pause, and then close the app, it will revert often. However, if I then reopen the app and try to reproduce the error right away, it seems to do the save correctly.

adam commented

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

@indiefan commented on GitHub (Nov 14, 2025):

I believe this is related to network switching and library disconnection/connection. It's frustratingly difficult to reproduce because I think the library connection status in the wild is triggered by memory pressure on backgrounded apps (or something similarly challenging to reproduce).

I've been casually trying to find a consistent repro for this for years without success, but I believe i have a synthetic set of steps that triggers the same issue on demand (hopefully it's not just some unrelated issue, but that's possible). It's very sensitive to doing these steps exactly (pausing, or navigating differently avoids reproduction).

Open ABS and start playing a book.
Return to the home screen.
Open the sidebar and select "Disconnect" (observe that the book is still playing with no controls)
Open the sidebar and select "connect to server" and select the right server.
Continue listening for a while (e.g. background the app, turn off the phone, observe the lock screen player is still playing and tracking), but don't pause.
Reopen ABS, select the book you're listening to (observe the option to play, even though the book is currently playing).
Press "Play" (observe the book reverts to the playback location it was at during step 3).

If you try other things (like play/pausing from the lock screen after 3/4) then you can observe the tracking temporarily revert to the timestamp triggered by 3 but immediately resolve/update to the current timestamp (thus avoiding losing progress). Or if you don't do 2, then you'll notice the player remains when you do 3 and when you do 4 the book stops playing. But in this case if you then press the play button from your headphones you will see the red error toast pop up (this series of steps reproduces the scenario where iOS believes there is an active session, but ABS is aware of the problem). Slightly better as there's no progress lost, but probably what's happening with #1613.

Now that I have a consistent repro case, I will look into finding the root cause and resolving it.

@indiefan commented on GitHub (Nov 14, 2025): I believe this is related to network switching and library disconnection/connection. It's frustratingly difficult to reproduce because I think the library connection status in the wild is triggered by memory pressure on backgrounded apps (or something similarly challenging to reproduce). I've been casually trying to find a consistent repro for this for years without success, but I believe i have a synthetic set of steps that triggers the same issue on demand (hopefully it's not just some unrelated issue, but that's possible). It's very sensitive to doing these steps exactly (pausing, or navigating differently avoids reproduction). 1. Open ABS and start playing a book. 2. Return to the home screen. 3. Open the sidebar and select "Disconnect" (observe that the book is still playing with no controls) 4. Open the sidebar and select "connect to server" and select the right server. 5. Continue listening for a while (e.g. background the app, turn off the phone, observe the lock screen player is still playing and tracking), but don't pause. 6. Reopen ABS, select the book you're listening to (observe the option to play, even though the book is currently playing). 7. Press "Play" (observe the book reverts to the playback location it was at during step 3). If you try other things (like play/pausing from the lock screen after 3/4) then you can observe the tracking temporarily revert to the timestamp triggered by 3 but immediately resolve/update to the current timestamp (thus avoiding losing progress). Or if you don't do 2, then you'll notice the player remains when you do 3 and when you do 4 the book stops playing. But in this case if you then press the play button from your headphones you will see the red error toast pop up (this series of steps reproduces the scenario where iOS believes there is an active session, but ABS is aware of the problem). Slightly better as there's no progress lost, but probably what's happening with #1613. Now that I have a consistent repro case, I will look into finding the root cause and resolving it.

adam commented

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

@indiefan commented on GitHub (Nov 15, 2025):

After more research into how the app works, I think the repro steps are somewhat valid here (though not the exact conditions encountered in the wild, due to the role that 'logout' specifically is playing in the steps above, they'll still likely be helpful in testing a robust fix).

The bottom line is that the Vue layer (in-app player controls) and the native audio player layer are separate and can become disassociated. For a lot of flows (where they aren't fully disassociated), connectivity changes resolve fine because the native player writes state to the local db (realm) and much of the socket lifecycle handling merges in this state appropriately. Even when they become disassociated, there are some flows where we don't lose progress (because the native player writes to the local db and depending on the flow that might get accounted for in resumption).

However, it is still possible (like in the scenario above) that reconciliation loses progress.

At a high level my proposed fix here is to query for and prioritize native player state over other signals at a few key interactions (e.g. on app resume, on socket connect, etc.).

Lastly, i'm curious about this line of code: https://github.com/advplyr/audiobookshelf-app/blob/072f19e15718ce76205a8ef69fa60c7d04fa372f/components/app/AudioPlayer.vue#L553

It's not clear to me if there are expected flows that would hit this, or if getting here is a solid signal that our native playback has become disassociated with the Vue layer.

@advplyr thoughts?

@indiefan commented on GitHub (Nov 15, 2025): After more research into how the app works, I think the repro steps are somewhat valid here (though not the exact conditions encountered in the wild, due to the role that 'logout' specifically is playing in the steps above, they'll still likely be helpful in testing a robust fix). The bottom line is that the Vue layer (in-app player controls) and the native audio player layer are separate and can become disassociated. For a lot of flows (where they aren't fully disassociated), connectivity changes resolve fine because the native player writes state to the local db (realm) and much of the socket lifecycle handling merges in this state appropriately. Even when they become disassociated, there are some flows where we don't lose progress (because the native player writes to the local db and depending on the flow that might get accounted for in resumption). However, it is still possible (like in the scenario above) that reconciliation loses progress. At a high level my proposed fix here is to query for and prioritize native player state over other signals at a few key interactions (e.g. on app resume, on socket connect, etc.). Lastly, i'm curious about this line of code: https://github.com/advplyr/audiobookshelf-app/blob/072f19e15718ce76205a8ef69fa60c7d04fa372f/components/app/AudioPlayer.vue#L553 It's not clear to me if there are expected flows that would hit this, or if getting here is a solid signal that our native playback has become disassociated with the Vue layer. @advplyr thoughts?

adam commented

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

@advplyr commented on GitHub (Nov 23, 2025):

Thanks for the reproducible steps with pressing disconnect. I was able to fix that by refreshing the home page when the user changes instead of reloading the page. Also, I implemented closing the player if you disconnect and are not playing a local download.

I think the issue with the capacitor audio player being out of sync with the native audio happens when the device kills webview.

At a high level my proposed fix here is to query for and prioritize native player state over other signals at a few key interactions (e.g. on app resume, on socket connect, etc.).

There shouldn't be any other times this happens while the app is open besides that disconnect bug. If there is we should fix that in the app. We should only need to implement the check when the Vue default layout gets mounted.

I don't know how to reproduce the device killing webview in the background. The disconnect bug will be a good way to force the capacitor audio player out of sync. Even though I'm patching it in this next release, it is easily reproduce by calling location.reload() while the audio player is open.

@advplyr commented on GitHub (Nov 23, 2025): Thanks for the reproducible steps with pressing disconnect. I was able to fix that by refreshing the home page when the user changes instead of reloading the page. Also, I implemented closing the player if you disconnect and are not playing a local download. I think the issue with the capacitor audio player being out of sync with the native audio happens when the device kills webview. > At a high level my proposed fix here is to query for and prioritize native player state over other signals at a few key interactions (e.g. on app resume, on socket connect, etc.). There shouldn't be any other times this happens while the app is open besides that disconnect bug. If there is we should fix that in the app. We should only need to implement the check when the Vue default layout gets mounted. I don't know how to reproduce the device killing webview in the background. The disconnect bug will be a good way to force the capacitor audio player out of sync. Even though I'm patching it in this next release, it is easily reproduce by calling `location.reload()` while the audio player is open.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/audiobookshelf-app#1085