Examining the feed at http://feeds.feedburner.com/zipp I obtain the URL for the MP3 file (The /rss/channel/item/enclosure element, expressed in XPath): http://feeds.feedburner.com/~r/zipp/~5/294555004/080519_ZippCast_0049.mp3.
Lets examine the headers:
% curl --head http://feeds.feedburner.com/~r/zipp/~5/294555004/080519_ZippCast_0049.mp3 HTTP/1.0 302 Moved Temporarily Date: Mon, 02 Jun 2008 20:28:29 GMT Server: Apache X-FB-Host: app15 Location: http://cdn4.libsyn.com/zipp/080519_ZippCast_0049.mp3 P3P: CP="ALL DSP COR NID CUR OUR NOR" Keep-Alive: timeout=30, max=100 Connection: keep-alive Content-Type: audio/mpeg
If you don't have curl(1) you can use lynx(1), links(1) or w3m(1) instead, refer to the respective manuals for how to see HTTP headers. The curl(1) prgram is standard on Mac OS X, and even works on Windows too.
The Location: HTTP header is a redirect. Lets follow:
% curl --head http://cdn4.libsyn.com/zipp/080519_ZippCast_0049.mp3 HTTP/1.1 302 Moved Temporarily Date: Mon, 02 Jun 2008 20:29:11 GMT Content-Length: 206 Content-Type: text/html Location: http://media.libsyn.com/bounce/http://cdn4.libsyn.com/zipp/080519_ZippCast_0049.mp3 Server: Footprint Distributor V4.2 Connection: keep-alive % curl --head http://media.libsyn.com/bounce/http://cdn4.libsyn.com/zipp/080519_ZippCast_0049.mp3 HTTP/1.1 301 Moved Permanently X-Powered-By: PHP/5.1.4 Location: /media/zipp/080519_ZippCast_0049.mp3 Content-type: text/html Date: Mon, 02 Jun 2008 20:29:46 GMT Server: lighttpd/1.4.15
Ooops! According to rfc2616 the Location header must be an absolute URI, not relative as here. Lets see what happens if I fix it manually:
% curl --head http://media.libsyn.com/media/zipp/080519_ZippCast_0049.mp3 HTTP/1.1 302 Found X-Powered-By: PHP/5.1.4 Location: http://cdn1.libsyn.com/zipp/080519_ZippCast_0049.mp3?nvb=20080602203748&nva=20080603203748&t=00d47876b74e289c7df18 Content-type: text/html Date: Mon, 02 Jun 2008 20:37:48 GMT Server: lighttpd/1.4.15 % curl --head 'http://cdn1.libsyn.com/zipp/080519_ZippCast_0049.mp3?nvb=20080602203748&nva=20080603203748&t=00d47876b74e289c7df18' HTTP/1.1 200 OK Content-Length: 9581864 Content-Type: audio/mpeg ETag: "40f21e8c7f96c1a78999155117a5c32c" Last-Modified: Mon, 19 May 2008 15:18:02 GMT Server: AmazonS3 x-amz-request-id: 8EE745DC60620FC8 x-amz-id-2: Trs3w1sY7bwGJIUya2WesWU6SBDyCtQWGEG8PUrySXr6+0YjC/r73J0mrNImSoOY Date: Mon, 02 Jun 2008 20:38:41 GMT Connection: keep-alive
Finally I get the actual audio file.
Whether it's the invalid Location: header or the number of redirects to get to the file that iTunes chokes on I can't tell, but it seems to be a misconfiguration at Libsyn.
If I were to create a corporate podcasting setup I'd seriously consider not using external partners for it as Zipp does. Too many things can go wrong, as seen here, and it just looks bad. But it's probably significantly cheaper to risk looking bad, so in the end it's a question about money as always.
4 comments:
Thanks for pointing this out. It appears that the problem is in the creation of the feed which Zipp is providing to Feedburner. They are linking to the wrong files, so we are "bouncing" the links back to the correct location so that the files will actually deliver. As you pointed out, however, that extra hop is breaking iTunes. We will get in touch with the account holder and help them correct the problem in their feed ASAP.
@liberated syndication:
I've notified Zipp too, the support person receiving my email told me he would pass it on to their IT staff.
And I'm impressed that you react so fast. That's a great service.
The links are fixed and iTunes on ZippCast now is back for shows 46, 47, 48, and 49.
Comment on the external partners comment. Yes, doing it yourself gives you all the control but there is point where somethings just can not be supported well over time, especially in non-core activities.
Libsyn as a content delivery network is able to provide delivery of terabytes of podcasts and gets the pricing to do so. They share that pricing in their service. If a company like Zipp were to take on audio hosting then it would cost way to much.
Feedburner, as a service, is an example of something that can be done in house (feed management and feed transformation) but the technology support required is not core to many companies. Zipp is a wheel manufacturer, not an IT company. So being able to tap in to the expertise of other services like Feedburner helps advance the delivery of ZippCast.
And iTunes... That one is a hard one... It really is the major entity in the delivery of podcasts. It is kind of hard not to use them. I agree there have been issues on the iTunes (the service, not the player) side of the things; right now it is something we live with.
I agree when there is a hiccup in any one of these chain of services it flows through and can take a bit of work to fix.
A good analogy today is the phone system. Not many companies (small or large) actually own their phone system. They rely on a chain of service providers to keep things running. Even those that "own" their phone system still need the services of many external partners. When there is a hiccup the service disruption ripple is felt widely.
Thanks for the note on the ZippCast issue.
John Blue
----
Truffle Media Networks
Podcasting With A Purpose
TruffleMedia.com
Post a Comment