Fixing iTunes “does not seem to be a valid podcast URL” errors

This is an interesting lesson in evolving standards, and evolving vigilance against bad implementations.  First, the core problem: the dreaded (hey, I dreaded seeing it this morning!) “does not seem to be a valid podcast URL” error in iTunes:

In this case, Developer Lives is in fact a dead feed (sadly,) but I fixed the problem with my client’s podcast before thinking to take a screen shot.  Web journalism falls lower on my priorities than fixing bugs, apparently…

The first thing I needed to do was shut off FeedBurner, which was relaying the source feed to iTunes and everywhere else.  This particular site was using some .htaccess directives with mod_rewrite to redirect all requests (other than FeedBurner) to the FeedBurner URL, but that feed is cached heavily and any exploratory changes to the feed structure weren’t going to be seen.

A quick commenting out of a few lines did the trick for that, but if you’re curious about how to use .htaccess so you can control your podcast feed, here’s a good tutorial. Since FeedBurner could have been the culprit (and I have spent a few hours this year troubleshooting some weird problems in that area,) I highly recommend having the means to keep the FeedBurner feed URL semi-private – it’s not secret, but if you always give out your local URL which redirects accordingly then you have the ability to take your feed back whenever you want it.

(Note that for my initial checks I was able to use curl with a “-A FeedBurner” argument to spoof the user agent, but that wasn’t going to work with the external validators I’d be using later.)

Once I had a feed that I’d be able to play with, I was able to take it to the feed validator, which is an essential service for this kind of thing.  Paste in your feed URL, hit the validate button, and it’ll fetch and scan your feed for errors – pretty much the same thing iTunes is doing, but with a whole lot more feedback than that error box we showed above!

(Of course, I could have, and one might argue should have, gone to the validator right away, but I had a hunch about how things were going to work out, and I got the alert before my coffee, so I figure I’m allowed a little fuzziness )

And lo and behold, there were a bunch of errors.  Nothing too nasty – a human could certainly read the XML and guess the feed’s intent – but for a computer that validates against a strict (apparently much stricter in a recent release) schema, it’s essentially garbage.

From there, it’s a matter of tweaking the output until validation passes.  Apple’s official iTunes RSS specs are really helpful here. In my client’s feed’s case, they were using an old Joomla plugin from 2007 or so that had already been tweaked a fair bit, but apparently the specification had gotten a little more formal in that time.  I actually don’t know if the previous feed had ever validated or if it was just a case of a developer throwing code at the problem until the shows appeared in iTunes, but there were a number of tags that were improperly formatted.  A half hour or so of messing with the PHP did the trick.

Once everything checked out, all that was left was to re-enable FeedBurner and ping their site to let them know the feed needed an immediate reload.

In the case of today’s bug, iTunes itself was rejecting the feed, but the latest episodes were still available in the iTunes store for individual download, which I thought was pretty interesting – iTunes’ servers are a little more permissive, apparently – at least for now.  Even if your feed doesn’t show the latest episodes in the iTunes store, validating the source is likely to solve 99% of your problems.

Tagged as: .htaccess, feedburner, fix itunes, itunes, itunes podcast, podcast, podcast feed, walkthrough