Replacement
cqr opened this issue · comments
A way to indicate that a new version of audio should replace a different episode in the app e.g. if the audio for the episode being replaced has already been downloaded
@Cj-Malone I think that's a better fit for #42, and even then it seems to mostly be useful for verifying a successful download. It also has the very real issue of being unworkable when the media is dynamic.
The use case being described here is a little complicated because it has to do with the ways that legacy clients work. I'll try to describe the way that these things are usually thought about on the publisher side.
Let's say you publish a file but there is a slight issue with it - a name is mispronounced or a date is wrong. You can update the file in place, but any clients that have already downloaded the file associated with that guid will usually not redownload the file, so those listeners will hear the version with the slight issue. For little problems, that's usually fine.
Let's say you have an episode published with a bigger problem - maybe a segment is silent. Obviously, you want any clients that have already downloaded the bad version of the file to redownload the new version. If all clients supported the media:hash tag, and you were not serving dynamic audio, you could just update it. But all clients do not, so generally best practice is to update the enclosure URL and the guid. Usually people will also update the title to indicate that this is a new version. Legacy clients will then download the new version.
Is this helpful?
So for the bigger issues do you also delete the old item, with the original guid leaving the RSS feed with only the new? That will cause duplicated item listings with my parser, and presumably other aggregators that cache.
With Atom you can have multiple entry with the same id. The parser then uses the information from the one with the latest updated, and I guess it's then a policy choice for the client to redownload.
For RSS though, maybe a integer as enclosureversion? That gets bumped each time you want the file re downloaded (major issue). Although to do this you would have to stop changing the guid and so un upporting clients would still only have the first downloaded.
Does anyone have experience with Stitcher or other services that re host? They may have already solved this issue.
That's correct. It's more important, in those cases, to ensure that clients have the latest version than to avoid duplication. This is a tradeoff that is being made in full awareness of the behaviors exhibited by parsers like yours and others. There's no mechanism that is widely offered for forcing expiration of the downloaded entries.
I don't think we're going to be able to rely on all existing readers to come up to date with the recommendations we are making here - a big part of the goals for this project is backwards compatibility of behavior, so I still think that duplication on clients that don't follow our recommendations is the preferred option.
The hosted audio platforms typically will pull new audio if the enclosure URL changes (e.g. Stitcher and Google). Unfortunately, clients like Apple Podcasts, Overcast, and PocketCasts drive much more listening than either of those players, and none of them exhibit that behavior.
FWIW, removing an episode from the feed is pretty universally recognized as indicating that the episode is no longer available at this point, so maybe that behavior should be updated in your and other caching parsers.
@Cj-Malone can you email me? My address is on my github profile. There's a slack where a small amount of conversation is happening that I think it would be good to have you involved with.
If duplicating is the preferred option, maybe a element like overrides with the old guid, I don't like it but it should give you duplicated content in legacy clients and not in supporting clients.
Caching is vital as alot publishers just drop old episodes, instead of archiving or paging the feeds (that applys to RSS as well as Atom).
Sorry I don't have slack, and instant messaging is a bad way for me to communicate anyway. I need time to think or I just come off as argumentive.
@Cj-Malone It's totally fine if you want to just stick to GitHub; we're really happy to have your take on things. I do want to make sure you are aware that we are using Slack to organize some other aspects of the group, like group phone calls. If you have an interest in being involved in those, Slack is probably the way that's going to happen for the time being.