====================== Busy Podcaster's Guide ====================== :Author: Garth T Kidd :Organisation: iPodder "Lemon Edition" Team :Version: $Revision: 1.10 $ :Date: 2004/11/24 In a hurry? Prefer to spend time on your show than tweaking software? This document explains: * How to `save money`_. Planned sections of the document will explain: * `How to get your feed right`_ and how to figure out what you got wrong when your listeners complain; * How to include production notes in your items; and * How to set up your own OPML directory. Nobody seems to be having much trouble getting their RSS feeds right enough to attract listeners, and the penalty for getting it wrong is usually pretty obvious (a full inbox of complaints that they can't download your show), so I'll start with `how to avoid being bankrupted by your podcast`_. .. _hassle Garth: If you have any questions about this document, hassle Garth__ either privately or in public in the `ipodder-dev`__ mailing list. __ mailto:garthk@gmail.com __ http://groups.yahoo.com/group/ipodder-dev/ Recent Changes ============== * Reworked to reflect changes in the likely eventual `podcast namespace specification`_. * Added the `Janes Tweak`_ to the `Grumet Kludge`_. .. _RSS: http://blogs.law.harvard.edu/tech/rss .. contents:: Table of Contents. .. _save money: .. _how to avoid being bankrupted by your podcast: How to Save Money ================= Podcasting can cost a pretty penny. The more listeners you have, the more likely it is that your web hosting provider will either send you a bill you weren't expecting, cut your site off, or both. BitTorrent ---------- .. sidebar:: Don't know how to "seed"? Don't worry if you don't know how to run a BitTorrent seeder for your shows. If podcatcher developers implement the `Janes Tweak`_ to the `Grumet Kludge`_, that'll get taken care of for you. You'll be able to podcast via BitTorrent even if you don't have broadband. BitTorrent is a handy way to dodge the bandwidth bill. It's slightly complicated to use and set up, but unless `podcaching`_ takes off or you use a professional hosting service there's not much avoiding it. The most complicated aspect of using BitTorrent turns out to be figuring out how to make your listeners use it. In short: not all listeners can cope with it. Their podcatcher might not support the protocol, or they might be stuck behind a firewall that blocks the protocol. If you want to keep these listeners happy, you have to find a way of letting them (and, preferably, *only* them) download directly from your site. Multiple Feeds -------------- A popular way of handling this is to generate two feeds: one that points to the torrent feed, and one that points directly to the content. The problem is that you have to generate multiple feeds. It gets even worse if you want to publish your podcast in multiple encodings (say, one in mp3 and one as m4b so iTunes users can use bookmarks and save disk space): you'd then need *four* feeds. Even if you and your software can cope, your listeners might not cope with how many orange XML icons they have to choose between. Another drawback with multiple feeds is that people who could potentially use your torrent feed will be subscribed to your direct download feed costing you more money than they need to. People subscribed to your torrent feed will have trouble grabbing episodes if there aren't enough seeders or if they plug into a firewalled network. In short, as well as running multiple feeds you'll *also* want to use `extended feed attributes`_, the `Grumet kludge`_ and its inverse, or all of the above to make sure that cunning and smart feeds can save you money when they can and recover from problems if they have them. Extended feed attributes ------------------------ You can use the extended ``enclosure`` attributes in the ``podcast`` namespace (summarised in this document and fully documented in the `podcast namespace specification`_) to help podcatchers give you the best of all worlds: the greatest number of happy listeners, the smallest bandwidth bill, and only one feed. .. _podcast namespace specification: podcast.html If you can't generate the namespaced attributes, or a lot of your listeners' podcatchers don't understand the attributes, you'll either have unhappy listeners or be paying more for bandwidth than you need to depending on how you structure your feed. Fortunately, there's another easy step that can help: .. _grumet kludge: The Grumet Kludge ----------------- The *Grumet Kludge* is for those of you who prefer happy listeners to saving money but still want to save as much money as you can. Adding the extended attributes mentioned above will help even more, as the kludge is somewhat inefficient, but the kludge (invented by Andrew Grumet) has one big advantage: it's really, *really* simple. All you have to do is this: publish your response files with the same URL as your audio files, but with ``.torrent`` added at the end. Let's say your audio file is called ``fnord-20041124.mp3``. Cunning clients will try to download ``fnord-200041124.mp3.torrent`` first. If that works, they'll use the response file to download your episode via BitTorrent--saving you a small fortune in bandwidth bills. If the BitTorrent download fails for some reason (say, you're out of seeders or they're behind a firewall), they'll give up and download the file directly. If ``fnord-200041124.mp3.torrent`` doesn't exist, cunning clients will make a note and not try the Grumet Kludge for another week. The Inverse Grumet Kludge ------------------------- The *Inverse Grumet Kludge* is for those of you who prefer saving money to happy listeners. Listeners who can't use BitTorrent will either have to upgrade to a clever podcatcher or use a secondary feed (if you can be bothered publishing one). For those of you who haven't figured it out just from the name and the scenario, let's continue the previous example: If you aim ``url``, ``length`` and ``type`` at ``fnord-200041124.mp3.torrent``, dumb clients will download the BitTorrent response file and then try to get your episode via BitTorrent. That's probably your preferred scenario, because there are a lot of dumb clients out there--every version of every client available up to late November 2004 is a dumb client by this definition, and just those numbers are enough to cause many podcasters severe trouble with their bandwidth bills. The Inverse Grumet Kludge lets cunning clients deal with BitTorrent failures. They'll strip the ``.torrent`` extension and trying to fetch ``fnord-20041124.mp3`` directly. Ta-da! .. _janes tweak: The Janes Tweak --------------- David "BlogMatrix Jaeger" Janes points out another clever aspect of the Grumet Kludge and its inverse: another hack to podcatcher behaviour would mean that podcasters could make good use of BitTorrent even if they were stuck behind a firewall that stopped BitTorrent. All it'll take is for podcatchers to seed even if their download via BitTorrent didn't succeed. Stripping away the jargon, what this means is that if you generate your response file (that's the one ending in ``.torrent``) and upload it together with your MP3, here's what'll happen: * Your first listener will download the response file. * When they try to download via BitTorrent, they'll time out because there won't be any seeds. So, they'll download your MP3 file directly. * Once they've finished downloading the MP3 file, they'll start seeding your show. * Subsequent listeners will grab the file via BitTorrent rather than directly from your web site. Podcaching ---------- With any luck, you'll soon be able to pretty much sit back and do nothing. If the `podcache specification`_ takes off, listeners' podcatchers will automatically consult podcache servers and grab the show from there rather than from your site. Instead of it costing you money, it'll cost *them* money, and they'll recover that money by... uh... .. _podcache specification: podcache.html Okay, nobody has figured out how a podcache might recover its costs. Unlike the boom years there aren't any venture capitalists eager to throw a few million at it in the hope that someone will one day figure it out. Any prospective podcache provider will have the advantage of economy of scale and will be able to use BitTorrent to spread some of the load out amongst the listeners, but it's still far from certain whether or not podcaching is economically viable. In short: podcaching might turn out to be a brilliant way of saving money that won't require any effort whatsoever, but don't hold your breath. Summary ------- * If you can't tackle generating BitTorrent response files and seeding, you'll need a professional podcast hosting service unless podcaching takes off and saves your skin. * Once you've got BitTorrent straightened out, choose whether your priority is happy listeners or saving money. * If your priority is happy listeners, serve your audio files directly and apply the Grumet Kludge. Any cunning or smart podcatcher will grab the torrent file and save you some money. * If your priority is saving money, serve torrent files out of your feed and apply the Inverse Grumet Kludge so that cunning and smart podcatchers can still download directly if they need to. How To Get Your Feed Right ========================== Let's lead with some examples. Monkey see; monkey do. Minimal Example (direct feed with Grumet Kludge for cunning clients) -------------------------------------------------------------------- This is the least you can possibly do and still get adequate behaviour from podcatchers:: Your podcast's name http://your.podcast.web.site/ A short description of your podcast Thu, 4 Nov 2004 08:52:00 +0000 I podcasted! Thu, 4 Nov 2004 08:52:00 +0000 b15e400c8dbd6697f26385216d32a40f Your feed will still validate against an RSS parser if you omit the two ``pubDate`` tags and the ``guid`` tag, and podcatchers will be able to successfuly download your enclosures, but Bad Things will happen later on. If you'd rather dumb clients grab your enclosures via BitTorrent, you need to make a few changes: * ``url`` should point to the repsonse file; * ``length`` should be the length of the response file; and * ``type`` should be ``"application/bittorrent"``. Feed Elements ============= Namespace Definitions --------------------- .. sidebar:: Or, try the iPodderX version! We haven't been the only people thinking about a podcast namespace. August and Ray of the iPodderX team have been chatting with Adam and Dave about the same stuff, and have put up `another podcast namespace proposal`__. It's still shaking out, as described in our local `podcast namespace document`__. __ http://ipodderx.com/podcastRSSModule __ podcast.html If you don't have any namespace, your overall RSS document looks a little like this:: ... To define the ``podcast`` namespace, make the ``rss`` tag look like this:: ... Channel Tags ------------ channel title ~~~~~~~~~~~~~ channel link ~~~~~~~~~~~~ channel description ~~~~~~~~~~~~~~~~~~~ channel pubDate ~~~~~~~~~~~~~~~ Item Tags --------- Items must have one ``title`` or ``description``. They should also have a ``pubDate`` so podcatchers can order playlists appropriately, and a ``guid`` so podcatchers can avoid re-downloading items un-necessarily. If you want to podcast, you also need an ``enclosure`` tag. title ~~~~~~~~~~ description ~~~~~~~~~~~ pubDate ~~~~~~~ guid ~~~~ If you're generating multiple feeds, make sure that for any item the ``guid`` tags are consistent across those feeds. enclosure ~~~~~~~~~ .. sidebar:: Are Multiple Enclosures Safe? In a word, no. The RSS_ spec doesn't explicitly support or prohibit multiple enclosures per item, but most software only supports one enclosure per item. As more and more RSS aggregators add support for podcasting, you can expect that most of them will support just one enclosure per item. We're doing our best (see the `podcast namespace specification`_) to provide other ways of doing whatever it is you might think you need to do with multiple namespaces, but in a way that doesn't break RSS. If you need help with that, `hassle Garth`_. The enclosure tag has three compulsory attributes. We're also trying to shoehorn extra details in there. David "BlogMatrix Jaeger" Janes has suggested that rather than namespaced ``podcast:direct_url`` and ``podcast:torrent_url`` we might want to put XHTML ``link`` tags in the ``enclosure``, with ``rel`` attributes set to ``"delivery"``. Mark Pilgrim's ``feedparser.py`` doesn't appear to handle any extra elements under ``enclosure``, though, whether attributes or tags. That shoots us down for the time being. I'll have to investigate. -- Garth enclosure url ............. enclosure length ................ enclosure type .............. podcast:alt_path ~~~~~~~~~~~~~~~~ podcast:enclosure_protection ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The ``podcast:enclosure_protection`` tag helps podcatchers make sure they got your enclosure accurately. .. warning:: If you're using BitTorrent or some other peer to peer download method that relies on downloading information about the file, ``md5`` and ``length`` should match the payload, *not the response file*. So that corruption of your enclosure can be detected even if the length is correct, put a hexified MD5 digest in the ``md5`` attribute. You'll know if your implementation is correct if your hexified digest for the word "fnord" is the same as that given in the example below:: For what it's worth, the Python code to compute the digest is:: import md5 def hexified_digest(blocks): """Return a hexified digest. blocks -- a sequence of blocks of data.""" engine = md5.new() for block in blocks: engine.update(block) return engine.digest().encode('hex') Podcatchers can't rely on the ``length`` attribute in ``enclosure`` being correct because too many feeds either leave it out entirely or put the same (incorrect) length on every enclosure. To let them know that you're serious, put another copy in the ``length`` attribute of the ``podcast:enclosure_protection`` tag:: podcast:prodnotes ~~~~~~~~~~~~~~~~~ podcast:payload_info ~~~~~~~~~~~~~~~~~~~~ Glossary ======== Podcast An RSS_ feed for which items contain enclosures pointing to audio files subscribers will listen to as if it were a downloadable radio broadcast. Podcaster You, assuming you want to produce a podcast. Podcatcher Software that downloads podcasts and puts them on a user's media player. Podsafe an adjective describing music you can play on your podcast without being sued. Podcache An automated podcast caching service. See the `podcache namespace specification`__ for details. Note: nobody has built one yet. BitTorrent ... Response file ... Torrent feed ... __ podcache.html FAQ === Q: My MP3 file is full of clicks and I need to replace it. What do I do? A: Well...