starred/audiobookshelf
1
0
Fork 0
mirror of https://github.com/advplyr/audiobookshelf.git synced 2026-05-30 23:40:40 +02:00
Code Issues 1.0k Packages Projects Releases 10 Wiki Activity

[Enhancement]: Discussion thread: better cross-platform session syncing #729

New Issue
Open
opened 2026-04-24 23:18:40 +02:00 by adam · 6 comments
adam commented 2026-04-24 23:18:40 +02:00
Owner
Copy Link
Copy Source

Originally created by @mikehoyle on GitHub (Nov 5, 2022).

Describe the feature/enhancement

There will be some overlap with the app codebase here, but the idea belongs in core I think. Please de-dupe if there's another discussion, I couldn't find one via search.

Background:

I am a regular listener on mobile (Android) and multiple iterations of the web-app. It's common for me to swap between the mediums (ex. Listen on web while at desktop, swap same book to mobile to go on a walk, then swap to my laptop at the couch when I return). In my experience, progress syncing for a single user is not particularly well supported when listening from multiple sources.

Here's my experience: The web-app typically requires a page refresh in order to sync new progress data, and the mobile app requires a close (i.e. swipe away from apps list) and re-open and reconnect to get an updated sync. Either will happily let you pick up from an outdated local progress point if you're not careful, and that risks overwriting your actual progress.

Ideas

Here are a few high-level ideas for how the experience could possibly be improved. I'll keep ideas constrained to the web-app as is appropriate for this forum, but they could easily be applied to the mobile app:

  • On computer wake, tab-activate, or periodically on pause, detect if server data shows user progress on a book as beyond what is known locally. If so, present/activate a "Sync progress" button.
  • Alternately, introduce a restriction that expects a user to only be listening to any given piece of media on a single device at once -- my naïve impression is the database expects this anyways, but doesn't enforce it. That way, you can confidently sync progress proactively without user input. In the best world, this would involve work to include a Spotify-esque UI such as "You are listening on X device, listen here?"

The downside here is it could restrict a very specific subset of users sharing an account while simultaneously listening to the same book, but that feels like an unsupported case anyways. The server couldn't make heads or tails of the session, and there's no motivation for users to share accounts on a self-hosted server in which unlimited accounts can be created. There's also a corner-case risk progress could be lost on forced sync, but it would be very easy to only sync server progress if it was beyond local progress.

Let me know your thoughts. I'm open to discussion and being involved in implementation, but I don't want to start anything without signoff, or knowledge that similar efforts aren't already underway.

Originally created by @mikehoyle on GitHub (Nov 5, 2022). ### Describe the feature/enhancement There will be some overlap with the app codebase here, but the idea belongs in core I think. Please de-dupe if there's another discussion, I couldn't find one via search. ## Background: I am a regular listener on mobile (Android) and multiple iterations of the web-app. It's common for me to swap between the mediums (ex. Listen on web while at desktop, swap same book to mobile to go on a walk, then swap to my laptop at the couch when I return). In my experience, progress syncing for a single user is not particularly well supported when listening from multiple sources. Here's my experience: The web-app typically requires a page refresh in order to sync new progress data, and the mobile app requires a close (i.e. swipe away from apps list) and re-open and reconnect to get an updated sync. Either will happily let you pick up from an outdated local progress point if you're not careful, and that risks overwriting your actual progress. ## Ideas Here are a few high-level ideas for how the experience could possibly be improved. I'll keep ideas constrained to the web-app as is appropriate for this forum, but they could easily be applied to the mobile app: - On computer wake, tab-activate, or periodically on pause, detect if server data shows user progress on a book as beyond what is known locally. If so, present/activate a "Sync progress" button. - Alternately, introduce a restriction that expects a user to only be listening to any given piece of media on a single device at once -- my naïve impression is the database expects this anyways, but doesn't enforce it. That way, you can confidently sync progress proactively without user input. In the best world, this would involve work to include a Spotify-esque UI such as "You are listening on X device, listen here?" The downside here is it could restrict a very specific subset of users sharing an account while simultaneously listening to the same book, but that feels like an unsupported case anyways. The server couldn't make heads or tails of the session, and there's no motivation for users to share accounts on a self-hosted server in which unlimited accounts can be created. There's also a corner-case risk progress could be lost on forced sync, but it would be very easy to only sync server progress if it was beyond local progress. Let me know your thoughts. I'm open to discussion and being involved in implementation, but I don't want to start anything without signoff, or knowledge that similar efforts aren't already underway.
adam added the enhancementprogress sync labels 2026-04-24 23:18:40 +02:00
adam commented 2026-04-24 23:18:40 +02:00
Author
Owner
Copy Link
Copy Source

@FerriteGiant commented on GitHub (Jan 18, 2023):

seconded

@FerriteGiant commented on GitHub (Jan 18, 2023): seconded
adam commented 2026-04-24 23:18:41 +02:00
Author
Owner
Copy Link
Copy Source

@BinkieSmalls commented on GitHub (Mar 22, 2023):

I am having the same issue with the syncing between web and android. Thank you for offering a workaround at least.
I can't help program a solution but would be able to help with testing

@BinkieSmalls commented on GitHub (Mar 22, 2023): I am having the same issue with the syncing between web and android. Thank you for offering a workaround at least. I can't help program a solution but would be able to help with testing
adam commented 2026-04-24 23:18:41 +02:00
Author
Owner
Copy Link
Copy Source

@mitchins commented on GitHub (Jun 1, 2023):

I came here for this very reason.

Even audible doesn't handle this fantastically, but I feel the "kindle" model of "furthest position" would solve this nicely.

There's two issues:

  • keeping the progress head
  • mobile apps (iOS at least won't sync the session unless I kill the app and re-open it).

It seems like the server is able to keep the furthest position read ok but the risk here is when resuming a client (such as going from iPad to iPhone) where it's behind, it'll actually update the server status to the position that's behind.

So we have two scenarios:

  • resuming when the app is open (app is active and in view)
  • resuming from the media controls such as iOS.

The first one is easy, we could ping the server for the latest position on resume - I haven't checked out the iOS code base yet but chances are it can be resolved client side with a simple pop up alert.

The second one is more complicated such I don't think we can change the player location easily nor even ask the user.
There's a couple of solutions:

  1. marking chapters as read for these books with chapters will help track down where we were.
  2. keeping a log of different clients "max position" would work similarly even if there's no chapters.
  3. least likely of all, there might be a way to use background extensions on mobile to update the player status but it's been a while since I've worked in media apps.

Overall, my recommendation is perhaps to go with 2, keeping a simple log of the head of where each client is up to as a log to jump to.

@mitchins commented on GitHub (Jun 1, 2023): I came here for this very reason. Even audible doesn't handle this fantastically, but I feel the "kindle" model of "furthest position" would solve this nicely. There's two issues: * keeping the progress head * mobile apps (iOS at least won't sync the session unless I kill the app and re-open it). It seems like the server is able to keep the furthest position read ok but the risk here is when resuming a client (such as going from iPad to iPhone) where it's behind, it'll actually update the server status to the position that's behind. So we have two scenarios: * resuming when the app is open (app is active and in view) * resuming from the media controls such as iOS. The first one is easy, we could ping the server for the latest position on resume - I haven't checked out the iOS code base yet but chances are it can be resolved client side with a simple pop up alert. The second one is more complicated such I don't think we can change the player location easily nor even ask the user. There's a couple of solutions: 1. marking chapters as read for these books with chapters will help track down where we were. 2. keeping a log of different clients "max position" would work similarly even if there's no chapters. 3. least likely of all, there might be a way to use background extensions on mobile to update the player status but it's been a while since I've worked in media apps. Overall, my recommendation is perhaps to go with 2, keeping a simple log of the head of where each client is up to as a log to jump to.
adam commented 2026-04-24 23:18:42 +02:00
Author
Owner
Copy Link
Copy Source

@boomboxnation commented on GitHub (Aug 26, 2023):

Very much agreed. A force sync is needed. I am so tired of losing my position while listening to local data on my phone. On the phone. I only listen to local on the phone, I will likely turn to just using ABS as an easy way to download audiobooks to my phone, and use a no-server app.

@boomboxnation commented on GitHub (Aug 26, 2023): Very much agreed. A force sync is needed. I am so tired of losing my position while listening to local data on my phone. On the phone. I only listen to local on the phone, I will likely turn to just using ABS as an easy way to download audiobooks to my phone, and use a no-server app.
adam commented 2026-04-24 23:18:43 +02:00
Author
Owner
Copy Link
Copy Source

@shall0pass commented on GitHub (Jan 31, 2024):

I am also having this issue where the play progress is being lost. Though in my case it's not always just web and android, it also seems to occur when my books are downloaded locally on android and I don't have a server connection at the time. If I listen to a book without a server connection, the next time I open the app the server progress will overwrite the local progress and I'll lose my place. The Libby app has solved this by giving the user an option to use the "Server progress" or "Local progress" if the two differ.

@shall0pass commented on GitHub (Jan 31, 2024): I am also having this issue where the play progress is being lost. Though in my case it's not always just web and android, it also seems to occur when my books are downloaded locally on android and I don't have a server connection at the time. If I listen to a book without a server connection, the next time I open the app the server progress will overwrite the local progress and I'll lose my place. The Libby app has solved this by giving the user an option to use the "Server progress" or "Local progress" if the two differ.
adam commented 2026-04-24 23:18:44 +02:00
Author
Owner
Copy Link
Copy Source

@0verEngineer commented on GitHub (Apr 27, 2024):

I also switch very often between android and web and i have lost my progress very often.

@0verEngineer commented on GitHub (Apr 27, 2024): I also switch very often between android and web and i have lost my progress very often.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
authentication
backlog
bug
chapter editor
config-issue
ebooks
encoding/embedding
enhancement
help wanted
listening sessions & progress
planned
possible plugin
progress sync
pull-request
Mirrored from GitHub Pull Request
 sorting/filtering/searching
unable to reproduce
upload
users & permissions
waiting
No Label enhancement progress sync
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam (Adam Melkus)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/audiobookshelf#729
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?