Explicit expiration date for content availability #318
Comments
|
The correct way to deal with this is to remove it from the feed, surely? |
|
If the feed has the last 10 episodes and the app caches the whole feed for 600 entries, it won't help. |
|
So is the intent to alert users to secure copies of a file that the publisher is legally required to remove? |
|
I have had weird errors because of missing that info in a machine readable way. TV stations like the German Public Station ARD already mark it on their website. So it isn't really about cheating the law here. You could remember the time limit yourself and download soon enough yourself or listen/watch the episode. |
Then the app is doing it wrong. The canonical list of shows that are playable - at least, shows that the publisher wants you to be able to play - are the ones in the RSS feed. Apps or directories shouldn't be storing shows that are no longer in the feed: that's not the publisher's intent. |
Yes they should. If I have downloaded an episode, which then is removed from the server because the RSS feed only contains the last 10, I wouldn't want the app to wipe it off of my phone. We don't know the publisher's intent - they might do it because they're legally compelled to, they might do it to save server costs. But actually that's more a different discussion than having the option to include an end date. I think it wouldn't be a requirement, so the publisher could determine if allowed & desirable in their situation. (Though I think such tag will have rather limited value.) |
|
I think there’s a mismatch here between what an app should do and what a directory/aggregator should do. I would expect a directory to remove older episodes as they roll off the feed, but an app shouldn’t do that unless the listener has chosen to remove it. |
|
I think it also is a nice feature to be able to curate and display a content expiring soon list so that people don't miss something. |
Agreed. I think that's fine. Let me slightly clarify my wording: The canonical list of shows that are downloadable - at least, shows that the publisher wants you to be able to download - are the ones in the RSS feed. I think most publishers don't expect older shows to be presented to listeners if they're not in the current RSS feed. I'd also suggest that shows should NOT appear within an app if the audio is no longer available (whether that's a local cache on the device or on the fileserver). (Incidentally, Spotify will remove a show from your local device's downloads if the publisher removes it from the RSS feed. I don't think that's the right behaviour for listeners, but I can see it could offer some legal protection for publishers.) This sounds like a bit of best practice work for podinfra.net to be honest. |
|
Well, you may be forced to reduce the number of episodes in your feed because of technical issues : I have 179 episodes, but can only publish the last 100s because my feed is 1Mb long (maximum size for some apps and platforms). Yes, I'm pissed of that public broadcasters have to remove their content, but yes, It should appears somewhere, and not only in |
|
For long feeds, you could use paged feed as advised here :
#117 (comment)
I think it can be a great addition to add an expiration date to encourage
listeners to listen or download a special temporary episode, but IMHO that
should be a simple information of when the item will be removed from the
feed.
It will never work to enforce apps to remove the episode, downloaded or
not, from the library of a user at a specific date. Most apps will not
enforce it, and even if they do it's a false sense of security as people
can download and save episodes manually anyway before the expiration date.
Pof Magicfingers (Giovanni Olivera)
… Well, you may be forced to reduce the number of episodes in your feed
because of technical issues : I have 179 episodes, but can only publish the
last 100s because my feed is 1Mb long (maximum size for some apps and
platforms).
Yes, I'm pissed of that public broadcasters have to remove their content,
but yes, It should appears somewhere, and not only in <content> and/or
<description> tag
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#318 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADST7IZ5CHL7GWLX3AJSG3UQHGWZANCNFSM5JGSCFHQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
|
There is also case where you have to remove an episode : because of legal action, because of bad quality, or retractation. This tag would be explicit that the show is no more accessible, retired due to distribution rights |
|
That's an HTTP 404 error on the audio, then. I still don't understand why we need to clutter up RSS feeds with availability details. If it's in the RSS feed, it's available. If it is not, it is not. |
|
|
|
@jamescridland instead of 404, you should provide HTTP status 410 |
It's not clutter if it's useful information. If that information needs to be displayed to the user, it has value to add it. For most cases, this will not be used, but when a content is only available for a limited time, let's say a special annoucement, for an upcoming event, for a discount, etc, it might be a nice addition to allow an "expiration date" shown to the user (Listen before wednesday) In the same way youtubers sometimes title video : Watch this before Friday. We could use the title in the same way, but why not include this as an attribute ? If the hosting provider allow to unpublish at a given time, this end of availability could be shown in apps as well. I cannot see this useful for content control, because that's just a date, and the best way to remove an episode still is removing the episode from the feed. But having the option to show, in the UI to listeners, an expiration date for an episode is still something worst discussing. |
Public broadcasters sometimes are forced to remove content after some time, for legal reasons.
7days and 30 are common.
A podcatcher will grab data and cache it so just not returning the episode in the feed isn't enough to prevent failing downloads.
Maybe also the feed isn't up to date with the file availability status.
How about being able to declare a date&time inside the feed and it's episode elements when the file will expire and no longer be available on the server?
This would allow us to not show ugly error messages and also give the user a last chance to store the episode locally before it expires.
Some stations even have a category for their video content with content they will soon no longer be available.
The text was updated successfully, but these errors were encountered: