Antennapod: downloaded episodes are autodeleted

[FreaxMATE]

App version: 1.7.3c (F-Droid)

Android version: 7.1.2 using /e/ OS (https://e.foundation/) lineage OS + microg

Device model: Google Nexus 5

Expected behaviour: downloaded podcasts are not deleted after finished hearing

Current behaviour: although auto deletion of episodes is disabled under settings, downloaded podcasts will be deleted some time after you finished hearing it. (doesn't work either when disabling autodeletion for every single subscription)

First occurred: noticed it months ago

Steps to reproduce: turn off auto deletion (if you selected it before) and then check whether downloaded podcasts remain

[ByteHamster]

There currently is a bug. Try to enable auto download, then select Cleanup » Never erase episodes, then disable auto download again.

[FreaxMATE]

There currently is a bug. Try to enable auto download, then select Cleanup » Never erase episodes, then disable auto download again.

Ok, thank you! Working so far.

[orionlee]

FYI, I don't face the problem. The following is my settings.

App Version: v1.7.3b based custom build
Android OS: 7.1.2
AntennaPod Settings:

• Storage > auto Delete : disabled
• Network > Automatic Download : enabled
• Network > Automatic Download > Episode Cleanup : 12 hours after finishing

[ByteHamster]

The problem here is that auto download in settings is a master switch for cleanup. When AntennaPod cleans episodes, it does not care about the master switch. It just deletes episodes, respecting the "episode cleanup" setting, but not respecting the fact that the whole settings section is disabled.

[orionlee]

Ah, got it. I can probably fix it sometime next week if nobody is on it.

[orionlee]

The issue is identified that when user taps to download an episode, the codepath involved, DBTasks.downloadFeedItems(), will try to delete 1 episode:

performAutoCleanup is always true for user-initiated downloads
https://github.com/AntennaPod/AntennaPod/blob/641ee60cbf7404530e26dcef2927910dcc34e840/core/src/main/java/de/danoeh/antennapod/core/storage/DBTasks.java#L341-L351

I'd propose we fix it after PR #2714. The follow-up PR, based on https://github.com/orionlee/AntennaPod/compare/f0c9089c78dd82fd99933c1f1be72d991c425f36...affdd8337897bd3b8daa30760d8a65dca1aaa3f1, refactors the same code path. It's more convenient to do it there (or after it).

[orionlee]

Looking at the codes, it looks like at some point in the past, auto episode cleanup is meant to happen when any types of download happens, be it user-initiated or auto-downloaded.

At present, the Settings UI presents auto-cleanup as part of auto-download only.

We have two options:

1. Honor the present Settings UI, and change the logic so that auto episode cleanup is done as part of auto download only.
2. Change the Settings UI to make auto episode cleanup as a settings of its own, independent of auto download (that's what the codes actually do right now).

If we peruse choice 2, the UX / feature needs to be further defined. At the minimal, we probably should combine auto episode cleanup with Storage > Auto Delete.

[ByteHamster]

If we peruse choice 2, the UX / feature needs to be further defined. At the minimal, we probably should combine auto episode cleanup with Storage > Auto Delete.

I would be happy about a rework there. Users always confuse those two settings. Not sure how it could work from an ux perspective. Might be good to have an "Automation" preference screen with auto download, auto feed update, auto delete. The auto feed update dialog has been bothering me for quite some time. I think a screen with a Master switch would be better there, too. I, personally, do not use automation at all, so I am not too motivated to do a rework myself.

[orionlee]

I might give it a try to think through and propose a rework later, time permitting.

[ByteHamster]

When thinking about a redesign, it would be great if we could also consider #2077. We should probably discuss the conceptual/UI changes before implementing. This might even need UI tests with real users to get it right. (I did some UI tests in the past few weeks. They help a lot to understand why AntennaPod is so hard to use for new users. Some of the feedback is already implemented)

[Pentaphon]

We should probably discuss the conceptual/UI changes before implementing

An easy way to do this is to simply emulate the UI of an existing podcast client that users actually like using and isn't too complex to emulate. The simpler, the better. No need to come up with new UI ideas. I think Podcast Republic with the bottom button UI seems to be the easiest and most satisfying to use, according to what I've seen. I think the issue with Antennapod is that there's too much going on in the hamburger sliding menu, an old UI notion from Holo, while modern apps are moving to bottom-button UI to deal with the increasingly large and tall phone screens that people demand.

[Pentaphon]

Will this issue be moved to a 2.0.0 milestone since @ByteHamster said that's the next version or do we still have 1.8.x versions to come?