A little podcast programming FU

The reason I haven’t done the fashionable thing and eliminated comments from my blog is that my readers1 are invariably polite and helpful. Case in point: the people who made suggestions—in comments, tweets, and emails—in response to Sunday night’s post on turning recordings of streamed radio shows into private podcasts. Their ideas were interesting and got me thinking in ways I hadn’t before, so I figured they were worth a post of their own.

First, there were suggestions to use get_iplayer, a Perl script that acts as a sort of TiVo for BBC shows, both radio and television. Even more intriguing was the proposal to run get_iplayer on the server instead of on my local machine, eliminating the need to upload the recording files. I like this idea, but I don’t think I’ll do it because the server I use doesn’t have ffmpeg, one of the programs get_iplayer relies on. I’m sure I could install it under my home directory, but that seems like a hassle just to get recording functionality I already have with Audio Hijack Pro. I have the same objection to using get_iplayer locally.

For those of you straining to tell me that the effort of installing and configuring get_iplayer and the components it relies on is far less than the effort I’ll go through in programming, I must tell you that I much prefer programming to system administration. So even if the effort is greater, I’ll enjoy it more. Plus, a AHP-based solution is easier to adapt to other streaming audio I may want to record and convert into podcast form.

Another suggestion was to save the recordings to Dropbox, so the upload to the server would then happen automatically. My initial plan was, in fact, to do it this way,2 but when I started looking into the Dropbox API, I couldn’t find a way to generate a permanent, direct URL to the recording file. The shares call makes a permanent URL, but it’s to a so-called Dropbox link that doesn’t go directly to the file. I can’t use that for an RSS enclosure. There’s also the media call, which does link directly to the file but isn’t permanent. According to the documentation, the link created by media expires after four hours. That’s not acceptable, either, as my recordings will often occur in the middle of the night and the download to my iPhone won’t happen in the four-hour window.

If you know of an automated way to make a permanent link to a media file, I’d love to hear about it. Until then, I’ll assume some uploading code will be necessary.

Finally, several people told me I should be using an XML or RSS library instead of building the feed by “hand” via text manipulations. My first instinct was to disagree strongly with this. XML/RSS files are, after all, just text files, and pretty simple ones, at that. I didn’t think anything would be gained by loading in a library that was, in essence, just a wrapper around a bunch of string substitution commands. But that was before my iPhone stayed silent for a day and half because it didn’t come out of Do Not Disturb mode on New Year’s Day.

You know about the Do Not Disturb bug, right? If you have DND set up to keep your iPhone quiet overnight, automatically turning on at night and turning off in the morning, you were in for a rude non-awakening. DND didn’t turn itself off on January 1, so there were no notices of alarms, phone calls, texts, email, etc. until you went into the Settings and turned it off manually. This bug is supposed to resolve itself on the 7th—until then DND is a manual-only feature, which defeats most of its value.

What does this have to do with using XML libraries? Because Apple is close-mouthed about its internals, we may never know why this year’s DND bug occurred. I can say, however, that every time I’ve written date handling code with stupid bugs it’s been because I had decided the problem at hand was “too simple” to bother with importing a library. So I went ahead and wrote my own code, which inevitably failed to consider one edge case or another that then bit me in the ass later.

So as I was bitching on Twitter about Apple not using well-established calendrical code, I realized that my complaints could just as easily be leveled at me. I was assuming that RSS feeds were so simple I could just whip up a solution in a few lines of text substitution. Am I an expert in the ins and outs of RSS feeds? No. Do I have a lot of experience in what distinguishes valid and invalid RSS file formats? No. Is this going to bite me in the ass someday? Yes.

So I’m going to abandon the path I put myself on in that earlier post and start investigating relevant libraries, some of which have already been suggested to me. You can teach an old dog new tricks.

Update 1/3/13
Jacqui Cheng has a plausible explanation for the DND bug and why it will resolve itself in a week.


  1. By which I mean the regulars. When I get linked on Daring Fireball or Reddit, a more unsavory element shows up. 

  2. At first, I thought a serious downside to using Dropbox would be that the recording files would end up syncing to my MacBook Air, where I don’t need or want them. But Selective Sync solves that problem. 


2 Responses to “A little podcast programming FU”

  1. Frederico says:

    Heya

    Interesting project. Sort of have a similar workflow already functioning utilizing Dropbox as the carrier engine; maybe my method will inspire you.

    Tl;dr: use Dropbox as the transfer engine only; let your server create the directory structure and links and provide automated scripted triggers to generate said same.

    Background: I have to maintain and monitor an ancient A/V monitoring solution on a frightfully old WinXP server. It allegedly has remote monitoring and access including http and push notifications, but it was made in Taiwan and the English translation is atrocious, so I have not invested the time to make any of it work; besides, I have no desire to open up the network with an otherwise unmonitored and presumably insecure service due to the lasts update occurring in the last century. Otherwise it is incredibly capable of producing audio/video/images based on events and schedules, and at surprising quality sourced from expensive cameras. A little post magic generates MPEG and PNG.

    The need was to be alerted to recorded events in a timely manner, and to be able to review media files of various types without establishing a remote connection on a shakey satelite broadband connection to use the horribly slow log & event viewer.

    Since the media output was near-real time post-trigger, I at first used Windows based scripting and FTP to get the stuff up to a faster server, but this got ugly, and again using even sftp on WinXP made me nervous.

    Solution: enter Dropbox. It was as simple as slinging the media files directly to the video server Dropbox folder upon creation, which in turn pushed all the media up to the cloud as fast as possible. Nifty. Now the receiving server need only watch the target directory, and upon adding new files, a script is triggered that builds a new HTML directory page (which is permalinked) listing all current and newly added files and creation/mod/last-accessed data; while simultaneously sending text and email alerts (i can even dial a phone and play a recorded alert) to interested parties; the emails are hybrid that include both directory links and target media links based on their file location on my server directory structure, not Dropbox’s.

    Substitute your rss creation on the watched folder, and you’re good to go.

    HTH; questions and comments most welcome.

    Cheers

    Frederico

  2. tofias says:

    Re: Dropbox URLs. It seems like you can just use the shares call by massaging the URL a bit:

    Replace www with dl and append ?dl=1 to your URLs.