WordPress.com is an easy way to start blogging. Get a blog, check out our features, read the latest announcements, choose from great themes, or learn about the team behind it.
Need help? Check out our Support site, then
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.
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!
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
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....
Ahhh - yes definitely let me know!
OK, so, confirmed, the HTTPS version is not supported, only HTTP URLs will lead to [audio] generating the right "enclosure" tags.
Thank you for providing this information - I'll relay it to the internal team.
Cheers!
This topic has been closed to new replies.
slaboure
zandyring