[Enhancement] Auto-download new episodes to not download already removed episodes

[advplyr]

Discussed in https://github.com/advplyr/audiobookshelf/discussions/835

^{Originally posted by **LilJay86** July 14, 2022} Hello, i have removed 2 Podcast Episodes and checkt "hard delete file" The 2 Episodes where removed from the File System and on ABS. After 1 - 2 hours were these 2 Episodes back onFile System and ABS. Does anyone know what I'm doing wrong. I suspect that the episodes will be recognized as new and re-downloaded again. How can I prevent already heard and deleted episodes from being recognized as new? Thanks

[gbakeman]

To put this another way, is ABS going to have a system for remembering the listen state of metadata belonging to a podcast? I was hoping for ABS to auto-download all metadata when a podcast is added, then keep track of each episode as new or listened regardless of downloaded status.

[advplyr]

Right now podcasts in abs are only for downloading. You can only listen to episodes you have downloaded so I'm not sure if your question applies yet.

[mfcar]

Hi @gbakeman , do you mean an Exclusion List to avoid a single Episode being added again in the future? Sonarr has implemented something similar to an entire series. If you remove a series, you can add it to an exclusion list to avoid this series being added again.

It's uncomplicated for an entire series because ABS stores the iTunes ID for each podcast, but I can try to investigate some way (I don't know, compare just the title or the filenames) to implement this.

[gbakeman]

Hi @mfcar , thanks for asking! I'm not sure how ABS works currently, but what I'm hoping for is a database of sorts that records podcast episodes that have been listened to. Right now, ABS only remembers the listen state of an episode so long as it remains downloaded on the server. Once the file is deleted from the server, the listen state is forgotten.

As far as persistence is concerned, it would be great if this operates on a per-series basis. So if you remove a few listened episodes from a series, then their state is still remembered. But if you delete the series, then I would be fine if this data is also erased.

[pwinnski]

To put this clearly: hard-deleted podcast episodes are re-downloaded if they're the most recent in the feed.

I think of this as a bug. If a feed contains, for example, three episodes, and I delete the second one, it stays deleted. But if I delete the most recent one, ABS re-downloads it, seeming to assume it is new. That's inconsistent behavior.

I expected ABS to use a timestamp or some other means to recognize that it should not download the deleted file. For example, when editing a podcast, the Episodes tab will "Look for new episodes after this date," but on a scheduled event, there is no such filter.

The podcasts table has a lastEpisodeCheck column, but it does not appear to be used by the scheduler.

Bug #2432 was closed as Completed, but this is still happening in v2.16.2.

I'll give a concrete example. I have set my podcasts with automatic downloads to check once per day. Overnight I see this in my log:

2024-11-07 00:00:27.712
[PodcastManager] runEpisodeCheck: "Murphy" | Last check: Wed Nov 06 2024 00:00:31 GMT-0600 (Central Standard Time) | Latest episode pubDate: Tue Oct 08 2024 23:00:00 GMT-0500 (Central Daylight Time)
2024-11-07 00:00:27.820
[PodcastManager] Found 1 new episodes for podcast "Murphy" - starting download
2024-11-07 00:00:29.747
[PodcastManager] Successfully downloaded podcast episode "Murphy - Trailer (Season 2)"

Since the "Last check" was Nov 06, yesterday, I would expect only episodes after Nov 06 to match, but it downloaded an "episode" from October 29.

Looking in PodcastManager.js, I see these comments:

    // Use latest episode pubDate if exists OR fallback to using lastEpisodeCheckDate
    //    lastEpisodeCheckDate will be the current time when adding a new podcast

This suggests that the focus is on the experience when first adding a podcast, but wanting to delete the most recent episode is falling through the cracks, and clearly there are people who would like that.

Thanks!