tag proposal: <podcast:rerun>

[Chris-Hindy]

Apologies in advance if this is not how it is done - nothing worse than management trying to be hip amongst the coders.
As an avid listener, I think the most irritating moment is when you start your podcast app, get on the road and realise another bloody rerun has been added to your feed. Now I'm on my bike and forced to waste time listening to something I know rather than learning something new.

If episodes could be tagged "rerun" and a podcatcher could learn to ignore those...well that would be sweet :).

Delete if inappropriate and I will go back to shouting my frustration through the streets of Copenhagen on my 2-wheeler.

[theDanielJLewis]

I, too, get annoyed by reruns unless I never heard the original. For example, the late Ask Me Another did some reruns that were only a few months old and I hated that because I knew those episodes. But their feed doesn't go very far back, so when they did a rerun from a couple years ago, it was completely new to me and I did enjoy that one.

Do you think a rerun indication should include a date? This could allow a podcast app to ignore all reruns newer than N years.

[daveajones]

I like this idea. It’s nice to have binary flag type indicators in the items like this that do simple things to make the app behave better. Love it.

[Chris-Hindy]

I, too, get annoyed by reruns unless I never heard the original. For example, the late Ask Me Another did some reruns that were only a few months old and I hated that because I knew those episodes. But their feed doesn't go very far back, so when they did a rerun from a couple years ago, it was completely new to me and I did enjoy that one.

Do you think a rerun indication should include a date? This could allow a podcast app to ignore all reruns newer than N years.

Of course there is no solution that works for all...if easy to add I agree....but I'm wary of adding too much complexity..the number of podcasts in which I would realise "damnit, I'm missing good reruns" and need to turn off "no reruns" for is quite limited...in my limited experience. But if adding UI for date qualifier is simple, no issue here.

[staceygoers]

Re-runs traditionally get lower listenership anyway, so curious why we might want to make that more so for the podcaster, by giving apps the chance to suppress them.

Let's say I use a podcasting app that won't display a re-run if I've listened to the original episode. If as a listener, I expect my podcast episode each Thursday ... won't I be confused when I don't see one?

Thinking through use cases here. I'm also wondering if this just couldn't be solved by seasons/episodes not just being numerical values.

[theDanielJLewis]

Let's say I use a podcasting app that won't display a re-run if I've listened to the original episode. If as a listener, I expect my podcast episode each Thursday ... won't I be confused when I don't see one?

Yes, I can see the potential confusion there. It could be grayed out, marked as a rerun, and not auto-downloaded.

But thinking about your work with NPR, I think you might really want the ability for listeners to skip reruns if they want, because it would result in more accurate ad stats.

Take me, for example. My Overcast is set to auto-download all new episodes. But when I see by the title or hear in the intro that the episode is a recent rerun, I delete it without listening further. I was counted as a listener, but I didn't listen at all. Thus, the consumption and ad stats would be inaccurate.

[jamescridland]

Of course, ads are normally different in a rerun than a first-play and there are other reasons for publishers to rerun. I enjoyed a rerun recently from Freakonomics Radio - but to me, it wasn't a rerun, just a new episode I'd not heard before. It was accompanied by a new introduction setting it in context, too.

Now, I guess can see the argument for:

<podcast:rerun guid="https://example.com/this-guid-for-the-original-episode" />

....where an episode that is materially the same as a previous one could be marked as a rerun. A pod-catcher would note that I've already listened to the original episode, and therefore mark this as listened-to only if I've listened to the original episode. It would also not auto-download it. Or perhaps it might just mark it as "This is a re-run of a show you heard in July 2018". As a listener, that might be quite good.

But, I can also see a conversation with a publisher going like this:

"So, you want me to spend development time on this, and then you want me to add an additional piece of production workflow, so that... we can earn less money and get fewer downloads?"

I would also suggest that relatively few podcast publishers do reruns: so I'm not sure this is good value for effort.

(On a wider thought - wouldn't it be good if a wiki-style index allowed me as a listener to tag this show as a rerun? Or allowed me to tag this show as being "about chickens" or "funny" or "features Ben Affleck", even if the original podcast publisher couldn't be bothered? So we end up with an additional layer of data for all podcast episodes.)

[theDanielJLewis]

I really like @jamescridland's GUID suggestion!

But I also agree that, while nice, I think this could be a DOA feature, unfortunately.

(On a wider thought - wouldn't it be good if a wiki-style index allowed me as a listener to tag this show as a rerun? Or allowed me to tag this show as being "about chickens" or "funny" or "features Ben Affleck", even if the original podcast publisher couldn't be bothered? So we end up with an additional layer of data for all podcast episodes.)

Yes, that would be nice, but there would need to be a some moderation. Otherwise, liberals could mark conservative podcasts as misinformation or disinformation, and conservatives could do the same to liberal podcasts. Any kind of crowd-sourced tagging would have to be only suggestions. Otherwise, it's opening up to abuse (malicious or spamming).

[daveajones]

All great comments here. It does have the feel of a DOA tag unfortunately. We can still keep it open for a while to see if anyone pipes in with a killer use case that nobody has thought of.

[Chris-Hindy]

Can I reply by replying to the notifications email..we’ll see. I feel the discussion has lost the original point. The idea was that I as a listener can choose ‘no reruns’ for each individual podcast in my podcatcher. As a podcaster, your listeners are your customers. Keeping them happy is the best way to keep them as long term customers and related ad revenue and recommendations to new listeners. I would use the ‘don’t play reruns’ setting consciously, others who are just joining your podcast would not set ‘no reruns’ until they have got to the point where reruns is an issue. I would not be surprised that there was no episode on Thursday since I have set ‘no reruns’. In fact more likely I would not even notice as I have 400+hours in my queue. I don’t see the threat to ad revenue from reruns with this setting, quite the contrary. I won’t listen to a rerun anyway, I will just consider unsubscribing from the podcast altogether. Maybe even decide not to suggest it to someone else because another podcast has won my favour in the meantime. Case in point, the Freakanomics rerun James mentioned - I just unsubscribed because they send so many reruns. My intention is to manually choose episodes from now on but the risk is high that I won’t get that done for months. It is one of my favourite all time shows yet there is a real risk they will lose ad revenue because I will not automatically download or listen going forward. I hope that this counts as a killer use case. Best regards, Chris Mottes, CEO Hindenburg Systems. Please feel free to Suggest a time for a meeting Sent from my iPhone - pls forgive fat-thumb and bad Siri errors :)

…

On 22 Oct 2021, at 09.11, Dave Jones ***@***.***> wrote:  All great comments here. It does have the feel of a DOA tag unfortunately. We can still keep it open for a while to see if anyone pipes in with a killer use case that nobody has thought of. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[saerdnaer]

I think we should add add with the optional guid reference, and observe the adoption by publishers. We could also add the proposed wiki-style flag to the index api...