starred/audiobookshelf-advplyr

Fork 0

mirror of https://github.com/advplyr/audiobookshelf.git synced 2026-03-02 22:46:55 -05:00

[Enhancement]: Keep Track of Completion Status for Deleted Assets #2064

New issue

Open

opened 2026-02-20 10:15:28 -05:00 by deekerman · 5 comments

deekerman commented

2026-02-20 10:15:28 -05:00

Owner

Originally created by @aureateflux on GitHub (Jun 18, 2024).

Type of Enhancement

Web Interface/Frontend

Describe the Feature/Enhancement

Currently it seems that once an asset (audio book, e-book, or podcast) has been deleted, ABS is entirely agnostic to that asset and does not retain progress or completion information.

Instead, ABS should retain information about previously deleted assets.

Why would this be helpful?

It would enable better tracking of completed media both inside ABS and with other apps (such as RYOT) that may use the API to pull progress information
It could prevent users from re-downloading consumed media that they don't intend to consume again. (In the case of books, you may not remember which book you left off in a series, for example)
Users who don't want to hoard data but still want to be able to track completion would be able to do so

This is obviously more useful with podcasts due to the auto-delete option for podcasts, but I think it makes sense with the other media as well, especially for users who fall into case #3.

Future Implementation (Screenshot)

Media profile pages would include a list of historical files associated with that media. For example, books would not disappear once the file has been deleted (like how authors aren't removed if all their books get deleted). Instead, a new expandable list similar to "Library Files" called "Historical Files" would contain a list of files related to that book along with completion status. Podcasts would include an episode list that notes episode completion as well as an indicator of whether the episode file still exists on the server.

Audiobookshelf Server Version

v2.10.1

Current Implementation (Screenshot)

I was noticing that on the Podcast page I can only see the current files for that podcast even though I know I have listened to many more episodes than are displayed. It occurred to me that this list is basically useless for the purposes of knowing anything about your history with that podcast.

Since I do think knowing what episodes you have and have not seen is useful (for example, figuring out whether you might have missed an episode), I think it would be better to expand on this feature to make it more useful.

Originally created by @aureateflux on GitHub (Jun 18, 2024). ### Type of Enhancement Web Interface/Frontend ### Describe the Feature/Enhancement Currently it seems that once an asset (audio book, e-book, or podcast) has been deleted, ABS is entirely agnostic to that asset and does not retain progress or completion information. Instead, ABS should retain information about previously deleted assets. ### Why would this be helpful? 1) It would enable better tracking of completed media both inside ABS and with other apps (such as RYOT) that may use the API to pull progress information 2) It could prevent users from re-downloading consumed media that they don't intend to consume again. (In the case of books, you may not remember which book you left off in a series, for example) 3) Users who don't want to hoard data but still want to be able to track completion would be able to do so This is obviously more useful with podcasts due to the auto-delete option for podcasts, but I think it makes sense with the other media as well, especially for users who fall into case #3. ### Future Implementation (Screenshot) Media profile pages would include a list of historical files associated with that media. For example, books would not disappear once the file has been deleted (like how authors aren't removed if all their books get deleted). Instead, a new expandable list similar to "Library Files" called "Historical Files" would contain a list of files related to that book along with completion status. Podcasts would include an episode list that notes episode completion as well as an indicator of whether the episode file still exists on the server. ### Audiobookshelf Server Version v2.10.1 ### Current Implementation (Screenshot) I was noticing that on the Podcast page I can only see the current files for that podcast even though I know I have listened to many more episodes than are displayed. It occurred to me that this list is basically useless for the purposes of knowing anything about your history with that podcast. Since I do think knowing what episodes you have and have not seen is useful (for example, figuring out whether you might have missed an episode), I think it would be better to expand on this feature to make it more useful.

deekerman added the

enhancement

backlog

labels

2026-02-20 10:15:28 -05:00

deekerman commented

2026-02-20 10:15:29 -05:00

Author

Owner

@nichwall commented on GitHub (Jun 18, 2024):

@nichwall commented on GitHub (Jun 18, 2024): Related to https://github.com/advplyr/audiobookshelf/issues/2595 https://github.com/advplyr/audiobookshelf/issues/963 https://github.com/advplyr/audiobookshelf/pull/1047

deekerman commented

2026-02-20 10:15:29 -05:00

Author

Owner

@advplyr commented on GitHub (Jun 18, 2024):

I'm pretty sure there is an open request for this for podcasts also or I know it has been discussed before. For books this is difficult since we can't rely on a universal identifier as well as you can for movies/tv series.

@advplyr commented on GitHub (Jun 18, 2024): I'm pretty sure there is an open request for this for podcasts also or I know it has been discussed before. For books this is difficult since we can't rely on a universal identifier as well as you can for movies/tv series.

deekerman commented

2026-02-20 10:15:29 -05:00

Author

Owner

@aureateflux commented on GitHub (Jun 18, 2024):

I didn't find one when I did a search before creating it, but if someone links it I'm happy to move my comments over there.

I think I saw or participated in a discussion about this on Discord a while back. Someone said it would be hard and wasn't on the roadmap, but I should check out RYOT.

So I did, and found that RYOT couldn't import everything from ABS, partly because of this issue. The maintainer of RYOT was interested in improving the ABS importer, but this was a limitation that we ran into once he got podcasts importing.

This is definitely more of a concern with podcasts because they are likely to have the auto-delete set in the scheduler. That said, is it possible to just have an internal identifier for books where an ISBN is not available? It would really just need to be internally consistent to that server, right?

@aureateflux commented on GitHub (Jun 18, 2024): I didn't find one when I did a search before creating it, but if someone links it I'm happy to move my comments over there. I think I saw or participated in a discussion about this on Discord a while back. Someone said it would be hard and wasn't on the roadmap, but I should check out RYOT. So I did, and found that RYOT couldn't import everything from ABS, partly because of this issue. The maintainer of RYOT was interested in improving the ABS importer, but this was a limitation that we ran into once he got podcasts importing. This is definitely more of a concern with podcasts because they are likely to have the auto-delete set in the scheduler. That said, is it possible to just have an internal identifier for books where an ISBN is not available? It would really just need to be internally consistent to that server, right?

deekerman commented

2026-02-20 10:15:29 -05:00

Author

Owner

@IgnisDa commented on GitHub (Jun 18, 2024):

Another idea to create consistent identifiers for books/podcasts is using MD5/SHA256 on the files. If the same media is downloaded again, it will have the same hash again.

@IgnisDa commented on GitHub (Jun 18, 2024): Another idea to create consistent identifiers for books/podcasts is using MD5/SHA256 on the files. If the same media is downloaded again, it will have the same hash again.

deekerman commented

2026-02-20 10:15:29 -05:00

Author

Owner

@nichwall commented on GitHub (Jun 18, 2024):

Hashes have been discussed a few times on Discord and in at least these issues (I think there's more but can't find them) https://github.com/advplyr/audiobookshelf/issues/2551 https://github.com/advplyr/audiobookshelf/issues/2509

@nichwall commented on GitHub (Jun 18, 2024): Hashes have been discussed a few times on Discord and in at least these issues (I think there's more but can't find them) https://github.com/advplyr/audiobookshelf/issues/2551 https://github.com/advplyr/audiobookshelf/issues/2509