mirror of
https://github.com/advplyr/audiobookshelf.git
synced 2026-03-02 22:46:55 -05:00
[Enhancement]: Proper Sync & Improved Support for Offline/Online Servers #2131
Labels
No labels
authentication
awaiting release
backlog
bug
chapter editor
config-issue
ebooks
encoding/embedding
enhancement
help wanted
listening sessions & progress
planned
possible plugin
progress sync
sorting/filtering/searching
unable to reproduce
upload
users & permissions
waiting
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/audiobookshelf-advplyr#2131
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
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?
Originally created by @Paradonas on GitHub (Jul 30, 2024).
Type of Enhancement
Server Backend
Describe the Feature/Enhancement
Issue 1: Sync Problem
When transitioning from my desktop web session to the mobile app to continue listening, the sync process does not work as expected. Since I frequently switch between devices, it's common for me to have the mobile app paused on the same audiobook I was playing on my PC. However, the playback on the mobile app lags behind the PC, requiring me to navigate out of the audiobook on the mobile app, wait for synchronization to occur (after pausing playback on the PC), then re-enter the audiobook to resume listening from where I left off on the PC.
I suggest improving the syncing process so that progress syncs automatically when I press play on the mobile app, eliminating the need to return to the bookshelf each time. Alternatively, a feature similar to Spotify or Audible where a "continue listening" or "carry over listening" button is available on both mobile and desktop platforms could be implemented.
This syncing issue also occurs in reverse, where I need to refresh the desktop page to sync from mobile, which I believe is expected behavior.
Issue 2: Server Connectivity
Due to not having a dedicated server PC, I run the server on my main PC, which is frequently restarted. This setup sometimes results in the mobile app losing connection to the server after multiple connection failures, requiring me to manually reconnect to the server.
Why would this be helpful?
To improve the app in the above described use cases.
Future Implementation (Screenshot)
Self Explanatory
Audiobookshelf Server Version
2.11.0
Current Implementation (Screenshot)
No response
@nichwall commented on GitHub (Jul 30, 2024):
Related to https://github.com/advplyr/audiobookshelf/issues/1113
https://github.com/advplyr/audiobookshelf-app/issues/1262
https://github.com/advplyr/audiobookshelf-app/issues/1161
https://github.com/advplyr/audiobookshelf-app/issues/1146
https://github.com/advplyr/audiobookshelf-app/issues/1076
https://github.com/advplyr/audiobookshelf-app/issues/1120
For point 1: How long do you leave the mobile app open in the background? (an hour, a day, never close the app, etc) Can you see the websocket closing in the server?
Can you provide some more information or logs about your sync issues?
For point 2: When you say "manually reconnect", do you mean having to enter credentials in the app again or just having to manually connect the server? If just manually connect to the server, that is by design so the app does not continuously try and communicate with the server after so many failed attempts (switching to offline mode automatically when in poor service or if the server is offline/not available outside of your local network)
@Silther commented on GitHub (Jul 31, 2024):
I personally do like the way how Spotify handles the syncing and would appreciate a similar thing in audiobookshelf.
But it would take away the freedom to listen to multiple audiobooks at the same time (if you haven't yet created a new account for a friend or other scenarios).
@Paradonas commented on GitHub (Jul 31, 2024):
I mostly leave the app running and simply shut down the screen with the power button as you do when done using your phone. Other times I leave the app on in the background with it being visible on the android app overview (the 3rd button, not back or home) as well as the widget of course being visible. I tested the issue now everything worked well. I shall have to monitor and test some more when I listen to see if the problem happens again as well as provide the logs in such an instance. I can remember it happening quite a few times previously though so for the moment just know that the sync doesn't feel perfect or work as well as with other similar services such as Spotify.
I will return to this issue when I've gathered some more info about the problem.
I mean as you say "just manually connect to the server" which you mention is by design. I guess this probably works well for others who have a permanent online server at a location where they can consistently connect to it for example every time they are home. For me however I'd like the server to try and connect if I'm in the mobile app or currently playing a book from the phone even after it has failed to connect previously which it may do more than others since as I mention the server is just online when I'm using my PC.
Thanks for your wonderful work on this app ❤️
@Paradonas commented on GitHub (Jul 31, 2024):
I think it's intended to be multiple account for different people. This isn't a problem in Audiobookshelf as it is in Spotify where u might want to share an account for Premium for example. So it wouldn't really be a problem then.
@Paradonas commented on GitHub (Aug 1, 2024):
Audiobookshelf Sync Issue
Played earlier on mobile. Switched over to PC and played for an hour or so. Switched back to mobile and the audiobook isn't synced. Progress on PC is 78%(44:32:07) while 76% (43:41:59) on mobile.
The sync in history on mobile says it synced on 15:28 it's now 15:32 meaning it indicates a recent sync that should've synced up to 78%, yet this didn't happen. The server is connected and a green cloud checkmark icon is visible on mobile and their is an indicated socket connection at 15:26:52 in the server logs. Everything seems ok yet the progress is unsynced? Does this somehow have to do with that I have downloaded the audiobook? The progress still syncs but there isn't any active stream that plays directly which might sync more reliably.
Earlier, when entering the library it said the library was empty yet connected to the server. I think this was it just loading. Normally, sometimes, I think simply going back here where the library usually is loaded fixes the issue withour having to restart the mobile app as well but I digress.
I've waited for about 5 minutes and the audiobook still isn't synced. Restarting the mobile app worked and now I'm at 78%. In the past I have a couple of times clicked play and lost my progress and had to scroll manually looking through and finding where I was when this happened. I also didn't know how far back I was so the issue was more infuriating.
Thx for the help
@Paradonas commented on GitHub (Aug 1, 2024):
Full logs:
production Config C:\Users[user]\AppData\Local\Audiobookshelf\config C:\Users[user]\AppData\Local\Audiobookshelf\metadata
[2024-08-01 14:14:49.076] INFO: === Starting Server ===
[2024-08-01 14:14:49.088] INFO: [Server] Init v2.11.0
[2024-08-01 14:14:49.088] INFO: [Server] Node.js Version: v20.11.1
[2024-08-01 14:14:49.095] INFO: [Database] Initializing db at "C:\Users[user]\AppData\Local\Audiobookshelf\config\absdatabase.sqlite"
[2024-08-01 14:14:49.137] INFO: [Database] Db connection was successful
[2024-08-01 14:14:49.214] INFO: [Database] Db initialized with models: user, library, libraryFolder, book, podcast, podcastEpisode, libraryItem, mediaProgress, series, bookSeries, author, bookAuthor, collection, collectionBook, playlist, playlistMediaItem, device, playbackSession, feed, feedEpisode, setting, customMetadataProvider, mediaItemShare
[2024-08-01 14:14:49.243] WARN: Removed 1 sessions that were 3 seconds or less ( at Database.cleanDatabase (C:\snapshot\audiobookshelf\server\Database.js))
[2024-08-01 14:14:49.246] INFO: [LogManager] Init current daily log filename: 2024-08-01.txt
[2024-08-01 14:14:49.331] INFO: [BackupManager] 2 Backups Found
[2024-08-01 14:14:55.633] INFO: [BinaryManager] Found valid binary ffmpeg at E:\Audiobookshelf\Audiobookshelf\ffmpeg.exe
[2024-08-01 14:14:55.633] INFO: [BinaryManager] Updating process.env.FFMPEG_PATH
[2024-08-01 14:14:57.314] INFO: [BinaryManager] Found valid binary ffprobe at E:\Audiobookshelf\Audiobookshelf\ffprobe.exe
[2024-08-01 14:14:57.314] INFO: [BinaryManager] Updating process.env.FFPROBE_PATH
[2024-08-01 14:14:57.315] INFO: [Watcher] Initializing watcher for "Library".
Warning: connect.session() MemoryStore is not
designed for a production environment, as it will leak
memory, and will not scale past a single process.
[2024-08-01 14:14:57.319] INFO: Listening on port :3333
[2024-08-01 14:14:57.346] INFO: [Watcher] "Library" Ready
[2024-08-01 14:16:22.571] INFO: [SocketAuthority] Socket Connected 9Ufvf-219DTlAM8iAAAB
[2024-08-01 14:16:38.182] INFO: [SocketAuthority] Socket Connected uWLXVstShUosZLsUAAAD
[2024-08-01 14:34:51.941] INFO: [SocketAuthority] Socket 9Ufvf-219DTlAM8iAAAB disconnected from client "admin" after 1109370ms (Reason: ping timeout)
[2024-08-01 15:26:52.757] INFO: [SocketAuthority] Socket Connected IgXTfOG1_7JUmWhGAAAF
[2024-08-01 15:37:26.931] INFO: [SocketAuthority] Socket IgXTfOG1_7JUmWhGAAAF disconnected from client "admin" after 634174ms (Reason: transport close)
[2024-08-01 15:37:29.634] INFO: [SocketAuthority] Socket Connected mLVeoTHmJB_uwAJVAAAH
I started playing from mobile again which is the last entry.
@nichwall commented on GitHub (Aug 1, 2024):
Thanks for the additional information.
So to clarify the order of events:
There is a socket disconnect during that I think it's the socket from the app being closed during playback in the browser due to inactivity. The socket is what syncs playback when multiple players are open.
@nichwall commented on GitHub (Aug 1, 2024):
Also, if you could change your log level to Debug that will show sync events (and more information) in the server log.
@Paradonas commented on GitHub (Aug 1, 2024):
I'm not sure when I specifically turned on my screen and app, pausing and the starting the server which runs as a service so specifically when that happens is unclear as well.
I start the server while listening so then app would then be active but with the screen off. I then start the PC and server and then pause wait for a few secs and then switch listening device to PC. This worked seamlessly this time with the sync occurring instantly as desired.
Yes this worked seamlessly.
Yes. Naturally I didn't close the media player as that stays open while in the app, at least in its minimized form (even in settings).
Maybe you mean the maximized version? I'm not sure if that's relevant but to clarify expected behavior should be for sync to occur even when pausing from the widget which is accessible even before in mobile lock screen. Maybe this is difficult to do though.
This is what bothers me. It should be synced when I just clink play because the connection to the servers is active. Preferably clicking play should just work. But currently you often have to back out, sometimes close the app(confirmed tested above), sometimes just back out to library for it to sync (not specifically tested yet).
The socket disconnect
[2024-08-01 15:37:26.931] INFO: [SocketAuthority] Socket IgXTfOG1_7JUmWhGAAAF disconnected from client "admin" after 634174ms (Reason: transport close)
appears at the same time the other socket connects
[2024-08-01 15:37:29.634] INFO: [SocketAuthority] Socket Connected mLVeoTHmJB_uwAJVAAAH
Another socket
[2024-08-01 15:26:52.757] INFO: [SocketAuthority] Socket Connected IgXTfOG1_7JUmWhGAAAF
is active and should be syncing (should it not?) after this failed ping if that is what you're referring to. As I mention above in the mobile app the history for the audiobook showed a sync 2 mins after this socket connected. At 15:28 a sync occurs. Somehow this didn't proceed me to 78% but instead I remained at 76%. If I then click play I still am at 76% and have to find my way back.
@0verEngineer commented on GitHub (Aug 8, 2024):
I reported several sync issues in the past because i use audiobookshelf in the same way, they never got fixed properly. I would love a proper syncing solution. 👍
@Inevitable commented on GitHub (Aug 12, 2024):
I just left a comment over on the app repo so apologies for the cross-post, but I DO have a permanently online and reachable server, and still experience loss of sync in a similar manner. Essentially, the App (android in my case) doesn't check with the server before resuming playback, and in doing so overrides any progress that may have been made via the web player. The only solution is to 'force stop' the android app, which is not a normal workflow. Android doesn't have a default 'exit' or 'kill process' state when you change view away from an app, such as returning to your home screen without playback in progress.
The result of this is that selecting the app from your launcher or other method(notifications/home screen widget etc) doesn't mean it is a fresh instance, more likely unless you had done a reboot since last 'closing' the app, you'll be resuming it from a suspended state, and will lose any progress from outside the mobile app.
As others have mentioned, this is quite annoying when, for me at least, the key point to having a central server is to explicitly deal with syncing without having to manually scrub tracks and remember where I last left off!/
I don't claim to be any sort of expert here, but I'd think that a simple time signature attached to state updates, and a process for the mobile app to attempt a check to compare last state time with server, and respecting it if newer. A reasonable timeout or perhaps even user select-able retry count could alleviate cases of 'slow to resume'.
@DDriggs00 commented on GitHub (Oct 23, 2024):
To further reduce input lag, such a check could even be put behind a local timer, and not be triggered unless the audiobook had been paused for more than a certain amount of time.