As far as I can tell, Feedburner, the Google service we use to allow us to easily manage the look and presentation of our podcast feeds, is suddenly having a difficult time capturing the podcast links that appear in our blog RSS feeds and turning those links into enclosures. These enclosures are essential for podcatchers. Basically, an enclosure tells a podcatcher, "Here is a new file to flag for automatic download the next time you sync your device." Without those enclosures present, your podcatcher will see nothing new in the feed. Thus, you will not receive that episode automatically.
What this results in for you is a podcast feed that usually contains 9-10 episodes only containing maybe 3 or 4 episodes. Quite possible, the latest episode is one of those that doesn't have the enclosure. Therefore, even though a new episode has published, you do not receive it automatically via your podcatcher.
Why this is so darn confusing:
Absolutely nothing has changed on CNET's end. Nothing. We have been using Feedburner like this for over two years now. Since then, we have formatted our podcast blogs in the same way and doing so has always allowed Feedburner to capture those podcast links and create enclosures as expected. Suddenly, however, Feedburner is simply not reliable in doing this. Another source of confusion lies in the fact that our video podcast feeds are unaffected. In other words, if you subscribe to the video feeds for our CNET Live shows, those episodes are appearing as they should with no ill effects. Our audio and video files are both served from the same location, so it can't be a problem with the serving of our audio files.
What I'm doing to fix the issue:
I am currently in contact with someone at Google who is taking the time to investigate the issue to see why it is that our audio podcast feeds are acting this way. We've taken a look at a few possible reasons and none has panned out. We also have an internal team taking a look at our feeds and how the files are served to make sure there isn't something configured incorrectly, or differently from the servers that deliver to you our awesome CNET audio content.
What you can do in the meantime:
You have a few options. Obviously, neither of them boils down to "subscribe to the audio podcast feed and they will appear as expected." So excluding that option, you can:
- Subscribe to the video feed for the CNET Live show you are trying to download. Like I mentioned above, those video feeds still work. Subscribe and you will receive the daily episodes automatically. If you really don't want to watch the video, press play and simply listen to it. Same difference, barring the extra battery juice that video playback uses as opposed to playing an MP3 file.
- Manually download from the podcast blog pages. You can find links to all of these podcast blogs directly from Podcast Central. Let me be clear: Even though the enclosures aren't appearing to make the podcast download to your device automatically, the blog post still exists for those posts. Therefore, if you visit the blog page of the episode you wish to hear, you can then either listen to it using the flash player on the blog page, or save the MP3 file directly to your drive or device and listen to it wherever you like.
- Wait patiently for the problem to get fixed, and then suddenly have a ton of awesome content to catch up on. I know this isn't the best option in the world, but it does exist.
What we plan to do in the near future:
Well, I think it's apparent that sticking with Feedburner certainly isn't the greatest idea in the world. Support has been difficult to find. (Scratch that: Nonexistent, until someone inside CNET happened to "know a guy" at Google who might be willing to help. Believe me, I'm very happy to have someone to work with now, but Feedburner really should have a level of support for everyone who uses the service.) Getting rid of our reliance on Feedburner means that we will need to create our own means of managing and maintaining all of our feeds internally. That way if something happens, we aren't relying on a third party to do our work for us. This is no small feat, as we have over 50 podcast feeds currently, and the key here is creating a tool that allows for the easy maintenance and creation of these feeds in the future.
Let me reiterate that it pains me when problems like this appear in our podcast feeds. I realize that we have a huge, and utterly awesome fan base that has come to expect new CNET audio content in our feeds daily. We are, of course, happy to facilitate, but when technology stands in our way, it's a very frustrating experience for everyone involved. Please keep in mind that you have someone working for you on the inside. Someone who knows the value of this kind of daily content. I am a podcaddict myself, after all. Here's to a speedy recovery.