Originally created by @woolmonkey on GitHub (Oct 9, 2022).
Describe the issue
So using the android version sometimes I well loose my position and have to find it again because it starts at a previous saved spot usually where I started that listening session. My latest time this happened was when in offline mode with a synced book. Listened on a plane and when started again it was at a previous spot hours before. I honestly can't remember if I took it out of airplane mode and it synced with the server during a layover but the likely hood is good. I have had the same thing happen well listening on Android Auto but can't remember circumstances behind that.]
Just opened up app and the two time remaining are different. The percentage says there is 4.5 hours left but the play par says 3 hours.
Steps to reproduce the issue
Listen to book
stop
listen again and back to previous saved spot.
The books are all downloaded.
Audiobookshelf version
0.9.57-beta on 2.2.1 server
How are you running audiobookshelf?
Docker
Originally created by @woolmonkey on GitHub (Oct 9, 2022).
### Describe the issue
So using the android version sometimes I well loose my position and have to find it again because it starts at a previous saved spot usually where I started that listening session. My latest time this happened was when in offline mode with a synced book. Listened on a plane and when started again it was at a previous spot hours before. I honestly can't remember if I took it out of airplane mode and it synced with the server during a layover but the likely hood is good. I have had the same thing happen well listening on Android Auto but can't remember circumstances behind that.]
Just opened up app and the two time remaining are different. The percentage says there is 4.5 hours left but the play par says 3 hours.
### Steps to reproduce the issue
1. Listen to book
2. stop
3. listen again and back to previous saved spot.
4. The books are all downloaded.
### Audiobookshelf version
0.9.57-beta on 2.2.1 server
### How are you running audiobookshelf?
Docker
adam
added the bug label 2026-04-24 23:16:13 +02:00
@AssortedMapTacks commented on GitHub (Oct 19, 2022):
I have the same problem. I don't expose my server to the internet so I'm offline whenever I leave the house. I'll listen in the car, pause to go into a store, come back and it starts back where it was the first time.
@AssortedMapTacks commented on GitHub (Oct 19, 2022):
I have the same problem. I don't expose my server to the internet so I'm offline whenever I leave the house. I'll listen in the car, pause to go into a store, come back and it starts back where it was the first time.
I am just chiming in with this same problem but do want to add that I don't remember having issues such as this in a few versions ago. As mentioned I will download the entire book/books. I mainly do this because although I 'mostly' have connection to the server, there's drops in my daily commute where I lose all cell signal. It's hard to say when it happens.. sometimes it seems random but other times it's more noticeable if it can't talk to the server for a while. Maybe have a strict offline mode where it will not even try to see the server.. Not sure :) Thanks for the awesome support!
@77boaz commented on GitHub (Nov 16, 2022):
I am just chiming in with this same problem but do want to add that I don't remember having issues such as this in a few versions ago. As mentioned I will download the entire book/books. I mainly do this because although I 'mostly' have connection to the server, there's drops in my daily commute where I lose all cell signal. It's hard to say when it happens.. sometimes it seems random but other times it's more noticeable if it can't talk to the server for a while. Maybe have a strict offline mode where it will not even try to see the server.. Not sure :) Thanks for the awesome support!
Same here. I tested with the book downloaded or streamed, same behaviour.
Also, If I choose manually i.e. chapter 4, the play starts in chapter 3, if I choose chapter 5 it starts at chapter 4 and so on. This is very annoying in special with books that have long chapters.
The issue is not on every audiobook. I have not figured out what the trigger is.
@alephtaph commented on GitHub (Nov 21, 2022):
Same here. I tested with the book downloaded or streamed, same behaviour.
Also, If I choose manually i.e. chapter 4, the play starts in chapter 3, if I choose chapter 5 it starts at chapter 4 and so on. This is very annoying in special with books that have long chapters.
The issue is not on every audiobook. I have not figured out what the trigger is.
@alephtaph The chapter thing may be because of how the chapters were scanned in by Abs. If you press the "Edit Chapters" button on the server web app you can check what each chapter is.
This issue with playback position is on my list to investigate this week.
@advplyr commented on GitHub (Nov 21, 2022):
@alephtaph The chapter thing may be because of how the chapters were scanned in by Abs. If you press the "Edit Chapters" button on the server web app you can check what each chapter is.
This issue with playback position is on my list to investigate this week.
@advplyr Thank you for looking at this. The chapters are alright, and this only happens to books where I have the position issue too. I'm happy to share the audiobook with you, if you need one for investigation.
@alephtaph commented on GitHub (Nov 21, 2022):
@advplyr Thank you for looking at this. The chapters are alright, and this only happens to books where I have the position issue too. I'm happy to share the audiobook with you, if you need one for investigation.
@alephtaph Can you check that the duration of the full audiobook matches what it actually is. The duration is pulled from the audio file metadata and if it is encoded incorrectly then Abs will have the wrong duration.
@advplyr commented on GitHub (Nov 21, 2022):
@alephtaph Can you check that the duration of the full audiobook matches what it actually is. The duration is pulled from the audio file metadata and if it is encoded incorrectly then Abs will have the wrong duration.
I have been experiencing this as well and working on a consistent repro.
Where I see it most is when I listen with a Bluetooth device. If I press play on the app, then at a later time pause via a button on the Bluetooth device and disconnect the device (as one would typically do at the end of a listening session), sometimes the progress won't be synced when I later come back to the app.
That's the most consistent pattern I've seen so far.
@mikehoyle commented on GitHub (Nov 29, 2022):
I have been experiencing this as well and working on a consistent repro.
Where I see it most is when I listen with a Bluetooth device. If I press play on the app, then at a later time pause via a button on the Bluetooth device and disconnect the device (as one would typically do at the end of a listening session), sometimes the progress won't be synced when I later come back to the app.
That's the most consistent pattern I've seen so far.
@MidnightSnowleopard commented on GitHub (Nov 29, 2022):
I've lost some progress at times too switching back and forth between web and android. It seems like there may be some sort of issue with the app not syncing progress at the end of playback or losing connection in the background and then regaining it but no longer syncing position.
Personally I'd be all for the app being paranoid in saving position and always trying to send the most up to date position every single time it is stopped or paused. In addition a button to explicitly send the latest position to the server. Gives a way to ensure that it should get there and explicit feedback if it doesn't.
@MidnightSnowleopard commented on GitHub (Nov 29, 2022):
I've lost some progress at times too switching back and forth between web and android. It seems like there may be some sort of issue with the app not syncing progress at the end of playback or losing connection in the background and then regaining it but no longer syncing position.
Personally I'd be all for the app being paranoid in saving position and always trying to send the most up to date position every single time it is stopped or paused. In addition a button to explicitly send the latest position to the server. Gives a way to ensure that it should get there and explicit feedback if it doesn't.
Using the latest android app and server versions today I lost my progress. The position went back several hours, so maybe a few days worth of listening sessing.
The book is downloaded to the device via the in app option so it is linked to the server item.
I had made several 10min or so listening sessions between stops in my car. On returning to the car after I'm thinking the fourth stop within 30min the playback started as normal upon Bluetooth connection to the car but this is when the position went way back. I let the playback automatically stop when I turn off the car. I don't usually have to interact with the app at all apart from the initial start playback at the start of the trip.
I don't notice a log file available for the android client, is there something I can do to export a log or enable logs for future? I have posted my connection log from the server from today in case that is useful. Server Daily Log 2022-12-23.txt
@Presjar commented on GitHub (Dec 23, 2022):
Using the latest android app and server versions today I lost my progress. The position went back several hours, so maybe a few days worth of listening sessing.
The book is downloaded to the device via the in app option so it is linked to the server item.
I had made several 10min or so listening sessions between stops in my car. On returning to the car after I'm thinking the fourth stop within 30min the playback started as normal upon Bluetooth connection to the car but this is when the position went way back. I let the playback automatically stop when I turn off the car. I don't usually have to interact with the app at all apart from the initial start playback at the start of the trip.
I don't notice a log file available for the android client, is there something I can do to export a log or enable logs for future? I have posted my connection log from the server from today in case that is useful.
[Server Daily Log 2022-12-23.txt](https://github.com/advplyr/audiobookshelf-app/files/10293399/Server.Daily.Log.2022-12-23.txt)
For what it's worth it also seems like the server takes precedence over the app... when I have a book fully downloaded to local. If it loses connection, the server says I last had a signal a half hour ago so you are here! For local books should the client/app have precedence over the server? Maybe an offline mode? Just wondering.. I'm no expert on how syncing works outside of kinda/sorta rsync :) Thanks for the support and this great app!
@77boaz commented on GitHub (Jan 22, 2023):
For what it's worth it also seems like the server takes precedence over the app... when I have a book fully downloaded to local. If it loses connection, the server says I last had a signal a half hour ago so you are here! For local books should the client/app have precedence over the server? Maybe an offline mode? Just wondering.. I'm no expert on how syncing works outside of kinda/sorta rsync :) Thanks for the support and this great app!
@Bostrolicious commented on GitHub (Jan 24, 2023):
I've encountered this problem many times as well. I always lose entire listening sessions, never just part of one. I've looked at the server logs, and there's no record of any progress synchronisation at the time progress was lost, not even the entries where it checks if synchronisation is necessary and determines everything is in sync. I think it's still somehow related to a connection to the server though, as I once tried shutting down the Abs container while listening to a book, and then didn't lose any progress for the remaining 10 hours of the book. Could just be a fluke, of course, but it normally happens more often than that.
Relating to what others have mentioned, I always download my books from the server, and almost always use bluetooth headphones. I don't use Android Auto (I do have a WearOS watch though, in case it's something related to playback control devices, but that seems dubious).
Happy to share logs from the latest session with lost progress if that's of any help. If so, do they need to be anonymised?
@Bostrolicious commented on GitHub (Jan 24, 2023):
I've encountered this problem many times as well. I always lose entire listening sessions, never just part of one. I've looked at the server logs, and there's no record of any progress synchronisation at the time progress was lost, not even the entries where it checks if synchronisation is necessary and determines everything is in sync. I think it's still somehow related to a connection to the server though, as I once tried shutting down the Abs container while listening to a book, and then didn't lose any progress for the remaining 10 hours of the book. Could just be a fluke, of course, but it normally happens more often than that.
Relating to what others have mentioned, I always download my books from the server, and almost always use bluetooth headphones. I don't use Android Auto (I do have a WearOS watch though, in case it's something related to playback control devices, but that seems dubious).
Happy to share logs from the latest session with lost progress if that's of any help. If so, do they need to be anonymised?
Since we are now syncing completely offline listening sessions in Android as of 0.9.62-beta can you test this again?
@advplyr commented on GitHub (Feb 23, 2023):
Since we are now syncing completely offline listening sessions in Android as of 0.9.62-beta can you test this again?
@Bostrolicious commented on GitHub (Feb 24, 2023):
Since we are now syncing completely offline listening sessions in Android as of 0.9.62-beta can you test this again?
I'll try it out and report back if I either lose progress or get through an entire book without any issues. My listening time is a bit limited at the moment though, so it may take a while.
@Bostrolicious commented on GitHub (Feb 24, 2023):
> Since we are now syncing completely offline listening sessions in Android as of 0.9.62-beta can you test this again?
I'll try it out and report back if I either lose progress or get through an entire book without any issues. My listening time is a bit limited at the moment though, so it may take a while.
I've had zero issues for the past week or so after updating the server (not
sure when the app updated). So signs are good that the fix is working!
On Fri, Feb 24, 2023, 1:15 PM Bostrolicious @.***>
wrote:
Since we are now syncing completely offline listening sessions in Android
as of 0.9.62-beta can you test this again?
I'll try it out and report back if I either lose progress or get through
an entire book without any issues. My listening time is a bit limited at
the moment though, so it may take a while.
@mikehoyle commented on GitHub (Feb 24, 2023):
I've had zero issues for the past week or so after updating the server (not
sure when the app updated). So signs are good that the fix is working!
On Fri, Feb 24, 2023, 1:15 PM Bostrolicious ***@***.***>
wrote:
> Since we are now syncing completely offline listening sessions in Android
> as of 0.9.62-beta can you test this again?
>
> I'll try it out and report back if I either lose progress or get through
> an entire book without any issues. My listening time is a bit limited at
> the moment though, so it may take a while.
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/advplyr/audiobookshelf-app/issues/409#issuecomment-1444506110>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AR2UU64MS4S7HR4XLOPIR6LWZEQI3ANCNFSM6AAAAAARAXEFKY>
> .
> You are receiving this because you commented.Message ID:
> ***@***.***>
>
It's working for me now and has been for about a week or so. Although I just updated the app yesterday, it seemed to have been working a bit longer than that. @mikehoyle could be right that it was actually fixed with the server. I did notice the most recent app version just keeps local going under playing. Maybe it was a combo of both.. Anyways it's working fine now. I drove through the usual complete dead spots and it didn't lose position on the app. Thanks!!
@77boaz commented on GitHub (Feb 25, 2023):
It's working for me now and has been for about a week or so. Although I just updated the app yesterday, it seemed to have been working a bit longer than that. @mikehoyle could be right that it was actually fixed with the server. I did notice the most recent app version just keeps local going under playing. Maybe it was a combo of both.. Anyways it's working fine now. I drove through the usual complete dead spots and it didn't lose position on the app. Thanks!!
I'm seeing this issue with android app version 0.9.76-beta and server version 2.13.3 (docker and nginx).
I have an audiobook that I have downloaded onto my phone and mainly listen offline (over bluetooth if that's relevant). When I connect back to the server later on, the listening position in the app is sometimes overwritten with the old listening position from the server.
The book is a single mp3 file that is 22.5 hrs long.
I'm trying to find exact reproduction steps and will post them if I find them.
@pssandhu commented on GitHub (Sep 16, 2024):
I'm seeing this issue with android app version 0.9.76-beta and server version 2.13.3 (docker and nginx).
I have an audiobook that I have downloaded onto my phone and mainly listen offline (over bluetooth if that's relevant). When I connect back to the server later on, the listening position in the app is sometimes overwritten with the old listening position from the server.
The book is a single mp3 file that is 22.5 hrs long.
I'm trying to find exact reproduction steps and will post them if I find them.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @woolmonkey on GitHub (Oct 9, 2022).
Describe the issue
So using the android version sometimes I well loose my position and have to find it again because it starts at a previous saved spot usually where I started that listening session. My latest time this happened was when in offline mode with a synced book. Listened on a plane and when started again it was at a previous spot hours before. I honestly can't remember if I took it out of airplane mode and it synced with the server during a layover but the likely hood is good. I have had the same thing happen well listening on Android Auto but can't remember circumstances behind that.]
Just opened up app and the two time remaining are different. The percentage says there is 4.5 hours left but the play par says 3 hours.
Steps to reproduce the issue
Audiobookshelf version
0.9.57-beta on 2.2.1 server
How are you running audiobookshelf?
Docker
@AssortedMapTacks commented on GitHub (Oct 19, 2022):
I have the same problem. I don't expose my server to the internet so I'm offline whenever I leave the house. I'll listen in the car, pause to go into a store, come back and it starts back where it was the first time.
@77boaz commented on GitHub (Nov 16, 2022):
I am just chiming in with this same problem but do want to add that I don't remember having issues such as this in a few versions ago. As mentioned I will download the entire book/books. I mainly do this because although I 'mostly' have connection to the server, there's drops in my daily commute where I lose all cell signal. It's hard to say when it happens.. sometimes it seems random but other times it's more noticeable if it can't talk to the server for a while. Maybe have a strict offline mode where it will not even try to see the server.. Not sure :) Thanks for the awesome support!
@alephtaph commented on GitHub (Nov 21, 2022):
Same here. I tested with the book downloaded or streamed, same behaviour.
Also, If I choose manually i.e. chapter 4, the play starts in chapter 3, if I choose chapter 5 it starts at chapter 4 and so on. This is very annoying in special with books that have long chapters.
The issue is not on every audiobook. I have not figured out what the trigger is.
@advplyr commented on GitHub (Nov 21, 2022):
@alephtaph The chapter thing may be because of how the chapters were scanned in by Abs. If you press the "Edit Chapters" button on the server web app you can check what each chapter is.
This issue with playback position is on my list to investigate this week.
@alephtaph commented on GitHub (Nov 21, 2022):
@advplyr Thank you for looking at this. The chapters are alright, and this only happens to books where I have the position issue too. I'm happy to share the audiobook with you, if you need one for investigation.
@advplyr commented on GitHub (Nov 21, 2022):
@alephtaph Can you check that the duration of the full audiobook matches what it actually is. The duration is pulled from the audio file metadata and if it is encoded incorrectly then Abs will have the wrong duration.
@mikehoyle commented on GitHub (Nov 29, 2022):
I have been experiencing this as well and working on a consistent repro.
Where I see it most is when I listen with a Bluetooth device. If I press play on the app, then at a later time pause via a button on the Bluetooth device and disconnect the device (as one would typically do at the end of a listening session), sometimes the progress won't be synced when I later come back to the app.
That's the most consistent pattern I've seen so far.
@MidnightSnowleopard commented on GitHub (Nov 29, 2022):
I've lost some progress at times too switching back and forth between web and android. It seems like there may be some sort of issue with the app not syncing progress at the end of playback or losing connection in the background and then regaining it but no longer syncing position.
Personally I'd be all for the app being paranoid in saving position and always trying to send the most up to date position every single time it is stopped or paused. In addition a button to explicitly send the latest position to the server. Gives a way to ensure that it should get there and explicit feedback if it doesn't.
@Presjar commented on GitHub (Dec 23, 2022):
Using the latest android app and server versions today I lost my progress. The position went back several hours, so maybe a few days worth of listening sessing.
The book is downloaded to the device via the in app option so it is linked to the server item.
I had made several 10min or so listening sessions between stops in my car. On returning to the car after I'm thinking the fourth stop within 30min the playback started as normal upon Bluetooth connection to the car but this is when the position went way back. I let the playback automatically stop when I turn off the car. I don't usually have to interact with the app at all apart from the initial start playback at the start of the trip.
I don't notice a log file available for the android client, is there something I can do to export a log or enable logs for future? I have posted my connection log from the server from today in case that is useful.
Server Daily Log 2022-12-23.txt
@77boaz commented on GitHub (Jan 22, 2023):
For what it's worth it also seems like the server takes precedence over the app... when I have a book fully downloaded to local. If it loses connection, the server says I last had a signal a half hour ago so you are here! For local books should the client/app have precedence over the server? Maybe an offline mode? Just wondering.. I'm no expert on how syncing works outside of kinda/sorta rsync :) Thanks for the support and this great app!
@Bostrolicious commented on GitHub (Jan 24, 2023):
I've encountered this problem many times as well. I always lose entire listening sessions, never just part of one. I've looked at the server logs, and there's no record of any progress synchronisation at the time progress was lost, not even the entries where it checks if synchronisation is necessary and determines everything is in sync. I think it's still somehow related to a connection to the server though, as I once tried shutting down the Abs container while listening to a book, and then didn't lose any progress for the remaining 10 hours of the book. Could just be a fluke, of course, but it normally happens more often than that.
Relating to what others have mentioned, I always download my books from the server, and almost always use bluetooth headphones. I don't use Android Auto (I do have a WearOS watch though, in case it's something related to playback control devices, but that seems dubious).
Happy to share logs from the latest session with lost progress if that's of any help. If so, do they need to be anonymised?
@advplyr commented on GitHub (Feb 23, 2023):
Since we are now syncing completely offline listening sessions in Android as of 0.9.62-beta can you test this again?
@Bostrolicious commented on GitHub (Feb 24, 2023):
I'll try it out and report back if I either lose progress or get through an entire book without any issues. My listening time is a bit limited at the moment though, so it may take a while.
@mikehoyle commented on GitHub (Feb 24, 2023):
I've had zero issues for the past week or so after updating the server (not
sure when the app updated). So signs are good that the fix is working!
On Fri, Feb 24, 2023, 1:15 PM Bostrolicious @.***>
wrote:
@77boaz commented on GitHub (Feb 25, 2023):
It's working for me now and has been for about a week or so. Although I just updated the app yesterday, it seemed to have been working a bit longer than that. @mikehoyle could be right that it was actually fixed with the server. I did notice the most recent app version just keeps local going under playing. Maybe it was a combo of both.. Anyways it's working fine now. I drove through the usual complete dead spots and it didn't lose position on the app. Thanks!!
@advplyr commented on GitHub (Feb 25, 2023):
Great! Thanks for testing
@pssandhu commented on GitHub (Sep 16, 2024):
I'm seeing this issue with android app version 0.9.76-beta and server version 2.13.3 (docker and nginx).
I have an audiobook that I have downloaded onto my phone and mainly listen offline (over bluetooth if that's relevant). When I connect back to the server later on, the listening position in the app is sometimes overwritten with the old listening position from the server.
The book is a single mp3 file that is 22.5 hrs long.
I'm trying to find exact reproduction steps and will post them if I find them.