5 errors in feed including item should contain a guid element

[nitaaikumar]

Dear @ben-xo, If I try to validate my feed at https://validator.w3.org/feed/ it shows the following 5 errors:

(1) If I add an itunes category like Society & Culture > History for example, the feed returns a 0 for the itunes category, maybe due to the "&" symbol. If I replace "and" instead of this "&" then the above validator shows invalid category. So it needs the exact & instead of and I think. Also sometimes even the subcategory has "&" like: Society & Culture > Places & Travel. So please fix this both category and sub-category.

(2) w3.org gives the following error for all items:

This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.

item should contain a guid element

From the RSS 2.0 Specification:

It's recommended that you provide the guid, and if possible make it a permalink. This enables aggregators to not repeat items, even if there have been editing changes.

A frequently asked question about < guid >s is how do they compare to < link >s. Aren't they the same thing? Yes, in some content systems, and no in others. In some systems, is a permalink to a weblog item. However, in other systems, each is a synopsis of a longer article, points to the article, and is the permalink to the weblog entry.

Additional useful information can be found here:

RSS Duplicate Detection

Solution

Add a different, unique, and unchanging guid to each item. See http://scripting.com/rss.xml for an example.

(3) If I set the itunes:explicit to "no" in the ini which is needed to stop the missing explicit error, then it does not add the explicit code in the feed at all and thus it shows the below missing itunes:explicit error. I think it should still add the itunes:explicit code with "no".

Missing recommended iTunes channel element: itunes:explicit

(4) Fourth error is: "Email address is missing real name" for this line:

<webMaster>podcastemail@gmail.com</webMaster>

Explanation

According to the RSS Advisory Board's Best Practices Profile, the recommended format for e-mail addresses in RSS elements is username@hostname.tld (Real Name), as in the following example:

<managingEditor>luksa@dallas.example.com (Frank Luksa)</managingEditor>

Solution

Add a real name, or prefered pseudonym, after the email address, surrounded by parenthesis.

(5) Another small bug I found is if I add a pipe separator | in the podcast title in the ini, it returns a 0 for the podcast title in the feed. I have used - instead so not a big issue, just letting you know.

[nitaaikumar]

@ben-xo, I fixed 4 by adding my name in brackets after my email for the webmaster variable. So that is fixed. Till the category & bug is fixed, I have temporarily given it a Category which does not include a & in it.

[ben-xo]

Hi @nitaaikumar , I will try to address these one by one.

(1) If I add an itunes category like Society & Culture > History for example, the feed returns a 0 for the itunes category, maybe due to the "&" symbol.

Great find. You will have to fix this by putting the setting in double-quotes, like this:

ITUNES_CATEGORIES = "Society & Culture > Places & Travel" - that should fix the problem. In the next version I will make the examples clearer so that it's less likely this problem will come up.

[ben-xo]

(2) w3.org gives the following error for all items:

This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.

item should contain a guid element

I understand feedback from the validator, but the reality is a little complicated. There are two quite specific, and quite rare, scenarios for you to understand.

Scenario 1: for some reason, you must edit an older episode that is already published.

Let's then suppose that due to an unfortunate circumstance (say, a copyright claim), you have to edit an older episode to remove some audio, and re-upload the file.

What you want to happen is for the old episode to stay "listened to" for those who already have it, and for the episode not appear as a new episode in the feed (and to retain it's place in the order).

A GUID ("globally unique ID") helps the podcast app to determine that this new audio file represents the same episode, and it should not be downloaded again.

But in fact there is a bigger problem for us when using dir2cast, and that is that if you replace the media file with a new file, dir2cast cannot tell the difference between this replacement and you having uploaded a new episode. So the edited episode will be bumped up to the top of the feed unless you take care to preserve the file date, which is not a straightforward fix without some creativity - and, to keep things simple, I have not supported this scenario in dir2cast. (Not yet, anyway).

Regardless, a GUID of the URL of the episode could help with half the problem in this scenario, but it will not help with the episode order changing in the feed!

Scenario 2 - your media moves to a new URL (perhaps because of costs or some other reason)

Let's suppose that you have to move some of your content to a different host. The URLs of every episode could change.

There are lots of ways to deal with this situation. Adding web server redirects is one.

But if you can't do that, then the URLs will change. In order for a podcast app to understand the episodes are really the same, they'd need a GUID - and it would have to be unrelated to the URL, which means it cannot just be based on the link.

But what what should it be based on? I don't have a one-size-fits-all answer, which is why I haven't added the feature yet.

Conclusion

For now, I think you can probably do without a GUID. They are optional, according to the RSS spec, and they come with their own problems.

[ben-xo]

(3) If I set the itunes:explicit to "no" in the ini which is needed to stop the missing explicit error, then it does not add the explicit code in the feed at all and thus it shows the below missing itunes:explicit error. I think it should still add the itunes:explicit code with "no".

Similarly to problem (1), there is a mistake in the example in dir2cast.ini.

Rather than setting ITUNES_EXPLICIT = no, please change it to ITUNES_EXPLICIT = "no" and the problem will be solved.

[ben-xo]

(5) Another small bug I found is if I add a pipe separator | in the podcast title in the ini, it returns a 0 for the podcast title in the feed. I have used - instead so not a big issue, just letting you know.

Once again the solution is double-quotes! :) Put them around the whole title, and there will be no more problem.

[nitaaikumar]

Thanks you @ben-xo, you solved them all by double quotes.

For now, I think you can probably do without a GUID. They are optional, according to the RSS spec, and they come with their own problems.

Thank you for explaining in detail. Now I get it. I can understand that it is complicated to add. Is it that the feed is not showing any episodes in podcast statistic services like bluburry because the guid is not there? I mean even if it is guid recommended and not compulsory, what would be good to know is can a lack of guid for each episode break the feed in some podcast apps or podcast stats? I have not tried the other podtrac stats. But what I did is I installed awstats on my server and now I can get the stats our every streamed and downloaded media file, even the exact bandwidth used, so I don't need these podcast statistics anymore. This is another benefit of having dir2cast on the server. One can get the best stats with awstats. :)

[ben-xo]

I am not against adding GUIDs - but I need to work out the best way.