mirror of
https://github.com/advplyr/audiobookshelf.git
synced 2026-05-30 23:40:40 +02:00
[Enhancement]: Finished podcast episode handling #370
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#370
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 @andonevris on GitHub (May 20, 2022).
Describe the feature/enhancement
I think we should have the ability to handle what happens once you have finished listening to a podcast episode, namely deleting media files either immediately or via a size quota.
Some podcasts are transient by nature so some media file management features would be very useful to clear out old files.
@advplyr commented on GitHub (May 20, 2022):
I agree. I think the same needs to be done with the mobile app but for locally downloaded episodes.
I'm hoping someone will volunteer to do a mockup of how this should all look and function. That is usually the hardest part for me, building it is the fun part.
@andonevris commented on GitHub (May 21, 2022):
I use antennapod for podcasts (open source) they handle finished podcasts well.
Global settings for storage:
Toggle switch to turn auto delete on off
Toggle switch to keep favourite episodes (need to be able to mark episode as favourite)
Toggle switch "Delete removes from queue" (once you build out the queueing of episodes it's useful to remove deleted episodes from that too)
Each podcast has its own settings:
Auto delete episodes checkbox with - "global default" : "always" : "never"
@shepda commented on GitHub (May 30, 2022):
Perhaps this feature needs to take multiple users into consideration because if a finished episode is deleted it may be deleted before other users have listened to it?
I think it would be nice if a finished episode is hidden from that user's Newest Episodes list.
@advplyr commented on GitHub (May 30, 2022):
Good point. I think this feature makes more sense on mobile devices then it does on your media folder.
I've already started adding a filter in the mobile app so you can default to filtering out finished episodes which I will also add to the web app.
@andonevris commented on GitHub (Jun 3, 2022):
Yeah having multiple users adds a level of complexity I hadn't considered.
Still I think it's still useful to be able to delete finished podcasts automatically even on your media folder, many podcasts are listen once episodes (daily news type stuff) keeping a backlog of that is not useful and actually becomes cumbersome to manage after a while, most podcast players include some sort of auto deletion functionality for that reason.
@advplyr commented on GitHub (Jun 3, 2022):
Most podcast players are mobile apps or don't have multi-user.
I'm thinking what we will do is the mobile apps will have settings for auto-deleting episodes. The server will have the filter to hide finished episodes and have the option to select multiple episodes and batch delete.
@Lebo77 commented on GitHub (Jul 5, 2022):
An ability of what order to show the podcast episodes by default would be smart as well. Some you want to go oldest-first. Others you want to see the most recent first.
An optional limit on the number of episodes, and which ones get deleted and when would be a good addition.
@advplyr commented on GitHub (Aug 20, 2022):
I was thinking of adding this for the next release then realized this will be problematic for a server with many users.
This might only make sense to do on mobile and remove the episode if it is downloaded on mobile.
@FuzzyMistborn commented on GitHub (Aug 20, 2022):
On mobile would be a great start. For the server that's a good point on multi user servers. Could it be added as a setting that could be enabled manually?
@advplyr commented on GitHub (Aug 21, 2022):
A setting that does what though? Which user would be the one that determines whether the item is finished and ready to remove?
@FuzzyMistborn commented on GitHub (Aug 21, 2022):
I guess there's no admin account?
@advplyr commented on GitHub (Aug 21, 2022):
There can be many admin accounts
@andonevris commented on GitHub (Aug 21, 2022):
In AB could we possibly make the podcast and the users subscribed to that podcast as separate entries?
For instance I add a podcast and only I am subscribed to it within AB. If other users want to listen to that podcast it already exists in AB so they can subscribe to it also.
This way we can have settings like "delete episode after last subscriber has listened"
IMO it's very unlikely all users will be interested in the same podcast, in my household there is no overlap in our podcast tastes at all, this way we can delete files once anyone interested has finished listening.
@advplyr commented on GitHub (Aug 21, 2022):
That seems very complicated in the current system of libraries and user permissions. Maybe, but not something I can picture right now.
@RandomWare commented on GitHub (Aug 25, 2022):
I second the filter option. I sometimes have a backlog of episodes built up. When I want to catch up I would ideally sort by release date and start playing the first episode in the list, which would be the oldest. When that episode is finished, the player would queue up the next one, and so on until there are no more unread episodes.
I am also a data hoarder, so would prefer not to delete old episodes, even if I've already listened to them. I was using podgrab until recently to automatically maintain a backup of my podcasts, but I've effectively replaced it with this app. However, since I don't want to delete the files, but also don't want to have them show up in the list of episodes when sorting by oldest first, it would be best to have a way to hide episodes that are already finished.
@gbakeman commented on GitHub (Aug 30, 2022):
I'd just like to add to this issue: I use ABS primarily as my personal podcast management system. I'd like it so that episode listen state is not tied to the episode file existing on the server, so I can clean up old episodes but still retain the metadata and listen state. Hoping this can be considered.
@advplyr commented on GitHub (Aug 30, 2022):
@gbakeman I'm not sure what you mean. Your listening progress if you are using the abs mobile app or the web client will always be tied to the episode on the server.
@gbakeman commented on GitHub (Aug 31, 2022):
The issue for me though is, when we "hard delete" a listened episode (only option to remove the actual file if I understand correctly), then any evidence that that episode was listened to is also gone (can't tell from the episodes list window anyways).
I think it's basically just how I'm used to most RSS reading apps - typically when you add a new feed, all of the metadata (or the last x entries) are downloaded and viewable, then you mark as read from the main view. Of course this is a different situation when dealing with actual files that you need to download, but my idea is that all (or x amount of) episodes in a given feed are viewable directly on the main interface, instead of needing to open the additional episode list window. You'd have various filters to make the list more manageable i.e hide listened, show only downloaded, etc. but otherwise the feed's list retains your watch status regardless of whether or not the file is stored on the server.
Hope I'm making sense and not trying to totally change up how ABS works. Thank you for your work!
@advplyr commented on GitHub (Sep 1, 2022):
It makes sense. I'm thinking we will remove the search for episode modal and just put the RSS feed in the same spot downloads are. Then the default view can be filtered for what you have downloaded but you can remove that filter and see the full RSS feed of episodes with download buttons.
@gbakeman commented on GitHub (Sep 1, 2022):
That sounds ideal. Do you want a separate issue opened for this or do you just want to track that here?
@advplyr commented on GitHub (Sep 1, 2022):
@gbakeman A new issue for this is a good idea. Thanks
@shepda commented on GitHub (Sep 22, 2022):
I can see that this has been implemented in the mobile app if you click on the podcast on the Library screen. I think it should also be added to the Newest episodes row on the Home Screen. Personally I use this row the most to listen to different podcast episodes in the order they were released.
@mcmikemn commented on GitHub (Apr 9, 2023):
Some use cases (like mine) are single-user, but even some cases with multiple users possibly want to auto-manage media. Does anyone actually keep all media forever? Why not add an option to groom media. If you want to keep all media, turn grooming off; if you want to delete media "after X Y has passed", turn it on (X could be a number and Y could be a length of time, e.g., X=6, Y=months - and you might even include a sub-option "groom even if not listened to?").
@Dragonatorul commented on GitHub (Apr 9, 2023):
Some of us at least try to keep it forever, with varying levels of success and investment. We're called "data hoarders", but some prefer the term archivists. Generally we're motivated by being burned one too many times when we remembered something interesting and went back to search for it, only to find it had been permanently deleted and irrevocably lost off the internet.
However, I agree that having the option to groom the server storage would be useful, even for data hoarders, if we wish to selectively archive, or, gods forbid, be forced to choose which parts of our library we can keep due to space and financial limitations.
Such a feature would thus need to be controlled by the server only, and be possible to configure globally and on a per-library and even per-library item basis in the case of podcasts.
I also agree that there is a need for such a feature for the mobile app to manage the local mobile storage As long as this is clearly detached from the server file management and would not impact server availability of files.
Additionally, there could be a retrieval and temporary on-demand storage feature. For example, if a podcast episode has been deleted locally as part of the standard cleanup configuration, but is requested by a user, even off a mobile client, then it can be downloaded again and stored for a period of time, or at least until that particular user no longer needs it. In effect acting as a cache proxy server.
@alfureu commented on GitHub (Jan 13, 2024):
I would like to chime into this discussion as well. Just facing the same thing. There are podcasts that I do not want to keep, other podcasts I would love to keep.
I noticed that there are icons on the 3 corners of the cover in ABS, maybe the 4th corner can be used to trigger the keep option?
@MrSimmo commented on GitHub (Jan 14, 2026):
Hi all,
I also would really like this feature. In the meantime, I have written a python script that can look for finished items and then delete them. You can also add a tag to the show to tell the script to ignore it (i.e. not delete it).
https://github.com/MrSimmo/audiobookself_auto_purge
It has the ability to filter on media type, age of media, ignore specific shows/titles etc.
@evanpeterjones commented on GitHub (Apr 15, 2026):
Chiming in with my thoughts and suggestions based on a different use case and solution.
Essentially I like the existing "Max # of episodes to keep" feature, and think it should be expanded with a Global Default and "Favorites" feature to circumvent auto-deletion.
Whether you or any user has played an episode should be irrelevant as to whether it's deleted if it is above this max.
I use Audiobookshelf both to archive limited-series fiction podcasts (ever since Homecoming went defunct and is now gone forever), as well as listen to plenty of weekly topical podcasts that I have no interest in archiving Gigabytes of episodes of forever.
My suggestion/ideal solution would be to add a global default for the existing, "Max # of episodes to keep" option and then to just add an override for this deletion process--there are two options for this that I see...
I prefer the 1st option because it provides more flexibility to save particular episodes, but I can understand how implementing a new Favorites feature might be more of a haul in terms of development.