audiobookshelf icon indicating copy to clipboard operation
audiobookshelf copied to clipboard

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

Open mikehoyle opened this issue 2 years ago • 6 comments

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.

mikehoyle avatar Nov 05 '22 06:11 mikehoyle

seconded

FerriteGiant avatar Jan 18 '23 07:01 FerriteGiant

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 avatar Mar 22 '23 10:03 BinkieSmalls

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 avatar May 31 '23 22:05 mitchins

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 avatar Aug 26 '23 00:08 boomboxnation

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 avatar Jan 31 '24 14:01 shall0pass

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

0verEngineer avatar Apr 27 '24 11:04 0verEngineer