Need help? Check out our Support site, then


Why did RSS feed stop adding enclosure data?

  1. I have a blog exposing MP3 files for a podcast. However, recently, our RSS feed stopped including enclosure for recent podcast entries, see entry 5 of this feed: http://code-2020.org/category/podcasts/feed/

    Any reason? The blog content is strictly the same and leverages the audio tag

    thanks!

    The blog I need help with is code-2020.org.

  2. Hi there,

    Do you mean episode 5? I'm sorry, I'm not terribly clear on what you mean by enclosure, so if you could clarify a bit, I think I'll better be able to help you :)

    Cheers!

  3. zandyring,

    Thanks for your reply. Please check here: https://discussions.apple.com/thread/4678917?start=0&tstart=0

    Essentially, when you want to prepare a RSS feed for consumption by iTunes, it needs to have proper "<enclosure>" tag available that tells iTunes where the source MP3 file is located.

    This is typically very easy to achieve with WordPress.com (and it works for episodes 1 to 4), you just need to put an [audio] bracketed tag in your blog post, this is for example the tag for Episode 4:

    [audio http://code-2020.s3.amazonaws.com/CODE-2020-Episode-4-JamesWard-Heroku.mp3|titles=Episode 4 - James Ward on Heroku|artists=Michaele Neale,James Ward]

    This will display a small MP3 player within your blog post so you can play the episode directly from within your browser and, when generating the RSS feed, will add a proper enclosure tag to the feed. Now, if you look at the source blog post for Episode 4 (or any from 1 to 4) and the source for Episode 5, they pretty much are the same and rely on the same [audio] tag, yet, episode 5 doesn't generate the right <enclosure> tag in the RSS feed, which makes it impossible for iTunes to display it.

    I found several similar comments/bug reports on the web while crawling for a solution.

    Is this clearer?

    Thanks!

    Sacha

  4. Wait, maybe I found the reason why... Let me get back to you once the iTunes podcast will get refreshed, which takes time.

    The only difference I could observe between Episode 5 and the others is that the audio tag was using an HTTPS URL instead of an HTTP (i.e. secure), which was not working with the audio tag. I dropped the S and could see an enclosure tag. If that's the case, then I still think this is a bug (or at the very least must be documented), but let me get back to this thread once iTunes refreshes its podcasts....

  5. Ahhh - yes definitely let me know!

  6. OK, so, confirmed, the HTTPS version is not supported, only HTTP URLs will lead to [audio] generating the right "enclosure" tags.

  7. Thank you for providing this information - I'll relay it to the internal team.

    Cheers!

Topic Closed

This topic has been closed to new replies.

About this Topic

Tags

No tags yet.