Why did RSS feed stop adding enclosure data?

• 

  slaboure · Member · Jan 16, 2013 at 1:44 pm

  • Copy link
  • Add topic to favorites

  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: (visible only to logged in users)

• 

  zandyring · Staff · Jan 16, 2013 at 8:56 pm

  • Copy link

  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!

• 

  slaboure · Member · Jan 17, 2013 at 8:22 am

  • Copy link

  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

• 

  slaboure · Member · Jan 17, 2013 at 8:28 am

  • Copy link

  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….

• 

  zandyring · Staff · Jan 17, 2013 at 4:24 pm

  • Copy link

  Ahhh – yes definitely let me know!

• 

  slaboure · Member · Jan 21, 2013 at 8:19 am

  • Copy link

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

• 

  zandyring · Staff · Jan 22, 2013 at 5:07 pm

  • Copy link

  Thank you for providing this information – I’ll relay it to the internal team.

  Cheers!