Reruns
farski opened this issue · comments
Many shows rerun episodes without alteration (of the primary content). This essentially creates duplicate entries in feeds that often are handled identically to new episodes by clients.
Like on a DVR, it would be good if users had the option to ignore reruns if they choose to
There are also many cases where a previous episode is re-released with additional/updated content. Should this be considered a rerun?
Reruns do create some confusion in the user experience—I've experienced it, that sense of déjà vu when you're 22 seconds into the show and you're like, "whaaaat?" So yes, it'd be super if podcatchers allowed users to set the preference "Skip Reruns." Challenge is that podcasters would likely not utilize the tag, knowing that 99.9% of listeners would automatically choose that option. As to your second scenario, I think most hosts make an announcement in the intro that the some of the content has been on the show before, been updated, is being run again as a part of series, etc. I wouldn't think a new tag is needed for that.
This is a conflict for me. I see the utility of this, but I agree that podcasters would most likely not use it. After all, I think reruns are usually a lazy idea anyway. But there are exceptions.
Consider these few scenarios:
- Podcaster can't publish an episode this week, so they post a "best of" clips show. Is that a rerun?
- Podcaster simply reposts an old, but popular episode, that may still exist earlier in the feed.
- Podcaster reposts an old, but popular episode that may have been pushed out of the feed (especially applicable to daily podcasts).
I have seen several podcasts I listen to do this, often showing the older episodes original release date, or older episode number, and often "rerun" in the title, so producers are already indicating this to their listeners, if not in a normalized or programmatic way.
I would define a re-run as one where a producer puts an item in their channel where the content is substantially the same as a single episode which has been previously released in their feed (though it may or may not currently be in the feed).
A "Best of" is a "new" episode to me - yes, it edits together bits of previous episodes, but it is not so substantially similar that I could easily say that a user had heard it before, and so have any practical action on this such as marking it as already heard, automatically skipping.
A rerun could still differ with a different intro, have different ads, etc. It is no doubt up to the producer to determine what constitutes a remixed or updated episode that is "new" vs. an actual rerun.
The affordance here is that a user could see that they have already heard this before or not, and so either skip it, or even have the app by default (like a tivo) not bother to download it if it has been previously heard (saving time / bandwidth / storage).
I would also liken this to how a producer may cross post an episode from another show.
In that case as well, a listener may have already subscribed to the other show and heard it, but this can only be established via additional tags that would reference the other feed and episode guid. In this case, for a rerun, you need the indication that this is a rerun, and the reference guid.
(I am not suggesting we necessarily use the same tag for a rerun as a reference to a different episode in the same feed, though that may be worth exploring, more noting the similarity in use and concept.)
On the negative side, producers tracking their metrics will have a disincentive to mark episodes as reruns, as it could mean fewer downloads, but that is the trade off for a better user experience, which I believe is better in the long run.
perhaps an optional field that, if populated, signifies a rerun by referencing the original episode identifier (GUID or whatever... diff topic)
I like that idea of referencing the GUID, maybe even using the same GUID. Already, podcast apps will not redownload if the GUID matches an older episode (up to some limit).
I feel like using the same guid might have unexpected side effects depending on how apps implement things.