Buzz Out Loud Lounge: BOL feed wonkiness as of late
- 7/25/09 4:30 PM
Sorry to add more work
by freespirit1956 - 7/26/09 5:08 AM In reply to: BOL feed wonkiness as of late by raygun01
I know this is the BOL forum, but the issue you described with the itunes issue of episodes not showing up is happening to me with the car tech audio feed too. Best of luck with this pain in the butt issue.
Peter
Will take a look on Monday
by raygun01 - 7/26/09 10:35 AM
In reply to: Sorry to add more work by freespirit1956
I'll ask Brian if he's noticed anything.
But (even though it sucks to hear this), I'm somewhat relieved to hear it isn't just BOL. Maybe a change was made to how BTO works OR to how Feedburner works that is causing issues across the board.
Thank you for letting me know!
The problem with BOL feeds
by barduck - 7/27/09 7:19 AM In reply to: BOL feed wonkiness as of late by raygun01
Jason,
The problem with the BOL feeds is not your fault or the process you are using to publish the items.
From your description, I am assuming that you are using feedburner by pointing it to BOL blog and just letting it find the podcasts automatically.
Since BOL blog doesn't explicitly say what are the media items (podcast) it wants to publish by using the RSS elements for media (<enclosure> and mrss's <content>), feedburner needs to "guess" it by scanning the entire blog post, extracting all the links from it and then checking each link for the content type by executing an HTTP HEAD request to that URL.
This is from feedburners help docs (http://www.google.com/support/feedburner/bin/answer.py?hl=en&answer=79023 ):
"...FeedBurner gives up if a link doesn't respond after 30 seconds, because we assume that this means the server is either down or too slow"
Looking at BOL blog, the structure of the post is that it publishes a link at the start of the <description> element, e.g. :
http://chkpt.zdnet.com/chkpt/1pcast.bole/http://podcast-files.cnet.com/podcast/cnet_buzzoutloud_072409.mp3
This link redirects to the actual mp3 file, in this case:
http://podcast-files.cnet.com/podcast/cnet_buzzoutloud_072409.mp3
NOW, if you check this mp3 link response time, you can see it can sometimes take up to 80 seconds and more to get a response for HEAD request. This happens for bol 1025 and 1026 while 1024 seems to respond in ~1-3 seconds. If you have "curl" try running these commands and see:
curl -I http://podcast-files.cnet.com/podcast/cnet_buzzoutloud_072409.mp3 -w "%{time_total}"
curl -I http://podcast-files.cnet.com/podcast/cnet_buzzoutloud_072309.mp3 -w "%{time_total}"
curl -I http://podcast-files.cnet.com/podcast/cnet_buzzoutloud_072209.mp3 -w "%{time_total}"
This is why episode 1026 fails to recognize the correct link to the mp3 file, it simply moves to the next link in the blog post (the emff.swf one). While episode 1025 simply returns nothing since it has NO other links in the blog post. Episodes that respond quickly enough have no problem with publishing their mp3 file in the feedburner feed (and iTunes, I assume you just publish to itunes through feedburner).
Hope this helps.
Now please go kick the butt of some IT person to fix this, I want my missing episodes back!
- Daniel
Holy crud, you are good!
by raygun01 - 7/27/09 7:44 AM
In reply to: The problem with BOL feeds by barduck
By jove I think he's got it!
Thanks! I will definitely take this into work today and see what I can stir up. This makes a lot of sense...
One thing I still can't figure out, though. The SWF link is always in the post... it's what creates the flash player in each blog entry and has since before I started producing podcasts for CNET. Feedburner is set up to only look for audio files to create enclosure tags around. Why does it suddenly this one time see the swf link and decide to make that file the enclosure? That's just strange.
Thank you so much for your insight and time. This is a great new discovery for me. 
Nice work, gumshoe
by KatoKatonian - 7/27/09 9:46 AM In reply to: The problem with BOL feeds by barduckJason, I think someone may have just earned themselves a BOL t-shirt.
the 404
by hetapia - 7/27/09 10:35 AM In reply to: Nice work, gumshoe by KatoKatonianSince the 404 doesn't have a forum, is the same thing happening to their podcast. Show don't show up in itunes.
An update...
by raygun01 - 7/28/09 1:52 PM
In reply to: BOL feed wonkiness as of late by raygun01
Barduck posted a pretty great idea into the forums as to the problem. When we investigated we found that this wasn't actually the cause of the problem. Here's the skinny (my post to Feedburner support which, believe it or not, can't be submitted using their Help service. All I get when I try is the following message: "We were unable to post your message. If you believe this is an error, please contact Google Support." ...don't even get me started on this one. Anyways, here's what I wrote to them:
---
I've been using Feedburner to help syndicate CNET's podcast feeds for nearly two years now with little to no issues. Suddenly over the past two weeks, I am experience maddening issues. I'm trying to nail down the source of the issue, but my experience so far leads me to believe that its Feedburner's issue. Please help a podcast out!
Buzz Out Loud's Feedburner URL:
http://feeds2.feedburner.com/cnet/buzzoutloud
I have loaded the Blog XML from the show's blog page into that Feedburner entry.
http://www.cnet.com/8300-11455_1-10.xml?postType=9949369
I have Feedburner set up to scan the posts for an MP3 link and when found, create the enclosure and iTunes tags around it. For two years, this has worked as expected and without issue. I've even placed an HREF link at the very top of every blog post that I paste that day's MP3 link into, with the expectation that Feedburner recognizes it as the very first MP3 link in the post and creates the enclosure tags around it.
Two weeks ago, I started getting reports of shows not downloading automatically in podcatchers like iTunes. Looking at the Feedburner feed, I'm noticing that any posts that don't download as expected have an enclosure URL that is different than the one I place at the top of every post. Take a look at the URL and you'll see it's a link to a SWF file, that does in fact end with the MP3 link
(see screenshot: http://img200.imageshack.us/img200/6823/feedburnerissues.jpg) ... this code is used to place a flash player into the blog post for that episode.
Now, for two years, I've done it this way and experienced no issues. Now, suddenly, it's happening almost daily. And all I do to fix it (temporarily, it seems) is republish the actual blog post with a minor and unrelated edit. That republishing retriggers Feedburner to see that the item is different and reload it and MAYBE it ends up grabbing the right enclosure url.
AND to make things even more madening, if I do in fact fix the issue... I often find out later (6 hrs, a day, whatever) that it's no longer fixed and in fact the SWF link is the enclosure link again.
Help!
--
This would explain why ANY of our audio podcasts might be experiencing this issue... because they have all been posted in the same exact way as BOL. This doesn't explain why SUDDENLY its an issue.
Anyways, I post more for yall as I discover it.
Redirect
by anonymousjoseph - 7/28/09 2:25 PM In reply to: An update... by raygun01
Hi Jason,
I'm not very familiar with FeedBurner, but it looks to me like the redirect may be the problem. Is the redirect necessary? My guess is that it is for hit counting purposes.
Good luck,
Joseph
Nope, I think it is the timeouts
by barduck - 7/28/09 2:32 PM In reply to: An update... by raygun01
I am still pretty sure it is the timeout. Every episode that didn't have a proper enclosure yesterday had their mp3 link respond in over 30 seconds while all the ones showing had a response of less than 2 seconds.
Today, episodes 1025, 1026 and few of the other missing ones showed up in the feed and their response times are normal now. Today, 1027 is not showing up in the feed and...surprise, it doesn't respond properly (75 seconds). Try it with curl yourself (but it may always work correctly from *INSIDE* cnet's network, so try from different location).
I don't think this is coincidence.
The SWF file is there simply because feedburner takes the next link after the first one (the mp3) fails to respond.
Trust me, there is nothing wrong with feedburner or your blog feed. If you want proof do a little experiment:
* Save your blog RSS as a static xml file
* Replace ALL the mp3 links for all episodes with one that works (has normal response time). But don't change anything else in that feed
* Upload it to some server
* Create dummy feedburner account and point it to that static xml you uploaded
You will see that feedburner will generate an rss with proper enclosures 100% of the time. Now do the same with an offending mp3 link that doesn't respond in time, you can guess the result...
Have you tried this?
by Dhalgren - 7/28/09 2:42 PM In reply to: An update... by raygun01
Jason, do you have a rel="enclosure" in the anchor tag linking to the mp3? Let me know if you need an example, or how I can include html code as a forum post.
He fixed it!
by dextire - 7/28/09 2:47 PM In reply to: An update... by raygun01
From Mr. Howell's twitter: "VICTORY! I've figured it out. I'll update you all once the feeds are back in order again".
Now once he updates us on what happened and the fix, all will be well in BOL feed land.
DEEP SIGH - fixed.
by raygun01 - 7/28/09 3:19 PM
In reply to: BOL feed wonkiness as of late by raygun01
OK, my suspicions were correct. After a lot of noodling, I figured out a solution.
The trick: Keeping the SWF flash player in the blog post so the visitors to http://bol.cnet.com would still have a playable player there... but not throwing off Feedburner's enclosure link detection.
The solution: Way back when, I worked with the developer's of our blog platform (BTO) to add in "podcast" functionality... and used that SWF block of code for the functionality. Essentially, with this new function, anyone posting a blog could publish an MP3 file to the web, drop the url to that MP3 file into the "Podcast" function and BTO would generate the player code behind the scenes, without that code actually hitting the blog entry.
Up until now, I and all other CNET podcasters have been working off of a preset code template. "Replace filename 4 times. Drop in the dek. Code is ready." Easy, but bulky and obviously, all that code was throwing FB off in it's detection of audio files for enclosure tagging.
So I replaced that big chunk of code with the BTO command, throw the link to the podcast into the field in BTO, and what do you get? No more lines of code with confusing urls pointing to SWF files directly... ie no way for Feedburner to get confused about what link is the actual media file link.
And I've confirmed that it's working the way it should now. I changed the past 10 entries so that the current list of shows now and going forward should have no issues.
Of course, crossing my fingers that I haven't missed anything, so time will tell but as far as I can tell, we're good in the hood.
And thanks to all of you for your helpful brainstorming and suggestions. They helped narrow down the field of issues. Mind you, our feeds aren't perfect, but they're a little better now as a result of all of this.
Out.
Deep sight
by J H F - 7/28/09 4:10 PM In reply to: DEEP SIGH - fixed. by raygun01
The video of BOL isn't on iTunes yet
the video always takes longer to appear...
by raygun01 - 7/28/09 5:01 PM
In reply to: Deep sight by J H F
And today, what with my time spent troubleshooting the audio feeds to death, I didn't get the video published until a little bit ago. But it's live now.
Congrats Jason!
by dextire - 7/28/09 5:19 PM In reply to: the video always takes longer to appear... by raygun01
For us it was just a minor inconvenience to get the show from the website. I'm sure it must have been a major headache for you though. I'm glad you figured it out.
| Forum legend: | |
 |
Locked thread |
 |
Moderator |
|
CNET staff |
 |
Samsung staff |
 |
Norton Authorized Support team |
 |
AVG staff |
 |
Windows Outreach team |
 |
Dell staff |
 |
Intel staff |
