mirror of
https://github.com/advplyr/audiobookshelf.git
synced 2026-05-30 23:40:40 +02:00
[Enhancement]: Allow user to view their listening sessions for a particular book #2475
Assignees
adam (Adam Melkus)
Clear assignees
adam (Adam Melkus)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: starred/audiobookshelf#2475
Reference in New Issue
Block a user
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 @ZLoth on GitHub (Jan 9, 2025).
Type of Enhancement
None
Describe the Feature/Enhancement
Allows users to view their listening session for a particular book and be able to begin/end playback at a time stamp rather that by a chapter.
Why would this be helpful?
Some audiobooks have very long chapters (sometimes over an hour long), or if it is a dramatized audio, may not have any chapters at all. If would enhance functionality if I fell asleep while listening to an audiobook, and pick up where I originally started. This is in addition to the existing sleep timer functionality.
Future Implementation (Screenshot)
After clicking on the appropriate icon on the web page, user can see the following menu:
They can begin playback by clicking on the time or playback icon
Audiobookshelf Server Version
2.17.7
Current Implementation (Screenshot)
@ZLoth commented on GitHub (Jan 26, 2025):
This functionality currently exists in the Android player under History, so this is essentially a feature parity request.
@advplyr commented on GitHub (Jan 26, 2025):
The mobile app view is very different than what we would support in the listening sessions section of the web client.
The "history" page is meant to show all pause/play/seek & sync actions that occurred for that item. That data is stored locally on the device and I don't think it would be a good idea to send all of that data to the server. Although I can see how it would be useful we already need to work on reducing the amount of data being sent & received.
@ZLoth commented on GitHub (Jan 26, 2025):
I understand @advplyr . When I was writing up the original feature request, I was pulling my hair out swearing that I saw something similar already as the "inspiritation from", but I could not locate it. I hit across it this morning and thought I would amend the request.
My data is unlimited for both my local internet and my mobile data, and really doesn't matter if I'm on my local Internet. Having said that, some other users of ABS may not have that luxury.
Having said that, there have been instances of user error where I was listening to a book, and was scanning the chapter list, only to accidentally touch the chapter and go either much earlier in the book or much later in the book, and there has to be an easier way to get back to where I was originally before my accidental keypress.
@advplyr commented on GitHub (Jan 26, 2025):
It's not just about using data in the mobile plan. Managing syncing this data is challenging since users are not always online while listening. Then storing every pause/play/seek action in the database for every user is excessive.
I hope to re-factor the mobile logic that handles syncing and maybe after that is done syncing more information can be considered.
For a related example, some users want to have all their playlists, collections, series, etc. available offline for their downloaded content. That requires keeping that data stored locally on the device and in sync with the server. While I'm not in favor of building all of that out we can improve the offline experience if we can improve the mobile apps ability to sync data with the server.
The mobile app has been through many iterations. It has been around before there were libraries, podcast support, offline listening, listening sessions (previously only media progress), and on and on. Through those changes the mobile app never got properly refactored.
Back on the topic of the original request and issue you raised about accidently clicking a chapter. A possible solution could be to have the web client store in the browsers IndexedDB the play/pause/seek actions. Instead of syncing every action to the server, each client manages their own recent actions that can be referred to in the case of accidental misclicks.