h1

The TWiT Podshifter saga: A plea to Lina

December 24, 2009

Vista busy cursor I am eating humble pie after suggesting that Leo Laporte might have acted deliberately to prevent This Week in Tech (TWiT) network podcasts from being speed-shifted, using the PodShifter service, when dowloaded via iTunes.

It turns out that Leo, or his staff, did take action which prevented PodShifter working on TWiT podcasts, but that was just a side effect. The intention was quite different and entirely innocent. Leo was gracious enough to respond to my earlier post to explain it all.

Specifically, the TWiT RSS feeds were modified by adding a new iTunes feature, the <itunes:new-feed-url> tag which is described here. The tag is there to help podcasters change feed URLs, or deprecate old URLs, without breaking existing iTunes subscriptions. The TWiT feeds have started using this tag to standardise all their feed URLs. Unfortunately, because PodShifter preserves all iTunes tags when it creates the shifted podcast feeds, iTunes just follows the URL in the <itunes:new-feed-url> tag and effectively replaces the shifted podcast feed with the unshifted original feed.

Leo became aware of my post thanks to Lina Calabria of Investling who is one of PodShifter’s backers and had, presumably, been scanning twitter for PodShifter related tweets.

Lina, I have a request for you. Having tried to get my mind around this, this is my take on what should happen next. While I understand that PodShifter (to quote one of your own tweets) respects iTunes tags, that really doesn’t make any sense in the case of the <itunes:new-feed-url> tag. People only use your service because they actively want a speed-shifted version of a given podcast. By preserving that tag you are causing them to get a normal speed podcast and so thwarting their wishes.

PodShifter should not ignore the <itunes:new-feed-url> tag, rather it should use it, if present, to identify the correct URL of the podcast to be shifted. This is in keeping with the spirit of the tag because it resolves issues over changed or deprecated URLs, which is why the tag was introduced in the first place.

Having thus updated the target URL, if applicable, PodShifter should work its speed-shifting magic in the normal way but NOT then pass on the <itunes:new-feed-url> tag. There is no need, because the purpose of that tag will already have been realised in the updating of the URL prior to shifting.

That way, the benefit of the tag is not lost (and in that sense it is still “respected”) and the end user still gets a shifted podcast to listen to, which is what they were trying to achieve. So everyone wins.

So what do you say, Lina? Could PodShifter customers have this change as a XMAS present? Please bear in mind that right now it only seems to be affecting TWiT, but Leo may just be quick off the mark. As more podcasters discover the use of the new tag the more PodShifter users will find their podcasts delivered unshifted and the vast majority will be at a loss to understand why or to do anything about it.

AddThis Social Bookmark Button

Advertisements

One comment

  1. Our dev team are away this week. your request is definitely noted .. i’ll try and make it a new year presi 🙂



Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: