See the entire conversation

Hi, @OvercastFM! I'm curious as to why the audio enclosures in @davewiner's feed don't load in Overcast? I double-checked and there are definitely enclosure tags in that conform to the RSS 2.0 spec. Is it because they are m4a and not mp3 files?
21 replies and sub-replies as of Jan 13 2020

I would ask @marcoarment directly. Overcast supports m4a so it’s likely something about the xml/rss
I have a guess or two. 1. He has a list of validated podcast feeds and Scripting News isn't among them. 2. Most of the items in the feed do not have enclosures. The proper way for a podcatcher to deal with them is to ignore the enclosure-less items.
I checked into it: it’s because Overcast skips any items without titles. Titles are optional in RSS, but by convention, podcast episodes always have titles. I’m not sure what the best move is here, but I think requiring titles for podcasts is a reasonable implementation choice.
Thank you for your reply! Do you think it would be reasonable to use the filename of the enclosure in this case? Same as if I upload a file via your interface.
I don't agree. Scripting News has had podcasts for a long time, and none of them have ever had titles. So the idea of a podcast without a title is well-established, imho.
I agree with @andrewshell filenames could be defacto titles in the case of no titles in the feed. I also agree with @davewiner that titles not be a requirement. It could make organizing more difficult for humans, but computers could just organize by publish date from rss.
Before you use file names in place of titles, let's have a discussion. RSS feed readers often mangle posts without titles, tradition started with Google Reader and imho it's rude. The file name was not intended to be a title. So I don't think you should use it that way.
For accessibility purposes, it’s essential that there be a title present. Despite the flexibility, it is a reasonable compromise to use the file name as a potential title if an actual title is missing.
I wanted to find out what ezfire is, and got a DNS error.
My apologies. I'll talk to the team about the site. EZFire has been a consultancy firm, working to promote accessibility for disabled people. I still do quite a bit of speaking and consulting work but I'm transitioning to other things. I haven't focused on much other than resting
Here's the use-case. The podcast is very well described in words.…
I think I agree with @davewiner. The RSS spec explicitly says that the title is optional (if there is a description). Remember the Robustness Principle:… I guess the thing to do is something that won't surprise the user. Now I'm off for a run using Overcast
I agree about not surprising (in a bad way) users. Regardless of what the spec says, the design of nearly all podcast apps relies heavily on episodes having titles. How should apps display episodes that lack titles? (I’d argue that RSS readers have the same issue in practice.)
The most likely and pragmatic solution in most contexts is to derive a title from other fields (truncated description, enclosure filename, etc.). So, effectively, titles are “required” in UIs, in the sense that every item generally gets one, whether specified in the feed or not.
I think it’s that the graphic design of many RSS-reading apps depends on some title-like field. If an app is one of those, it should either handle no title in the design or fill the space with something reasonable. Titles are not guaranteed unique anyway. But items are ordered.
just use a string like “Not Supplied” as the title every time there is no title. I’m sure people will love that.
One analogue is how email clients render emails with no subject lines. There's a lot of prior art there.
It makes sense to do what the art world does and label it as “Untitled” followed by the date of creation/publication.
I ran into this issue when I was writing a podcast feed parser. Strangely enough, Apple has podcasts without a title tag listed on the iTunes Search API. Apple Podcasts gives them a default title of No Title. If you do a search for “No Title”, a bunch of them come up.
"Scripting News Episode 2020-01-12" as a default title easily generated from other fields, still searchable, makes sense for the user in the UI without breaking the feed parser?
File name gets my vote. (Not that anyone cares)