Add option to automatically mark filtered episodes as played

[matejdro]

Currently, all episodes filtered by the episode filter are not downloaded, but they still remain in the feed.

This PR adds an option to the filter dialog to also automatically mark all excluded episodes as played.

[keunes]

Hello,

Thanks for creating a PR, and being willing to contribute to AntennaPod! For future reference, we always recommend checking in with us (or any project team, for that matter) before you develop something. That reduces the risk of doing work that won't be merged in the end.

Now, concretely abou this enhancement: I think it makes sense, but I think this should only be implemented together with #5237. Because the past year we've moved away from 'mark as played' in some cases (reasons in the linked issue) and this PR would be a move in the opposite direction.

[matejdro]

Thanks, will try to create issues in the future.

If I understand #5237 correctly, it would just introduce new status? So we could merge this in and after new status is ready, we just change the code to mark it as ignored instead of played?

[ByteHamster]

So we could merge this in and after new status is ready, we just change the code

To be honest, I don't really like that approach. It gets people to use the "wrong" approach to episode states.

I am not entirely sure why this feature is needed. If you filter the screen, you can use multi-select to mark all as played. This "mark all as played" is more or less a one-off action. As soon as it was executed once, it is not really needed anymore, because the episodes already are marked as played. I think having to press 2 more buttons to enter multi-select is reasonable - it is important that we do not overflow the UI with rarely used features because that makes it harder to use for everyone.

[matejdro]

Without that feature, I need to periodically do manual chore and manually mark all excluded episodes as played. Technology should be all about helping us reduce manual chores and this feature does that by automatically marking unwanted episodes as played.

[ByteHamster]

Maybe I just don't understand your use-case. Why do you need to manually mark hidden episodes as played?

[matejdro]

If there is no automatic mark as played on excluded episodes (this PR), excluded episodes will remain in my feed. If I want a clean feed, there is no other way rather than manually mark all of excluded episodes as played.

[ByteHamster]

excluded episodes will remain in my feed

Why do they remain? Don't you have a filter set up? Then they already are hidden, so no need to additionally mark them as played.

[matejdro]

I think we might be talking about different sorts of filters here?

I'm taking about include/exclude filter inside podcast setting where you can include only episodes containing any of the listed terms. These only stop the download, they do not hide the episodes, as far as I can tell. Maybe there is another toggle I need to switch?

[ByteHamster]

I think we might be talking about different sorts of filters here?

Ooh, right. I hadn't looked at the code before. Then this seems to be similar to #531. Automatically marking episodes as played/ignored, so you can later hide those with a filter feels like a workaround. Maybe it would be better to change the filter, so it directly hides them. That way, the filtering can be undone easily. That could be quite a difficult change, though, because we would need to adapt basically all database access operations. So maybe the easier option would indeed be what you suggest - marking as "not interested" automatically. This also ties into the whole auto-download discussion. I guess we need some UX mock-ups and design work to decide what works best.

[matejdro]

Yea, while directly hiding would be an ideal outcome, it is a lot of work.

On the other hand, we already have the filtering in the app, it just only affects downloads, so #531 is practically 90% done. Only thing needed is to push the filter further past the downloads, which this PR does.

Just marking as played/ignored/not interested instead of outright hiding is also beneficial, because it can be undone later in case you want to access the episodes.

[ByteHamster]

Just marking as played/ignored/not interested instead of outright hiding is also beneficial, because it can be undone later in case you want to access the episodes.

It can't really be undone. Then some episodes are marked as ignored because you did so manually, and some episodes are marked as ignored because the filter did so automatically. Changing the filter then does not un-hide these episodes. A proper filter can be adapted without having to go through the list again.

[matejdro]

But the point is that episodes are still there, they are just ignored. So a simple switch somewhere that toggles display of ignored episodes would allow you to undo this.

[jstetten]

For what it's worth, I have the same use case as @matejdro. I set up a filter for one news podcast that breaks up their broadcast into 15—20 short episodes a day. The filter works great in this situation; nonetheless, every day I still have to go through and manually mark all the non-downloaded episodes as played. At the very least, I wish unplayed episodes would be removed from my Inbox, because I use a carefully-crafted exclusive filter so have already (pre-)decided what to do with them.

In this case, I don't care if they're marked as "played" because I literally never want to see them again, but in general I'm quite looking forward to an additional "ignored" status (I would prefer "archived", but no matter), because I have thousands of unplayed or partially played episodes and until custom queues are implemented, 2 states isn't enough to keep on top of them. In fact, adding an additional "filtered" attribute would be even nicer (and more semantically correct), which need not appear in the UI until the first use of filters, so as not to confuse beginners and reduce clutter.

(As it is, I've developed an ad-hoc system that combinatorially overloads the intended meanings of played, favorite, tag, queued, and position to impose some finer-grain control on everything but it's pretty messy and wouldn't dare try to explain it to anyone.)

[matejdro]

@ByteHamster It appears that the work on refactoring has stalled? There is no PR yet and it has been over a year.

What if this PR is merged in the meantime, to gain this functionality and then it can be refactored later if/when episode status refactoring is done? I don't want this to get blocked needlesly long by a potential feature that may or may not be done.

[ByteHamster]

Sorry for the late reply. To be honest, I'm not really a fan of adding temporary solutions. People get used to those and if they are changed to the "proper" solution later, users complain that they want the temporary solution back. Would you maybe be interested in working on adding the "ignored" state? ;)

[matejdro]

Is it really a "temporary" solution if there is absolutely no work being done on the "long term" solution? :)

[ByteHamster]

I would still say so, yes. Especially if the long term solution takes a long time, users will ask for the temporary solution back once we do make the switch. I want to avoid that by trying to not add temporary things.

It is nice working with you on PRs 👍 So if you would like to work on the long term solution (#5237), I would be more than happy to assist and review :)