I opened #6793 as a first draft at fixing this. However, it is not a complete fix, because it doesn't clean up the existing entry from FeedItems. In version 3.2.0, as well as the current develop branch, the existing entry in FeedItems is updated with the new pubDate when an the same episode is re-posted. But with #6793, this results in a new entry being added to FeedItems. So I think a different approach is necessary, I'm just not certain what it is.

Current behavior when an episode is re-posted with the same guid, and there is a download already, is again to simply update the pubDate. So perhaps the correct approach is to simply set the episode as new when the pubDate is newer.

I reverted the initial commit in #6793 and replaced it with a pubDate check in updateFromOther(). This works much nicer, as it updates the existing entry in FeedItems rather than adding a new entry. The only thing I don't like about this fix is that, if the episode is already downloaded, it still gets set to a state of NEW, meaning that it ends up in the Inbox. Normal behavior is to only place new and un-downloaded episodes into the Inbox. So I think that I need to do another check for whether or not that item is downloaded.

If the episode is downloaded to the device, and the pubDate is newer than the current pubDate, then we should either set the state to UNPLAYED, or leave the state as-is.

However, if there is no download for the episode, and it is re-posted with a new pubDate, then it should be set as NEW so that it is treated like any other new episode.

I'm just not sure right now how to determine if there is a local download for the episode.

Hmm, isn't this intended behavior? If I have already decided what to do with the episode, why do I need to decide again just because the host changes the date?

Well, it seems pretty clear that this is their way of "rebroadcasting" the episode. Most feeds will just make a new post for the episode, so it gets a new guid, etc. But in this case they are removing and re-posting the same episode with a new pubDate. It's not the same thing as a simple update of the pubDate, because the episode now appears at the top of the feed XML instead of its original position.

I think that the expectation is that the episode is included in auto-downloads when it appears at the top of the feed like that.

Just for a little additional insight... think of the use case where someone subscribes to a podcast, but has no desire to listen to the entire back catalog. So, instead the user marks everything as played. I do this myself, to keep older episodes from showing up in a filtered episode list, when using the Not Played filter. In this case, all the user notices is that there's a new episode, and that it didn't auto-download.