[Enhancement]: Finished podcast episode handling

[andonevris]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

A setting that does what though? Which user would be the one that determines whether the item is finished and ready to remove?

[FuzzyMistborn]

I guess there's no admin account?

[advplyr]

There can be many admin accounts

[andonevris]

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]

That seems very complicated in the current system of libraries and user permissions. Maybe, but not something I can picture right now.

[RandomWare]

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]

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]

@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]

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]

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]

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.

That sounds ideal. Do you want a separate issue opened for this or do you just want to track that here?

[advplyr]

@gbakeman A new issue for this is a good idea. Thanks

[shepda]

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.

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]

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]

Does anyone actually keep all media forever?

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]

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?