More extensive Cleanup settings

[keunes]

Current (as per #1241)

Enhencement

A bit more flexibility in these settings could be nice:

Remove episodes:

• After: [radio buttons]
  • completing playback [default]
  • pausing(/skipping) or completing playback
• With a delay of: [dropdown]
  • 0 days (immediately)
  • 1 day [default]
  • 3 days
  • 5 days
  • 7 days
• But exclude: [checkboxes]
  • favourites [default: Y]
  • episodes in the queue [default: Y]

The advantage of adding 'remove after pausing' is that if you loose interest of an episode and tap 'next' halfway through, these episodes can be automatically deleted after a while and won't take up memory space indefinitely.

What if you just pause and want to listen to an episode later again?
Because many people just pause an episode with the intention to listen to it again later, this option should not be the default. In practice, this setting I imagine will almost always be applied in combination with a delay of a couple of days; when the episode has not been restarted after those days, there's probably a lack of interest (this would be my use case, with a setting of 5 days).

inspiration
Use-case of @charlesay in #1262.

[mfietz]

Just a thought: Maybe skipping an episode would just extend the set delay. Something like "Skipping an episodes extends the delay by half, but at least 1 day." (Either at the bottom of this dialog or we have some (i) button somewhere that shows this information... somehow... The preference summary is probably the best place)

Having the option to not exclude favorites and queued episodes seems rather useless to me. The number of people that actually use auto delete, do use favorites and do want their favorites to be deleted automatically is probably very small.
Something in the queue should not be deleted, either. Exceptions do not really make sense to me.

[keunes]

Extending delay after skipping
That's a nice idea. Actually we'd need a delay of 1/2 day after pause as well, otherwise a pause may accidentally lead to deletion whilst playback would be resumed in an hour or so. What do you mean with the 'at least one day'? Why would we have that?
If there's space in the dialog I would include any info it right there (it is useful to be presented when you actually change the setting), otherwise just in the preference summary.

Concerning the exclusion options
to me, auto cleanup us simply about freeing up space. I want AP to be able to download the latest stuff, but not have the amount of episodes on my phone exceed the 25 that I set in the Episode Cache settings (because that means that I can't update my apps anymore).

Excluding favourites
When I make an episode a favourite (when the future comes available), I think 'I really like this and may want to come back to this later to listen again or to show it to others'. It doesn't mean I want to listen to it again tomorrow, or the next days. Thus to me, the episode should automatically be deleted (as in the file): keeping the file unnecessarily takes up space from newly released episodes that would otherwise be automatically downloaded.
Imagine that throughout time I have indicated 24 favourites. Without manually deleting those files, there will not be space for new episodes.

Excluding queued episodes
I see that is less logical here; why would episodes in the queue be eligible for deletion? Imagine you have a s***load of episodes in your queue (because you always want to have the latest items, and fool yourself thinking that one day you'll listen to them), but that you don't want all those files on your phone due to space restrictions.
Now too, you can manually delete episodes(' media files) while keeping them in the queue.

Shortcoming in my proposal (?)
Currently there's an option 'When not in queue'. What does that option imply, actually? That when an episode has not been played and is not in the queue, it is eligible for deletion? If so, I don't think that's possible with my proposal. An option would be to add "downloading" in the "After" section.

[mfietz]

That's a nice idea. Actually we'd need a delay of 1/2 day after pause as well, otherwise a pause may accidentally lead to deletion whilst playback would be resumed in an hour or so. What do you mean with the 'at least one day'? Why would we have that?

Basically what you just said. When delay would else be below one day (e.g. immediately), the delay will be at least 1 day nevertheless.

If there's space in the dialog

Dialog says no. (Little Britain, anyone? https://www.youtube.com/watch?v=0n_Ty_72Qds#t=6)

Imagine you have a s***load of episodes in your queue ... , but that you don't want all those files on your phone due to space restrictions.

What about not downloading them in the first place? ^^
People should really learn to keep their things in order. I really don't think it is our fault if someone is a podcast hoarder ;)

Currently there's an option 'When not in queue'. What does that option imply, actually? That when an option has not bee played and is not in the queue, it is eligible for deletion?

Yes. Playback state doesn't matter, if it is not in the queue (and not a favorite), it can be deleted.

[keunes]

haha :)

about the delay: I thought you meant "always add a delay of half a day, but let the minimum delay be 1 day". Whereas I would go for "let the minimum delay be 1 day" (or "always add a delay of half a day"). So I wondered 'why have both'. It saves space explaining either compared to a combination of both ;)

about not downloading episodes: so if I want episodes to be automatically added to my queue, without actually downloading them, I don't think I'm capable now ;) But yeah, I guess that option can be left out.

So that leads us to the following proposal:

Remove episodes:

• After: [radio buttons]
  • completing playback [default]
  • pausing(/skipping) or completing playback **
  • downloading **
  • never
• With a delay of: [dropdown]
  • 0 days (immediately)
  • 1 day [default]
  • 3 days
  • 5 days
  • 7 days
• Exclude favourites [checkbox, default=Y]

** After pausing, skipping or downloading an episode, a minimum delay of 1 day will be applied.

Description: Episodes that aren't in the queue will automatically deleted under certain circumstances. After pausing, skipping or downloading an episode, a minimum delay of 1 day will be applied.

[mfietz]

What do you think "at least" means? :>
According to http://www.dict.cc/?s=mindestens "at least" and "at the minimum" are synonyms

[keunes]

I know what 'at least' means, but what you suggested is, or at least this is what I understood (based on "extends the delay by half, but at least 1 day"):

• setting = 0 days -> 1 day
• setting = 1 day -> 1,5 days
• setting = 3 days -> 3,5 days
• etc

What I suggest is (based on "minimum delay is 1 day"):

• setting = 0 days -> 1 day
• setting = 1 day -> 1 day
• setting = 3 days -> 3 days
• etc

Subtle, but different ;)

[mfietz]

What I meant:

• 0 days [immediately] -> max(1, 1,5*0) = 1 day
• 1 day -> max(1, 1,5*1) = 1,5 days
• 3 days -> max(1, 1,5 * 3) = 4,5 days
  and so on

Maybe more clearer: "Skipping an episodes extends the delay by half [of its length?], but at least by 1 day."

[keunes]

Ah, right. Well. A simple minimum delay of 1 day would be sufficient in my view.

[Matth7878]

I don't understand why there is a need to extend delay ? When choosing to delete episode after pausing delay should start after last pause.
Supposing my cleanup delay is 1 day, If I pause an episode at 8 pm, resume playing and pausing it again at 10 pm then episode should be cleaned up next day at 10 pm and not 8 pm.

[keunes]

Although as said, I don't think extended delay is necessary (as I would use more conservative delay values), one could argue the following:
Normally an episode can be deleted rather quickly, ie with a short delay. Chances are though that when playback is paused, it resumes only after a longer period.

In my use case: I pause episode A, skip to next and start the queue from episode B, C, etc; only to go back to episode A two days later. While I like to get rid of episodes 1 day after I've finished playback, this may lead to unwanted deletion of a paused episode.

It simply is likely that you want to retain episodes longer if they're paused then if they've been finished listening, because you may still want to listen to them (whilst that's not the case for other episodes).

[TomHennen]

I think there's value in 'remove after pausing', it certainly would fit my workflow. HOWEVER, I'd prefer to keep things simple. The update in #1241 resolved some issues where you'd remove something from the queue, but then it would sit around forever. The only solution was multiple clicks to make sure the item was actually deleted. Having an option to delete things that aren't in the queue is essential in my opinion. It fits with the workflow for AP that I use, and that I think we want to push others to use. Namely, the queue has things I want to listen to. If it isn't in the queue, I don't care about it.

I could see changing the current setting where we remove when playback completes to removing after the episode hasn't been listened to in a certain amount of time (or adding a couple of options to the dialog that did this).

I'm very reticent to create a complicated dialog to handle all of these other cases.

Regarding keeping favorites, there are already options to have something marked as a favorite and not having the episode taking up space (a user can just delete the episode while it's marked as favorite). One of the reasons for introducing favorites is that some users wanted the ability to keep some episodes forever.

Regarding extending the delay for certain actions, I'm not sure how we'd implement that. The DB stores when the episode completed playback and (thanks to a recent PR) when the episode was last paused. We don't have any fields that say when it was last skipped and I'm not sure it's worth adding that field. It also makes it harder to explain to users exactly when stuff will be deleted.

[Matth7878]

Regarding skipped episode I don't think there is a need to track when skipped because there is 2 possibilities :

• if keep episode skipped is checked then it should pause episode and so db should have a last paused time
• or if episode are not kept then episode should be marked as completed and db should have a completed time

In fact there is another possibility : option to keep episode but when skipping auto mark episode as read (if there was less than a certain amount of time remaining) has been triggered. In this case skipped episode should be marked as completed and removed from queue.

[TomHennen]

Your second option already exists. Smart Mark as Played.

On Thu, Oct 22, 2015, 12:45 AM Matth78 notifications@github.com wrote:

Regarding skipped episode I don't think there is a need to track when
skipped because there is 2 possibilities :

• if keep episode skipped is checked then it should pause episode and
  so db should have a last paused time
• or if episode are not kept then episode should be marked as
  completed and db should have a completed time

In fact there is another possibility : option to keep episode but when
skipping auto mark episode as read (if there was less than a certain amount
of time remaining) has been triggered. In this case skipped episode should
be marked as completed and removed from queue.

—
Reply to this email directly or view it on GitHub
#1275 (comment)
.

[Matth7878]

I know this option exist. What I meant was that skipped episode should be treated as :

• paused if "keep skipped episode" is on and "smart mark as read" has not been triggered
• or completed if "keep skipped episode" is off or if "smart mark as read" has been triggered

[keunes]

I could see changing the current setting where we remove when playback completes to removing after the episode hasn't been listened to in a certain amount of time (or adding a couple of options to the dialog that did this). [@TomHennen]

Do you mean replace the current option? If so: Why not add? In my view, these two different options (remove after completed playback & remove after episode hasn't been listened to in a certain amount of time) both have value.

Regarding keeping favorites, there are already options to have something marked as a favorite and not having the episode taking up space (a user can just delete the episode while it's marked as favorite). One of the reasons for introducing favorites is that some users wanted the ability to keep some episodes forever.

If you don't have automatic deletion for the media file of favourite episodes, then for these you'll be thrown back to the previous situation where you manually have to remove individual files.
Some users want to keep the episode files forever, some just want to keep the reference forever. Why not cater for both. (I'm assuming here that this option is about deleting media files, leaving anything else intact)

Simplifying my proposal: 'orphaned episodes'
In my last proposal, I had "delete after" with the following options:

• "pausing(/skipping) or completing playback"
• "downloading" (episodes that have not been played and aren't in the queue, are eligible for deletion)

Merging them makes no difference in functionality but makes it easier for the user (less options, vague option 'delete after downloading' removed).
In 'formula': if min(time passed since downloaded, time passed since last paused) > delay ordered by user; then episode is eligible for deletion

Delete episode files:

• After: [radio buttons]
  • completing playback [default]
  • completing playback and being orphaned
  • never
• With a delay of: [dropdown]
  • 0 days (immediately)
  • 1 day [default]
  • 3 days
  • 5 days
  • 7 days
• Exclude favourites [checkbox, default=Y]

Description: Episodes that aren't in the queue will automatically deleted under certain circumstances. For orphaned episodes (those paused, skipped, or downloaded without being played), a minimum delay of 1 day will be applied.

[TomHennen]

With regard to favorite episodes, I meant the user can delete the media file while it remains in favorites. There should be nothing else for them to do. It does occur to me that there is no long press option to remove an episode from favorites. So maybe that's something that should be done.

Regarding what you're proposing. That is more complicated. At the moment there are 7 options. That's a lot, but not too many to cover the entire screen. With what you're proposing the user would click to set the option and see a dialog with many different options. That may very well be visually intimidating.

Not only is it more complicated for the user, it's also much more complicated to implement. Someone needs to create a dialog box that does all of those things and tests all of those options. That's a non-trivial amount of work. It's something that I don't really have time for at the moment (depending on how my week is going I often barely have time to respond in writing to the issues posted here).

If someone were to submit a PR with this functionality, we might entertain the idea. But we really are trying to keep AntennaPod fairly simple and straightforward, too many options makes that more difficult. In some ways, the option as it's currently implemented is more difficult than I really wanted. I had initially wanted it to only keep things that are favorites or in the queue and only give the user an option to turn that off.

[keunes]

Ok, short response (well, at least I tried ^^):

With regard to favorite episodes, I meant the user can delete the media file while it remains in favorites. There should be nothing else for them to do.

Not sure if we're on the same wavelength regarding the favourites (don't really get what you mean with the last sentence above), but never mind.

With what you're proposing the user would click to set the option and see a dialog with many different options. That may very well be visually intimidating.

Agree. But if put in a regular settings screen (like 'Customise navigation drawer' or 'Automatic download'), I think it's o.k. in terms of complexity, comparable to the screens I just mentioned. For me personally I think my proposal would make things simpler if it replaces/merges 'Auto delete' and the new 'Episode cleanup' (which to me are somewhat overlapping and their differentiation and working isn't really clear to me, though maybe that'll change once I actually get to use it).

Not only is it more complicated for the user, it's also much more complicated to implement.

I do see that. I wouldn't give it high-priority either, so maybe for now just add or replace 'needs info' with the enhencement/needs work/feature request label and retain the issue for later or other developers.

[maltfield]

I have a request for (what I imagine is a popularly desired) functionality that doesn't appear to be implemented in any actively maintained FOSS android podcast software:

I'd like to have new episodes of the podcast automatically downloaded. And I'd like those episodes to be automatically deleted X days after they're published.

Alternatively, replace "And I'd like those episodes to be automatically deleted X days after they're published" with "And I'd like to retain only X count of the most-recent episodes downloaded, deleting older episodes to make room for the new ones." Because the podcast I'm thinking of is published daily, it's the same thing for me. But feel free to implement whichever is easier or better for UX.

It's really shocking to me that there's no FOSS android podcast app on F-Droid with this functionality. Is it possible to be implemented on AntennaPod?

To describe my use-case more specifically: I have a video news show that I like to watch. They publish a new video podcast every day. The videos 1-hour long and are ~250 MB in size. I like to watch the video in the morning after waking up while showering, brushing my teeth, making/eating breakfast, etc. But because the video is so big, it sometimes doesn't finish downloading until after I'm done with my morning routine. Therefore, I'd like the podcast app to download it automatically while I sleep so it's finished downloaded by the time I wake up.

Moreover, some mornings I just oversleep or am in a rush, so I'd like it to keep a few days worth of the podcast's episodes. But because the size is so big, I'd like it to only keep a few (user-configurable) episodes (probably 3-7-ish episodes). I'd like it to delete these older episodes to make space for newer episodes even if I didn't get around to watching a given episode.

Ideally, the number of days to keep a given podcast's episodes would be configurable and specific to each podcast (so one news show that's audio-only, shorter, and smaller, I may want to keep 30 episodes of before auto deleting, but another podcast that's longer and bigger, I may want to keep only 3 episodes of before auto deleting). But I consider per-podcast retention setting to be optional as I'm sure it adds a lot of complexity.

Is this possible? Also, should I create a distinct issue for this specific request?

Thank you.

[ByteHamster]

Most of this is already supported. The remainder mainly is a usability problem, not a functional problem. The usability issues around automatic cleanup are already tracked in #4795. Closing to keep the discussion in one place.