Originally created by @cassieesposito on GitHub (May 25, 2022).
Is your feature request related to a problem? Please describe.
One of my users finds the amount of time the ABS app rolls back upon resume to be annoyingly long. I, on the other hand, think it's perfect.
Describe the solution you'd like
A setting where that can be changed. Filling in a box with 1 second granularity without changing the default would be perfect
Originally created by @cassieesposito on GitHub (May 25, 2022).
### Is your feature request related to a problem? Please describe.
One of my users finds the amount of time the ABS app rolls back upon resume to be annoyingly long. I, on the other hand, think it's perfect.
### Describe the solution you'd like
A setting where that can be changed. Filling in a box with 1 second granularity without changing the default would be perfect
This was updated so that you can disable the auto-rewind. I also found the auto-rewind to be too aggressive so it was reduced in the latest release.
@advplyr commented on GitHub (Jul 5, 2022):
This was updated so that you can disable the auto-rewind. I also found the auto-rewind to be too aggressive so it was reduced in the latest release.
Right now I use Listen Audiobook Player on Android which allows you to set rewind times based on how long it has been paused. This is great because if it has only been a few seconds or minutes, I don't need to go back very far to remember what was being read, but if it has been a day or two, then I need more of a refresher. I also like the ability to customize the times since everyone's preference is different. This is one of the biggest features I look for in an app (which is why I hate almost all iOS apps, because I can't find any that do this). I'm excited for this project and to see where it will go!
@darickc commented on GitHub (Aug 3, 2022):
Right now I use Listen Audiobook Player on Android which allows you to set rewind times based on how long it has been paused. This is great because if it has only been a few seconds or minutes, I don't need to go back very far to remember what was being read, but if it has been a day or two, then I need more of a refresher. I also like the ability to customize the times since everyone's preference is different. This is one of the biggest features I look for in an app (which is why I hate almost all iOS apps, because I can't find any that do this). I'm excited for this project and to see where it will go!

Thanks for that screenshot. I am unsure about one thing though. If you close out of an audiobook and start another audiobook, then go back after an hour to the first book will it auto rewind?
Currently in abs the auto rewind only takes place if the player is open and paused for X amount of time then play is pressed.
@advplyr commented on GitHub (Aug 3, 2022):
Thanks for that screenshot. I am unsure about one thing though. If you close out of an audiobook and start another audiobook, then go back after an hour to the first book will it auto rewind?
Currently in abs the auto rewind only takes place if the player is open and paused for X amount of time then play is pressed.
Yes it does. It must keep track when playing stops for any reason. I can close the player completely, come back in and it will rewind it.
@darickc commented on GitHub (Aug 3, 2022):
Yes it does. It must keep track when playing stops for any reason. I can close the player completely, come back in and it will rewind it.
Got it. I'll have to think about this because our app also allows streaming from the server.
We only store local playback sessions in the db on the phone so we may need to change the data model a bit to support this.
@advplyr commented on GitHub (Aug 3, 2022):
Got it. I'll have to think about this because our app also allows streaming from the server.
We only store local playback sessions in the db on the phone so we may need to change the data model a bit to support this.
This would be a really awesome change since I had problems with the auto rewind lately.
Sometimes when listening to an offline file the auto rewind would just go back about five minutes, which can be really annoying.
A soon implementation of this would awesome!
@NotSafarad commented on GitHub (Aug 6, 2022):
This would be a really awesome change since I had problems with the auto rewind lately.
Sometimes when listening to an offline file the auto rewind would just go back about five minutes, which can be really annoying.
A soon implementation of this would awesome!
@toxic0berliner commented on GitHub (Sep 14, 2022):
Fully in line with what @darickc wants, last stop time synced up to server and rewind being applied based on that would be awesome 😎
@toxic0berliner commented on GitHub (Sep 14, 2022):
Fully in line with what @darickc wants, last stop time synced up to server and rewind being applied based on that would be awesome 😎
@WhiteSockedDancer commented on GitHub (Jun 2, 2025):
Any news on this?
What is the current rewind time/logic?
I'm quite confused how much it goes back usually on resuming. Sometimes its quite to long after just a 5 minute break and sometimes it starts with no rewind at all.
Offtopic:
Sometimes even almost 1 minute in the future and i have to go back manually. This is quite annoying and seems to be another bug that keeps my progress not synced that well.
Maybe when stopping while the phone is locked, abs just saves the progress on a later interval?
Enabling "Allowed Background-activity" helped a little bit (i guess), but it's still not perfect.
There are already a lot of issues marked with progress sync, but most of them are about syncing with android auto? I'm not sure how to debug this and if i should open a new issue.
@WhiteSockedDancer commented on GitHub (Jun 2, 2025):
Any news on this?
What is the current rewind time/logic?
I'm quite confused how much it goes back usually on resuming. Sometimes its quite to long after just a 5 minute break and sometimes it starts with no rewind at all.
**Offtopic:**
Sometimes even almost 1 minute in the future and i have to go back manually. This is quite annoying and seems to be another bug that keeps my progress not synced that well.
Maybe when stopping while the phone is locked, abs just saves the progress on a later interval?
Enabling "Allowed Background-activity" helped a little bit (i guess), but it's still not perfect.
There are already a lot of issues marked with progress sync, but most of them are about syncing with android auto? I'm not sure how to debug this and if i should open a new issue.
Offtopic:
Sometimes even almost 1 minute in the future and i have to go back manually. This is quite annoying and seems to be another bug that keeps my progress not synced that well.
Maybe when stopping while the phone is locked, abs just saves the progress on a later interval?
Enabling "Allowed Background-activity" helped a little bit (i guess), but it's still not perfect.
There are already a lot of issues marked with progress sync, but most of them are about syncing with android auto? I'm not sure how to debug this and if i should open a new issue.
If resuming listening is happening in the future, this is almost always because you are using a VBR file so seeking is inaccurate. You should encode your file to use constant bitrate for mp3 or enable mp3 index seeking in the app.
@nichwall commented on GitHub (Jun 2, 2025):
> **Offtopic:**
> Sometimes even almost 1 minute in the future and i have to go back manually. This is quite annoying and seems to be another bug that keeps my progress not synced that well.
> Maybe when stopping while the phone is locked, abs just saves the progress on a later interval?
> Enabling "Allowed Background-activity" helped a little bit (i guess), but it's still not perfect.
> There are already a lot of issues marked with progress sync, but most of them are about syncing with android auto? I'm not sure how to debug this and if i should open a new issue.
If resuming listening is happening in the future, this is almost always because you are using a VBR file so seeking is inaccurate. You should encode your file to use constant bitrate for mp3 or enable mp3 index seeking in the app.
@WhiteSockedDancer commented on GitHub (Jun 3, 2025):
Offtopic:
Sometimes even almost 1 minute in the future and i have to go back manually. This is quite annoying and seems to be another bug that keeps my progress not synced that well.
Maybe when stopping while the phone is locked, abs just saves the progress on a later interval?
Enabling "Allowed Background-activity" helped a little bit (i guess), but it's still not perfect.
There are already a lot of issues marked with progress sync, but most of them are about syncing with android auto? I'm not sure how to debug this and if i should open a new issue.
If resuming listening is happening in the future, this is almost always because you are using a VBR file so seeking is inaccurate. You should encode your file to use constant bitrate for mp3 or enable mp3 index seeking in the app.
Thanks for your answer!
How could i check if my mp3 files have a constant bitrate?
But i will try the mp3 index seeking in the app! Thanks.
@WhiteSockedDancer commented on GitHub (Jun 3, 2025):
> > **Offtopic:**
> > Sometimes even almost 1 minute in the future and i have to go back manually. This is quite annoying and seems to be another bug that keeps my progress not synced that well.
> > Maybe when stopping while the phone is locked, abs just saves the progress on a later interval?
> > Enabling "Allowed Background-activity" helped a little bit (i guess), but it's still not perfect.
> > There are already a lot of issues marked with progress sync, but most of them are about syncing with android auto? I'm not sure how to debug this and if i should open a new issue.
>
> If resuming listening is happening in the future, this is almost always because you are using a VBR file so seeking is inaccurate. You should encode your file to use constant bitrate for mp3 or enable mp3 index seeking in the app.
Thanks for your answer!
How could i check if my mp3 files have a constant bitrate?

But i will try the mp3 index seeking in the app! Thanks.
You can't detect it in Abs but if you have VLC media player you can detect it using the Tools -> Codec Information (Ctrl + i) then go to the Statistics tab.
As you listen to the file in VLC media player you can watch the statistics changing. For variable bit rate files the "Input bitrate" will be changing.
Here is an example of a constant bit rate audio file.
@advplyr commented on GitHub (Jun 3, 2025):
You can't detect it in Abs but if you have VLC media player you can detect it using the Tools -> Codec Information (Ctrl + i) then go to the Statistics tab.
As you listen to the file in VLC media player you can watch the statistics changing. For variable bit rate files the "Input bitrate" will be changing.
Here is an example of a constant bit rate audio file.

@WhiteSockedDancer commented on GitHub (Jun 4, 2025):
Thanks! I will check that. Got VLC installed ;).
But back to topic:
What is the current rewind time/logic?
@WhiteSockedDancer commented on GitHub (Jun 4, 2025):
Thanks! I will check that. Got VLC installed ;).
But back to topic:
What is the current rewind time/logic?
@advplyr commented on GitHub (Jun 4, 2025):
> Thanks! I will check that. Got VLC installed ;).
>
> But back to topic:
>
> What is the current rewind time/logic?
https://github.com/advplyr/audiobookshelf-app/blob/d26403c8004fcc06509d87ec8ad6b31ac7fb7322/android/app/src/main/java/com/audiobookshelf/app/player/PlayerListener.kt#L163-L173
@WhiteSockedDancer commented on GitHub (Jun 5, 2025):
Ah, thanks. More different durations hardcoded than I expected ^^.
Having these not hard coded but adjustable in the settings would be nice to have, so everyone could change these to preferred values.
Probably both values (time and seekback) with already in code provided default values but in seconds.
If someone wants to just have two different seekback times they could just put the same values in.
It could look like that for just 5s and 30s:
time since last pause (ms)
seekback (ms)
< 10000 (10s)
5000 (5s)
< 60000 (1m)
5000(5s)
< 300000 (5m)
30000 (30s)
< 300000 (5m)
30000 (30s)
else
30000 (30s)
Is this time since last pause (time) app-specific or synced with ABS? The best approach would be to have the last synced pause timestamp and decide on that. This way the seekback is always individual for every audiobook and also works with different players.
usecase: On my way home i listen to an audiobook on my phone or in the car and when I'm at home i want to continue to the end of the chapter on my music-assistant player or in my browser/desktop PC.
Since the last pause (on my phone) just happend and got synced i can continue without any seekback on the other device.
@WhiteSockedDancer commented on GitHub (Jun 5, 2025):
Ah, thanks. More different durations hardcoded than I expected ^^.
Having these not hard coded but adjustable in the settings would be nice to have, so everyone could change these to preferred values.
Probably both values (time and seekback) with already in code provided default values but in seconds.
If someone wants to just have two different seekback times they could just put the same values in.
It could look like that for just 5s and 30s:
| time since last pause (ms) | seekback (ms) |
|----------------------------|---------------|
| < 10000 (10s) | 5000 (5s) |
| < 60000 (1m) | 5000(5s) |
| < 300000 (5m) | 30000 (30s) |
| < 300000 (5m) | 30000 (30s) |
| else | 30000 (30s) |
---
Is this time since last pause (time) app-specific or synced with ABS? The best approach would be to have the last synced pause timestamp and decide on that. This way the seekback is always individual for every audiobook and also works with different players.
usecase: On my way home i listen to an audiobook on my phone or in the car and when I'm at home i want to continue to the end of the chapter on my music-assistant player or in my browser/desktop PC.
Since the last pause (on my phone) just happend and got synced i can continue without any seekback on the other device.
The last pause time is stored locally in memory on the device, not synced to the server. It is also not saved in a database so if you restart the app it is not persisted.
@advplyr commented on GitHub (Jun 5, 2025):
The last pause time is stored locally in memory on the device, not synced to the server. It is also not saved in a database so if you restart the app it is not persisted.
@WhiteSockedDancer commented on GitHub (Jun 5, 2025):
But the last pause/stop gets synced, isn't it?
Would it be possible to use that timestamp if available and just use the locally stored one as fallback?
@WhiteSockedDancer commented on GitHub (Jun 5, 2025):
But the last pause/stop gets synced, isn't it?
Would it be possible to use that timestamp if available and just use the locally stored one as fallback?
It doesn't get synced. There is a request to sync every play, pause, seek action to the server but I think that is an unnecessary amount of data to keep. That data is just stored locally on the device
@advplyr commented on GitHub (Jun 5, 2025):
It doesn't get synced. There is a request to sync every play, pause, seek action to the server but I think that is an unnecessary amount of data to keep. That data is just stored locally on the device
@WhiteSockedDancer commented on GitHub (Jun 6, 2025):
It doesn't get synced. There is a request to sync every play, pause, seek action to the server but I think that is an unnecessary amount of data to keep. That data is just stored locally on the device
Maybe I'm making a mistake, but when I stop listening my progress is synced with the server. if i pause, my progress also gets synced. Else i could not continue on another device.
We have a timestamp of when last syncing happend => lastplaytime?
@WhiteSockedDancer commented on GitHub (Jun 6, 2025):
> It doesn't get synced. There is a request to sync every play, pause, seek action to the server but I think that is an unnecessary amount of data to keep. That data is just stored locally on the device
Maybe I'm making a mistake, but when I stop listening my progress is synced with the server. if i pause, my progress also gets synced. Else i could not continue on another device.
We have a timestamp of when last syncing happend => lastplaytime?
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 @cassieesposito on GitHub (May 25, 2022).
Is your feature request related to a problem? Please describe.
One of my users finds the amount of time the ABS app rolls back upon resume to be annoyingly long. I, on the other hand, think it's perfect.
Describe the solution you'd like
A setting where that can be changed. Filling in a box with 1 second granularity without changing the default would be perfect
@advplyr commented on GitHub (Jul 5, 2022):
This was updated so that you can disable the auto-rewind. I also found the auto-rewind to be too aggressive so it was reduced in the latest release.
@darickc commented on GitHub (Aug 3, 2022):
Right now I use Listen Audiobook Player on Android which allows you to set rewind times based on how long it has been paused. This is great because if it has only been a few seconds or minutes, I don't need to go back very far to remember what was being read, but if it has been a day or two, then I need more of a refresher. I also like the ability to customize the times since everyone's preference is different. This is one of the biggest features I look for in an app (which is why I hate almost all iOS apps, because I can't find any that do this). I'm excited for this project and to see where it will go!
@advplyr commented on GitHub (Aug 3, 2022):
Thanks for that screenshot. I am unsure about one thing though. If you close out of an audiobook and start another audiobook, then go back after an hour to the first book will it auto rewind?
Currently in abs the auto rewind only takes place if the player is open and paused for X amount of time then play is pressed.
@darickc commented on GitHub (Aug 3, 2022):
Yes it does. It must keep track when playing stops for any reason. I can close the player completely, come back in and it will rewind it.
@advplyr commented on GitHub (Aug 3, 2022):
Got it. I'll have to think about this because our app also allows streaming from the server.
We only store local playback sessions in the db on the phone so we may need to change the data model a bit to support this.
@darickc commented on GitHub (Aug 4, 2022):
That would be awesome!
@NotSafarad commented on GitHub (Aug 6, 2022):
This would be a really awesome change since I had problems with the auto rewind lately.
Sometimes when listening to an offline file the auto rewind would just go back about five minutes, which can be really annoying.
A soon implementation of this would awesome!
@toxic0berliner commented on GitHub (Sep 14, 2022):
Fully in line with what @darickc wants, last stop time synced up to server and rewind being applied based on that would be awesome 😎
@MadWalnut commented on GitHub (Oct 5, 2022):
This feature would be really great!
@WhiteSockedDancer commented on GitHub (Jun 2, 2025):
Any news on this?
What is the current rewind time/logic?
I'm quite confused how much it goes back usually on resuming. Sometimes its quite to long after just a 5 minute break and sometimes it starts with no rewind at all.
Offtopic:
Sometimes even almost 1 minute in the future and i have to go back manually. This is quite annoying and seems to be another bug that keeps my progress not synced that well.
Maybe when stopping while the phone is locked, abs just saves the progress on a later interval?
Enabling "Allowed Background-activity" helped a little bit (i guess), but it's still not perfect.
There are already a lot of issues marked with progress sync, but most of them are about syncing with android auto? I'm not sure how to debug this and if i should open a new issue.
@nichwall commented on GitHub (Jun 2, 2025):
If resuming listening is happening in the future, this is almost always because you are using a VBR file so seeking is inaccurate. You should encode your file to use constant bitrate for mp3 or enable mp3 index seeking in the app.
@WhiteSockedDancer commented on GitHub (Jun 3, 2025):
Thanks for your answer!
How could i check if my mp3 files have a constant bitrate?
But i will try the mp3 index seeking in the app! Thanks.
@advplyr commented on GitHub (Jun 3, 2025):
You can't detect it in Abs but if you have VLC media player you can detect it using the Tools -> Codec Information (Ctrl + i) then go to the Statistics tab.
As you listen to the file in VLC media player you can watch the statistics changing. For variable bit rate files the "Input bitrate" will be changing.
Here is an example of a constant bit rate audio file.
@WhiteSockedDancer commented on GitHub (Jun 4, 2025):
Thanks! I will check that. Got VLC installed ;).
But back to topic:
What is the current rewind time/logic?
@advplyr commented on GitHub (Jun 4, 2025):
https://github.com/advplyr/audiobookshelf-app/blob/d26403c8004fcc06509d87ec8ad6b31ac7fb7322/android/app/src/main/java/com/audiobookshelf/app/player/PlayerListener.kt#L163-L173
@WhiteSockedDancer commented on GitHub (Jun 5, 2025):
Ah, thanks. More different durations hardcoded than I expected ^^.
Having these not hard coded but adjustable in the settings would be nice to have, so everyone could change these to preferred values.
Probably both values (time and seekback) with already in code provided default values but in seconds.
If someone wants to just have two different seekback times they could just put the same values in.
It could look like that for just 5s and 30s:
Is this time since last pause (time) app-specific or synced with ABS? The best approach would be to have the last synced pause timestamp and decide on that. This way the seekback is always individual for every audiobook and also works with different players.
usecase: On my way home i listen to an audiobook on my phone or in the car and when I'm at home i want to continue to the end of the chapter on my music-assistant player or in my browser/desktop PC.
Since the last pause (on my phone) just happend and got synced i can continue without any seekback on the other device.
@advplyr commented on GitHub (Jun 5, 2025):
The last pause time is stored locally in memory on the device, not synced to the server. It is also not saved in a database so if you restart the app it is not persisted.
@WhiteSockedDancer commented on GitHub (Jun 5, 2025):
But the last pause/stop gets synced, isn't it?
Would it be possible to use that timestamp if available and just use the locally stored one as fallback?
@advplyr commented on GitHub (Jun 5, 2025):
It doesn't get synced. There is a request to sync every play, pause, seek action to the server but I think that is an unnecessary amount of data to keep. That data is just stored locally on the device
@WhiteSockedDancer commented on GitHub (Jun 6, 2025):
Maybe I'm making a mistake, but when I stop listening my progress is synced with the server. if i pause, my progress also gets synced. Else i could not continue on another device.
We have a timestamp of when last syncing happend => lastplaytime?