[Enhancement]: Allow user to view their listening sessions for a particular book

[ZLoth]

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]

This functionality currently exists in the Android player under History, so this is essentially a feature parity request.

[advplyr]

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]

The mobile app view is very different than what we would support in the listening sessions section of the web client.

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.

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.

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]

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.