[Bug]: Listening position / time sync not working correctly with Android Auto #382

New Issue

2026-04-24T23:18:54+02:00

adam commented

2026-04-24 23:18:54 +02:00

Originally created by @Mega-Volti on GitHub (Jan 3, 2023).

Describe the issue

Frequently, when I listed to any audiobook in my car, the playback will resume as if the latest listening session had not happened. E.g. I listened for 20 minutes, paused, continued the next day and it'd resume on the older position, 20 minutes too early, repeating the content.

Additionally, when using the forward/backward buttons for the first time within the Android Auto interface, playback will often jump to a seemingly random position several minutes away from the current playback position, usually in the future. When rewinding to the correct position and using the forward/backward buttons, it correctly moves 10 seconds forward backwards.

My best guess is that the playback position is not saved correctly and the Android client thinks it's in a different position than it actually is. And it only syncs it correctly after manual button use. But as the time jumps have been rather random, I was not able to pinpoint this exactly.

Having a strong or weak internet connection does not seem to make a difference. At the very end of every listening session my internet connection is excellent (joining my home wireless network) and I still get listening position sync issues.

So far, I have only observed the issue with audiobooks that are also saved locally on the Android phone using the local download option within the Audiobookshelf app. However, since I use this functionality for all audiobooks I listed to, I'm not sure whether it is limited to downlaoded audiobook or might also occur when streaming.

This behavior occured for several different audiobooks, audiobook format does not seem to be relevant. It also has occured ever since I started using Audiobookshelf a few months ago.

Steps to reproduce the issue

Download audiobook to Android device
Connect Android Auto
Play audiobook for extended time
Disconnect Android auto and play audiobook on other sources
Play on Android Auto again
Listening positions will usually be noticably out of sync
Using the forward or backward button will usually jump to a wrong listening position as well

Audiobookshelf version

Audiobookshelf v2.2.11, Android app v0.9.60

How are you running audiobookshelf?

Docker

Originally created by @Mega-Volti on GitHub (Jan 3, 2023). ### Describe the issue Frequently, when I listed to any audiobook in my car, the playback will resume as if the latest listening session had not happened. E.g. I listened for 20 minutes, paused, continued the next day and it'd resume on the older position, 20 minutes too early, repeating the content. Additionally, when using the forward/backward buttons for the first time within the Android Auto interface, playback will often jump to a seemingly random position several minutes away from the current playback position, usually in the future. When rewinding to the correct position and using the forward/backward buttons, it correctly moves 10 seconds forward backwards. My best guess is that the playback position is not saved correctly and the Android client thinks it's in a different position than it actually is. And it only syncs it correctly after manual button use. But as the time jumps have been rather random, I was not able to pinpoint this exactly. Having a strong or weak internet connection does not seem to make a difference. At the very end of every listening session my internet connection is excellent (joining my home wireless network) and I still get listening position sync issues. So far, I have only observed the issue with audiobooks that are also saved locally on the Android phone using the local download option within the Audiobookshelf app. However, since I use this functionality for all audiobooks I listed to, I'm not sure whether it is limited to downlaoded audiobook or might also occur when streaming. This behavior occured for several different audiobooks, audiobook format does not seem to be relevant. It also has occured ever since I started using Audiobookshelf a few months ago. ### Steps to reproduce the issue 1. Download audiobook to Android device 2. Connect Android Auto 3. Play audiobook for extended time 4. Disconnect Android auto and play audiobook on other sources 5. Play on Android Auto again 7. Listening positions will usually be noticably out of sync 8. Using the forward or backward button will usually jump to a wrong listening position as well ### Audiobookshelf version Audiobookshelf v2.2.11, Android app v0.9.60 ### How are you running audiobookshelf? Docker

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

adam closed this issue

2026-04-24 23:18:55 +02:00

adam commented

2026-04-24 23:18:56 +02:00

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

When you disconnect android auto the next time after listening can you check using the website client if your server has the correct progress?

I'm wondering if Android Auto is jumping back because the progress stored on the server never got updated, or if your local progress was not updated.

I also think this may be a duplicate issue I just didn't search yet. I know it has been mentioned in the Discord.

@advplyr commented on GitHub (Jan 3, 2023): When you disconnect android auto the next time after listening can you check using the website client if your server has the correct progress? I'm wondering if Android Auto is jumping back because the progress stored on the server never got updated, or if your local progress was not updated. I also think this may be a duplicate issue I just didn't search yet. I know it has been mentioned in the Discord.

adam commented

2026-04-24 23:18:57 +02:00

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

There was another report that when opening Android Auto without first opening the mobile app on your device then you will only see the "Downloads" tab.
Can you check if that is the case for you when you are listening? This would show that Android Auto without the mobile app open first is never connecting to the server.

@advplyr commented on GitHub (Jan 3, 2023): There was another report that when opening Android Auto without first opening the mobile app on your device then you will only see the "Downloads" tab. Can you check if that is the case for you when you are listening? This would show that Android Auto without the mobile app open first is never connecting to the server.

adam commented

2026-04-24 23:18:57 +02:00

@Mega-Volti commented on GitHub (Jan 3, 2023):

I did use the search within open issues and couldn't find any that match the behavior I observed, but I might of course have missed something or used the wrong seach teams. Sorry if that was the case. I didn't check the Discord yet.

I forgot to mention earlier: I have also observed that occasionally, when connecting Android Auto or the web client, the listening position does get displayed correctly (e.g. set to 6:20) but when I actually hit the play button, it starts playing at a completely different position (e.g. it jumps to 5:47 and plays from there). This happened when using Android Auto, I'm not quite sure whether it also happend within the app after disconnecting Android Auto.

I just went to the car and checked regarding the "Downloads" tab: I quit out of the Audiobooshelf app and closed the background task in the Android UI, connected Android Auto and in the library menu I could still see all my audiobooks, it was not limited to just downloads. Which I think does confirm that Android Auto indeed does connect to the server. I also opened Android Auto with Audiobookshelf open on the phone and it showed the very same selection, no difference.

I listened to about two minutes of an audiobook, disconnected Android Auto, but when listening on the Audiobookshelf app itself, after disconnecting Android Auto, I had not saved the latest listening position but instead started playback 2 minutes earlier, from the old position. The web app started from the correct position afterwards, but I did go back and forth within the Android app a bit to pinpoint play positions, so I'm not sure whether the sync to the server occured during Android Auto usage or during phone app usage.

It might also be that Android Auto syncs to the server correctly, but the native Android app keeps its play status in some sort of cache and might "miss" the parts played while Android Auto is active?

@Mega-Volti commented on GitHub (Jan 3, 2023): I did use the search within open issues and couldn't find any that match the behavior I observed, but I might of course have missed something or used the wrong seach teams. Sorry if that was the case. I didn't check the Discord yet. I forgot to mention earlier: I have also observed that occasionally, when connecting Android Auto or the web client, the listening position does get displayed correctly (e.g. set to 6:20) but when I actually hit the play button, it starts playing at a completely different position (e.g. it jumps to 5:47 and plays from there). This happened when using Android Auto, I'm not quite sure whether it also happend within the app after disconnecting Android Auto. I just went to the car and checked regarding the "Downloads" tab: I quit out of the Audiobooshelf app and closed the background task in the Android UI, connected Android Auto and in the library menu I could still see all my audiobooks, it was not limited to just downloads. Which I think does confirm that Android Auto indeed does connect to the server. I also opened Android Auto with Audiobookshelf open on the phone and it showed the very same selection, no difference. I listened to about two minutes of an audiobook, disconnected Android Auto, but when listening on the Audiobookshelf app itself, after disconnecting Android Auto, I had not saved the latest listening position but instead started playback 2 minutes earlier, from the old position. The web app started from the correct position afterwards, but I did go back and forth within the Android app a bit to pinpoint play positions, so I'm not sure whether the sync to the server occured during Android Auto usage or during phone app usage. It might also be that Android Auto syncs to the server correctly, but the native Android app keeps its play status in some sort of cache and might "miss" the parts played while Android Auto is active?

adam commented

2026-04-24 23:18:57 +02:00

@tknorris commented on GitHub (Jan 3, 2023):

This issue sounds similar to the one I reported using just the plain android app: https://github.com/advplyr/audiobookshelf-app/issues/487

@tknorris commented on GitHub (Jan 3, 2023): This issue sounds similar to the one I reported using just the plain android app: https://github.com/advplyr/audiobookshelf-app/issues/487

adam commented

2026-04-24 23:18:58 +02:00

@Mega-Volti commented on GitHub (Jan 4, 2023):

Quick update:

I checked twice now and the behaviour seems consistent: When I listed using Android Auto, at the end of my session, the play position is correctly shown within the Android Auto interface. The app also shows on the phone and it does show the correct time there. But as soon as I disconnect Android Auto (I'm using it via USB cable, so as soon as I pull the cable) the listening position within the app jumps to the "old" value, the position it had before using Android Auto.

@Mega-Volti commented on GitHub (Jan 4, 2023): Quick update: I checked twice now and the behaviour seems consistent: When I listed using Android Auto, at the end of my session, the play position is correctly shown within the Android Auto interface. The app also shows on the phone and it does show the correct time there. But as soon as I disconnect Android Auto (I'm using it via USB cable, so as soon as I pull the cable) the listening position within the app jumps to the "old" value, the position it had before using Android Auto.

adam commented

2026-04-24 23:18:58 +02:00

@Mega-Volti commented on GitHub (Jan 7, 2023):

And another update, it's worse than I initially thought:

Even when not using Android Auto, I did observe the same behaviour simply while using the Android app.

And now while using only the web interface, using the 10 second forward/backward button after listening for a while did jump to a position minutes away from where it should be.

This happend with an audiobook that had a single huge mp3 file with about 14 hours playtime. It might be some sort of rounding error, at least for the web interface issue, since the jump is just a few minutes off. Either way, something is seriously buggy with the listenting position, to a point where using Audiobookshelf does become really cumbersome.

@Mega-Volti commented on GitHub (Jan 7, 2023): And another update, it's worse than I initially thought: Even when not using Android Auto, I did observe the same behaviour simply while using the Android app. And now while using only the web interface, using the 10 second forward/backward button after listening for a while did jump to a position minutes away from where it should be. This happend with an audiobook that had a single huge mp3 file with about 14 hours playtime. It might be some sort of rounding error, at least for the web interface issue, since the jump is just a few minutes off. Either way, something is seriously buggy with the listenting position, to a point where using Audiobookshelf does become really cumbersome.

adam commented

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

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

That sounds more like you have badly encoded audio file.

@advplyr commented on GitHub (Jan 7, 2023): That sounds more like you have badly encoded audio file.

adam commented

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

@Mega-Volti commented on GitHub (Jan 7, 2023):

Then every use of the forward/backward button would result in random jumps, right? It was only the first use after listening for some time, subsequent uses did move the position back and forward exactly 10 seconds (the interval I have set) as expected. If the file was badly encoded, this wouldn't have worked, right?

Some issue with the positional sync seems more likely. But this might not be connected to the Android Auto issue at all, since this only did jump a few minutes, while the Android Auto issue seems to be "forgetting" whole listening sessions.

@Mega-Volti commented on GitHub (Jan 7, 2023): Then every use of the forward/backward button would result in random jumps, right? It was only the first use after listening for some time, subsequent uses did move the position back and forward exactly 10 seconds (the interval I have set) as expected. If the file was badly encoded, this wouldn't have worked, right? Some issue with the positional sync seems more likely. But this might not be connected to the Android Auto issue at all, since this only did jump a few minutes, while the Android Auto issue seems to be "forgetting" whole listening sessions.

adam commented

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

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

Related #462 and #402

Just fixed #385 for the next release. When playing a downloaded item from any tab other then "Downloads" it was streaming from the server instead of playing the local copy. In the next release the local copy will always be played if it is available.

In situations where connection to server is intermittent this could have caused issues with the sync. From reading through all the comments there are likely more than one bug around progress.

I haven't yet reproduced any of the progress sync issues mentioned though which makes it impossible to verify.

@advplyr commented on GitHub (Jan 9, 2023): Related #462 and #402 Just fixed #385 for the next release. When playing a downloaded item from any tab other then "Downloads" it was streaming from the server instead of playing the local copy. In the next release the local copy will always be played if it is available. In situations where connection to server is intermittent this could have caused issues with the sync. From reading through all the comments there are likely more than one bug around progress. I haven't yet reproduced any of the progress sync issues mentioned though which makes it impossible to verify.

adam commented

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

@mjtimblin commented on GitHub (Jan 9, 2023):

Thanks @advplyr for actively looking into the bug! I've experienced the issue as well, so I thought I'd add the steps I've taken here in case it helps.

Download audiobook using the audiobookshelf app
Plug phone into car (2022 Mazda 3), and open audiobookshelf app using the car's infotainment system
Start or resume playback of the downloaded audiobook
After listening for some time, pause playback using the car's media buttons
Wait 30 seconds to ensure playback has synced (have tried while connected to WiFi and also with a strong 5G signal)
Unplug phone from car
Restart car
Plug phone into car, and open audiobookshelf app using the car's infotainment system
Continue playback of the same audiobook

Progress is never saved in step 5. When continuing playback in step 9, the audiobook resumes from the progress saved prior to the Android Auto listening session (progress at step 3). The only way I have been able to save progress while listening with Android Auto is by opening the audiobookshelf app on my phone while currently listening to an audiobook, waiting a moment for the playback progress bar to update with the car's current playback, and pausing the playback using the phone instead of the car's controls. Then I can disconnect my phone from my car.

@mjtimblin commented on GitHub (Jan 9, 2023): Thanks @advplyr for actively looking into the bug! I've experienced the issue as well, so I thought I'd add the steps I've taken here in case it helps. 1. Download audiobook using the audiobookshelf app 2. Plug phone into car (2022 Mazda 3), and open audiobookshelf app using the car's infotainment system 3. Start or resume playback of the downloaded audiobook 4. After listening for some time, pause playback using the car's media buttons 5. Wait 30 seconds to ensure playback has synced (have tried while connected to WiFi and also with a strong 5G signal) 6. Unplug phone from car 7. Restart car 8. Plug phone into car, and open audiobookshelf app using the car's infotainment system 9. Continue playback of the same audiobook Progress is never saved in step 5. When continuing playback in step 9, the audiobook resumes from the progress saved prior to the Android Auto listening session (progress at step 3). The only way I have been able to save progress while listening with Android Auto is by opening the audiobookshelf app on my phone while currently listening to an audiobook, waiting a moment for the playback progress bar to update with the car's current playback, and pausing the playback using the phone instead of the car's controls. Then I can disconnect my phone from my car.

adam commented

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

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

@mjtimblin Thanks for the steps. On step 3 when you are playing the downloaded book are you playing that book from the "Downloads" tab? In the current version it is important what tab you are playing the book from.

@advplyr commented on GitHub (Jan 9, 2023): @mjtimblin Thanks for the steps. On step 3 when you are playing the downloaded book are you playing that book from the "Downloads" tab? In the current version it is important what tab you are playing the book from.

adam commented

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

@mjtimblin commented on GitHub (Jan 11, 2023):

@advplyr I've tried, unsuccessfully, to replicate my issue the past two evenings on my way home from work. I can tell you from memory that most of the time over the past couple of weeks, I would start the book using my phone instead of using the Android Auto interface. Since the playback time was frequently off, I would prefer to start the playback using the app so that I could use the timeline to adjust the time quickly. When I would use the Android Auto interface to start playback, I would normally use the "Listening" tab to resume an already started audiobook.

I doubt it's related, but I did make a couple of server changes a couple of days ago and haven't had this bug since. Those changes were upgrading the server from v2.2.11 to v2.2.12 and disabling the "Store covers with item" setting. The "Store covers with item" setting was enabled and was causing issues where attempts to update book covers would result in 502 error responses due to improper folder permissions in my audiobooks directory.

@mjtimblin commented on GitHub (Jan 11, 2023): @advplyr I've tried, unsuccessfully, to replicate my issue the past two evenings on my way home from work. I can tell you from memory that most of the time over the past couple of weeks, I would start the book using my phone instead of using the Android Auto interface. Since the playback time was frequently off, I would prefer to start the playback using the app so that I could use the timeline to adjust the time quickly. When I would use the Android Auto interface to start playback, I would normally use the "Listening" tab to resume an already started audiobook. I doubt it's related, but I did make a couple of server changes a couple of days ago and haven't had this bug since. Those changes were upgrading the server from v2.2.11 to v2.2.12 and disabling the "Store covers with item" setting. The "Store covers with item" setting was enabled and was causing issues where attempts to update book covers would result in 502 error responses due to improper folder permissions in my audiobooks directory.

adam commented

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

@Mega-Volti commented on GitHub (Jan 12, 2023):

For me, these did happen when playing from the regular library. I have not tried playing from the downloads tab so far.

@Mega-Volti commented on GitHub (Jan 12, 2023): For me, these did happen when playing from the regular library. I have not tried playing from the downloads tab so far.

adam commented

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

@Borlean commented on GitHub (Feb 10, 2023):

I have also observed that occasionally, when connecting Android Auto or the web client, the listening position does get displayed correctly (e.g. set to 6:20) but when I actually hit the play button, it starts playing at a completely different position (e.g. it jumps to 5:47 and plays from there). This happened when using Android Auto, I'm not quite sure whether it also happend within the app after disconnecting Android Auto.

The same issue has been happening with me, most recently with Podcasts that were downloaded with Audiobookshelf. I did not "Download" the files to my phone, I was streaming them directly from the server. Sometimes the infotainment in my care will show the correct time when Audiobookshelf is opened, but when I click play, it backs up to a prior position. Most recently happened on ABS v2.2.14 on the server and 0.9.61-beta on my android phone. Hope this helps.

@Borlean commented on GitHub (Feb 10, 2023): > I have also observed that occasionally, when connecting Android Auto or the web client, the listening position does get displayed correctly (e.g. set to 6:20) but when I actually hit the play button, it starts playing at a completely different position (e.g. it jumps to 5:47 and plays from there). This happened when using Android Auto, I'm not quite sure whether it also happend within the app after disconnecting Android Auto. The same issue has been happening with me, most recently with Podcasts that were downloaded with Audiobookshelf. I did not "Download" the files to my phone, I was streaming them directly from the server. Sometimes the infotainment in my care will show the correct time when Audiobookshelf is opened, but when I click play, it backs up to a prior position. Most recently happened on ABS v2.2.14 on the server and 0.9.61-beta on my android phone. Hope this helps.

adam commented

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

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

Can you test again on the latest server v2.2.15 and app 0.9.62-beta?

@advplyr commented on GitHub (Feb 26, 2023): Can you test again on the latest server `v2.2.15` and app `0.9.62-beta`?

adam commented

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

@Mega-Volti commented on GitHub (Feb 27, 2023):

I did the test and it's working now, even though in a weird way:

When disconnecting Android Auto, the app still shows the wrong play position.
When actually starting playback, it starts playing for a split second (something, couldn't tell whether it was the right position or not because the time was too short).
Then jumps to the correct play position and starts playing from there.

So far I have only tested playing from the app that was already running, after disconnecting Android Auto. I didn't have the time yet to try other methods (e.g. play from the lock screen, force-close the app and restart etc.), will update here in case any of these don't work as expected.

I'm not sure whether this counts as fixed or not, since the behaviour is still a bit weird, but it's definitely fine to use now.

@Mega-Volti commented on GitHub (Feb 27, 2023): I did the test and it's working now, even though in a weird way: - When disconnecting Android Auto, the app still shows the wrong play position. - When actually starting playback, it starts playing for a split second (something, couldn't tell whether it was the right position or not because the time was too short). - Then jumps to the correct play position and starts playing from there. So far I have only tested playing from the app that was already running, after disconnecting Android Auto. I didn't have the time yet to try other methods (e.g. play from the lock screen, force-close the app and restart etc.), will update here in case any of these don't work as expected. I'm not sure whether this counts as fixed or not, since the behaviour is still a bit weird, but it's definitely fine to use now.

adam commented

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

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

I used it a bit more the last few days and the behaviour described above seems to be stable / reproducable, I haven't observed any other behaviour so far.

@Mega-Volti commented on GitHub (Mar 3, 2023): I used it a bit more the last few days and the behaviour described above seems to be stable / reproducable, I haven't observed any other behaviour so far.

adam commented

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

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

And another update:

As long as I use only the Android app, switching between Android Auto and playback on the app works fine. no issues with the playback position.

But when playing via the web interface and then switching to the Android app, the playback position is still not always correct. E.g., starting an audiobook via web interface and listening to it for half an hour (which works fine there, even when split into multiple sessions, playback is resumed correctly each time). Then opening then Android app, hitting play on the audiobook - the book will start form the very beginning, ignoring the half hour play session(s) already had on the web app.

@Mega-Volti commented on GitHub (Mar 4, 2023): And another update: As long as I use only the Android app, switching between Android Auto and playback on the app works fine. no issues with the playback position. But when playing via the web interface and then switching to the Android app, the playback position is still not always correct. E.g., starting an audiobook via web interface and listening to it for half an hour (which works fine there, even when split into multiple sessions, playback is resumed correctly each time). Then opening then Android app, hitting play on the audiobook - the book will start form the very beginning, ignoring the half hour play session(s) already had on the web app.

adam commented

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

@advplyr commented on GitHub (Mar 6, 2023):

@Mega-Volti Are you using 0.9.62-beta for that test?

@advplyr commented on GitHub (Mar 6, 2023): @Mega-Volti Are you using 0.9.62-beta for that test?

adam commented

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

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

Yes I am, just double-checked.

I also just obseved some extremely odd behaviour, there is definitely still something going seriously wrong with Android Auto (and local books). It's a bit complicated, though:

Two books, let's just call them book A and book B.
I had listened to A a while already, playback position was 09:51 (hours:minutes, don't recall the seconds), all good.
I had a buddy with me in the car and instead of continuing book A, we decided to start together with a new book - book B. starting listening position 00:00 since it's a new one.
I selected it from the local books via Android Auto, we listened for about 5 minutes, so to 00:05. Then we decided to have a quick stop and turned off the book. A bit later, I started it again the same way - but it started from 00:00 again, the local playback was never synced for some reason.
No big deal, it was just a few minutes, we fast-forwarded and continued the drive, till around listening position 00:53.
I park the car, disconnect Android Auto, go home, open the Audiobookshelf app (still on the phone).
Browsing the "home" section I do see book A in the "continue" row, but not book B.
I do see book B at the bottom of the screen, I can continue playback with it. I do and book B plays normally. Even then, it doesn't show up in the "continue" section.
Everything is synced, I am home and have wifi, the cloud icon is green.
I exit the app and start it up again. Book B still does not appear in the "continue" section. But book A does, now with playback position 00:53 saved! Instead of the 09:51 it should have, because Book A didn't get touched at all in the meantime.

So for some reason, after playing book B from the local storage on Android Auto, and switching back to the app, the playback position from book A (the book previously played in the app, without Android Auto) got overwritten by the playback position from book B (which started playing via Android Auto).

Sorry if it's too detailed, maybe I could trim things a little, but it's weird and probably too complex to reproduce (or it would need very extensive testing since multiple books are involed) so I figured it's better to give as much detail as possible. Hope it helps.

@Mega-Volti commented on GitHub (Mar 7, 2023): Yes I am, just double-checked. I also just obseved some extremely odd behaviour, there is definitely still something going seriously wrong with Android Auto (and local books). It's a bit complicated, though: Two books, let's just call them book A and book B. I had listened to A a while already, playback position was 09:51 (hours:minutes, don't recall the seconds), all good. I had a buddy with me in the car and instead of continuing book A, we decided to start together with a new book - book B. starting listening position 00:00 since it's a new one. I selected it from the local books via Android Auto, we listened for about 5 minutes, so to 00:05. Then we decided to have a quick stop and turned off the book. A bit later, I started it again the same way - but it started from 00:00 again, the local playback was never synced for some reason. No big deal, it was just a few minutes, we fast-forwarded and continued the drive, till around listening position 00:53. I park the car, disconnect Android Auto, go home, open the Audiobookshelf app (still on the phone). Browsing the "home" section I do see book A in the "continue" row, but not book B. I do see book B at the bottom of the screen, I can continue playback with it. I do and book B plays normally. Even then, it doesn't show up in the "continue" section. Everything is synced, I am home and have wifi, the cloud icon is green. I exit the app and start it up again. Book B still does not appear in the "continue" section. But book A does, now with playback position 00:53 saved! Instead of the 09:51 it should have, because Book A didn't get touched at all in the meantime. So for some reason, after playing book B from the local storage on Android Auto, and switching back to the app, the playback position from book A (the book previously played in the app, without Android Auto) got overwritten by the playback position from book B (which started playing via Android Auto). Sorry if it's too detailed, maybe I could trim things a little, but it's weird and probably too complex to reproduce (or it would need very extensive testing since multiple books are involed) so I figured it's better to give as much detail as possible. Hope it helps.

adam commented

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

@advplyr commented on GitHub (Mar 10, 2023):

Playback history for audiobooks was added and another fix for that included in 0.9.63. Viewing the playback history can help debug these issues because it shows the timestamp of each play/pause and syncs.

@advplyr commented on GitHub (Mar 10, 2023): Playback history for audiobooks was added and another fix for that included in 0.9.63. Viewing the playback history can help debug these issues because it shows the timestamp of each play/pause and syncs.

adam commented

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

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

I did another test with the Android app version 0.9.63.

Same result: Listening to audiobook A in Android Auto, then listening to a different audiobook B in the app, then listening to audiobook A via the web interface, results in the playback positon of audiobook A wrongly being set to what the actual playback position of audiobook B was. Playing audiobook B in the web interface, it seems to have "forgotten" its last play session.

Meaning that the play session of audiobook B gets wrongly attributed to audiobook A, which messes up the playback positions.

I have also extensively tried listening to only a single audiobook and switching between Android Auto and the app and I have observed no issues with playback positions in that case. As long as only a single audiobook is played, switching seems to work fine. But as soon as two are played, things get messed up.

@Mega-Volti commented on GitHub (Mar 16, 2023): I did another test with the Android app version 0.9.63. Same result: Listening to audiobook A in Android Auto, then listening to a different audiobook B in the app, then listening to audiobook A via the web interface, results in the playback positon of audiobook A wrongly being set to what the actual playback position of audiobook B was. Playing audiobook B in the web interface, it seems to have "forgotten" its last play session. Meaning that the play session of audiobook B gets wrongly attributed to audiobook A, which messes up the playback positions. I have also extensively tried listening to only a single audiobook and switching between Android Auto and the app and I have observed no issues with playback positions in that case. As long as only a single audiobook is played, switching seems to work fine. But as soon as two are played, things get messed up.

adam commented

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

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

Found an issue even with only a single audiobook involved:

Play book locally with Android Auto
Confirm Android app is synced
Play book using the web interface
Confirm Android app is synced
Play book again locally with Android Auto

Android Auto resumes from the last playback position that it had when it finished step 1, ignoring progress made during step 3.

@Mega-Volti commented on GitHub (Mar 19, 2023): Found an issue even with only a single audiobook involved: 1. Play book locally with Android Auto 2. Confirm Android app is synced 3. Play book using the web interface 4. Confirm Android app is synced 5. Play book again locally with Android Auto Android Auto resumes from the last playback position that it had when it finished step 1, ignoring progress made during step 3.

adam commented

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

@mjtimblin commented on GitHub (Mar 20, 2023):

I have had this same experience consistently. As long as I am using just my phone and Android Auto, progress is synced perfectly. However, the Android app always ignores progress I've made using the web interface.

Android app: v0.9.63-beta (Google Play Store version on Samsung Galaxy S21)
Server: v2.2.16 (Debian package on Ubuntu 20.04)

Found an issue even with only a single audiobook involved:
1. Play book locally with Android Auto

2. Confirm Android app is synced

3. Play book using the web interface

4. Confirm Android app is synced

5. Play book again locally with Android Auto
Android Auto resumes from the last playback position that it had when it finished step 1, ignoring progress made during step 3.

@mjtimblin commented on GitHub (Mar 20, 2023): I have had this same experience consistently. As long as I am using just my phone and Android Auto, progress is synced perfectly. However, the Android app always ignores progress I've made using the web interface. Android app: `v0.9.63-beta` (Google Play Store version on Samsung Galaxy S21) Server: `v2.2.16` (Debian package on Ubuntu 20.04) > Found an issue even with only a single audiobook involved: > > 1. Play book locally with Android Auto > > 2. Confirm Android app is synced > > 3. Play book using the web interface > > 4. Confirm Android app is synced > > 5. Play book again locally with Android Auto > > > Android Auto resumes from the last playback position that it had when it finished step 1, ignoring progress made during step 3.

adam commented

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

@Mega-Volti commented on GitHub (Apr 1, 2023):

I might have found the cause at least: In another bug report it was mentioned that Audibookshelf can only handle one stream at a time. Using the web interface, closing it seems to close the stream properly. Using the Android app, closing it doesn't seem to reliably do that, only using the "close player" button (it's a bit hidden) seems to do that.

So switching between the app and the web interface, while the stream within the app never closes properly, seems to confuse the server.

Possible solutions: Auto-close the stream after a bit of a delay or at least re-check whether the open stream really is the "primary" one on resume.

@Mega-Volti commented on GitHub (Apr 1, 2023): I might have found the cause at least: In another bug report it was mentioned that Audibookshelf can only handle one stream at a time. Using the web interface, closing it seems to close the stream properly. Using the Android app, closing it doesn't seem to reliably do that, only using the "close player" button (it's a bit hidden) seems to do that. So switching between the app and the web interface, while the stream within the app never closes properly, seems to confuse the server. Possible solutions: Auto-close the stream after a bit of a delay or at least re-check whether the open stream really is the "primary" one on resume.

adam commented

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

@Mega-Volti commented on GitHub (Apr 13, 2023):

This is still happening and on top of it, the Android app in general seems to ignore listening sessions via the web interface.

To reproduce:

Listen to book in Android app
Close player in Android app and make sure everything is synced
Continue listening via web interface
Close web interface and make sure everything is synced with the Android app
Even restart the Android app and check everything is synced again
Playback position within the Android app will still ignore the listening session via the web interface

@Mega-Volti commented on GitHub (Apr 13, 2023): This is still happening and on top of it, the Android app in general seems to ignore listening sessions via the web interface. To reproduce: 1. Listen to book in Android app 2. Close player in Android app and make sure everything is synced 3. Continue listening via web interface 4. Close web interface and make sure everything is synced with the Android app 5. Even restart the Android app and check everything is synced again 6. Playback position within the Android app will still ignore the listening session via the web interface

adam commented

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

@advplyr commented on GitHub (Dec 14, 2023):

A bunch of updates were made to progress syncing since this issue. Particularly v0.9.66
Is this still an issue?

@advplyr commented on GitHub (Dec 14, 2023): A bunch of updates were made to progress syncing since this issue. Particularly v0.9.66 Is this still an issue?

adam commented

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

@Mega-Volti commented on GitHub (Dec 15, 2023):

A bunch of updates were made to progress syncing since this issue. Particularly v0.9.66 Is this still an issue?

Happy to say: Haven't noticed any issues for a long while now, everything working perfectly in terms of sync!

One minor issue I ran into in the meantime: Mp3 playback will randomly crash on Android when playing local books. I assume that it has nothing to do with ABS itself, but with the mp3 backend used for Android playback. No crashes when streaming. Crashes occur in random intervals and at random positions. Crashes during mp3 file transitions seem more likely than mid-file, but either occur. Simply resuming playback will continue the book - until the next crash. Frequency varies randomly and between books - some books seem to crash every 5-30 minutes, others barely ever (every few hours or so).

@Mega-Volti commented on GitHub (Dec 15, 2023): > A bunch of updates were made to progress syncing since this issue. Particularly v0.9.66 Is this still an issue? Happy to say: Haven't noticed any issues for a long while now, everything working perfectly in terms of sync! One minor issue I ran into in the meantime: Mp3 playback will randomly crash on Android when playing local books. I assume that it has nothing to do with ABS itself, but with the mp3 backend used for Android playback. No crashes when streaming. Crashes occur in random intervals and at random positions. Crashes during mp3 file transitions seem more likely than mid-file, but either occur. Simply resuming playback will continue the book - until the next crash. Frequency varies randomly and between books - some books seem to crash every 5-30 minutes, others barely ever (every few hours or so).

adam commented

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

@advplyr commented on GitHub (Jan 2, 2024):

I think the crash you are getting is the same as #773 if the crash is only happening while the app is in the background.

@advplyr commented on GitHub (Jan 2, 2024): I think the crash you are getting is the same as #773 if the crash is only happening while the app is in the background.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/audiobookshelf-app#382