If you saw this when trying to download iPlayer programmes today:

There is no page for this programme. This probably means that the programme does not exist.

Then I’m sorry. The message was fairly accurate, though: the BBC moved the page. Thanks to a patch from Liam Bedford, though, I was able to release a fix in a very short time.

The downloads are on the project page.

This release also fixes the missing icon in the Windows application.

ThatGuy wrote in a comment that he’s using iplayer-dl on a Linux machine that he connects to via ssh, and wondered,

Though is it possible to get the ruby script to continue to be processed on the server, even if i disconnect form SSH?

It is. In fact, it’s exactly what I do. To achieve it, you’ll need to install GNU Screen (apt-get install screen on Debian/Ubuntu; your distro may vary).

The first time you connect to the downloading machine (or after a reboot), type:

screen

You’ll get a console prompt, from which you can start downloads as usual. When you disconnect from the session, the download will continue to run in the background.

Next time you connect to the machine via ssh, type:

screen -rd

You’ll get back to the console prompt that you were using earlier, which might still be downloading, or might have finished.

It’s as simple as that!

I’ve released a new version of iplayer-dl and the GUI downloader with a few fixes and enhancements. The principal improvement is the use of a new source for programme information since the BBC discontinued the old metadata URLs. I also took the opportunity of a trip outside the UK to work out how to return a more useful error message in that situation.

The change list is as follows:

• The old metadata files are no longer available. The programme name is now fetched from a newer source.
• Show a more helpful error message if the user is outside the UK.
• Programme title for creating subdirectories wasn’t determined correctly.
• (Console) Progress line didn’t work when the filename was too long.
• (Console) In response to a request, it’s now possible to specify the PIDs to download in a separate file via the --pid-list or -l option.
• (GUI) The program won’t die if it can’t find its icon.

Here are the goods: source release and Windows GUI.

There’s been something of a Vim renaissance among the Reevoo developers of late. It was driven initially by necessity: a couple of developers live far away and spend a couple of days a week working from home, but wanted to be able to continue doing pair programming despite the physical distance.

Latency means that GUI solutions like VNC suck, so we’ve ended up using a combination of GNU Screen and Vim. Vim’s ideal for low-bandwidth and high-latency connections, and Screen lets two people use the same terminal.

By comparison, all the developer machines in the office are Macs, and most of us use TextMate as an editor. It’s a good product: it’s easy to get started with (unlike Vim!), but it’s also highly customisable—and it comes supplied with a number of language support bundles, doing everything from lining up equals signs to asking Subversion who’s responsible for writing a particular line of code. The most-used combinations from the Ruby bundle are probably Command-R (run the current file) and Command-Shift-R (run the test under the cursor), because they really speed up the test-driven development cycle.

I’ve been a Vim user for a long time, but using TextMate at work has made me realise just how much I was missing! Fortunately, Vim is just as customisable as TextMate. It just doesn’t do as much out of the box.

My colleague James wrote about his Vim learnings yesterday, and commented:

Ideally I’d like to be able to do the equivalent of “run focussed test” in TextMate, which should be quite straightforward, but that’ll have to wait for another day.

Here’s my effort at solving that. In my .vimrc, I’ve added a couple of key mappings that only work in command mode in ruby test files:

" Run Ruby unit tests with gT (for all) or gt (only test under
" cursor) in command mode
augroup RubyTests
  au!
  autocmd BufRead,BufNewFile *_test.rb,test_*.rb
    \ :nmap gt V:<C-U>!$HOME/.vim/bin/ruby-run-focused-unit-test 
    \ % <C-R>=line("'<")<CR>p <CR>|
    \ :nmap gT :<C-U>!ruby %<CR>
augroup END

gT should be fairly obvious, but gt relies on a small Ruby script I’ve written and stored in my ~/.vim/bin/ directory.

Incidentally, I keep my configuration files in Subversion, so have a browse if you’re interested, or even check the whole lot out:

svn co http://paulbattley.googlecode.com/svn/config

The new version of the iPlayer site went live late last week, and is significantly different from the old version. As a side effect, downloads were broken. However, with the aid of a session trace sent to me by a kind reader, I’ve made the necessary amendments.

• The method to find the version PID has changed.
• The page served to mobile clients has a different address.

There are still a few questions left (I’m almost certainly not finding the version PID in the best way), but it does work. With a little further effort, it should be possible to grab the radio files as well, which would be a nice bonus.

You can get the updated files in the usual place.

Incidentally, I don’t think they’ve announced it, but from the HTML and JavaScript source, it looks like the Beeb are doing a trial of Nokia N95 support. Has anyone tried?

It may surprise some readers, but I don’t actually have a bad relationship with anyone at the BBC. I had an interesting and cordial conversation with someone from the iPlayer team (not the implementation part) at Mashed last weekend. I think a lot of people there are aware of the futility of trying to lock down content that’s simultaneously being digitally broadcast in the clear.

But I’m puzzled that there are people there who actually seem to thing that obfuscation is worthwhile.

Although iPlayer downloads over the iPhone interface are working pretty well, there’s a bigger prize out there: being able to download the higher quality video and audio that’s streamed to regular Flash clients. The new BBC Radio online player will use MP3 (Yay!) over RTMP (Boo!) in Flash. For ideological and practical reasons, I’d love to be able to play MP3s outside the browser, without needing Flash, and to be able to transfer them to my MP3 player for listening in bed, on the train, etc.

In a thread on the BBC Backstage mailing list about changes to the implementation of online radio playback, I wrote:

It looks like the audio data’s just MP3; it would be even more user friendly if it just used HTTP instead of obfuscating it with a proprietary protocol (RTMP). Then you wouldn’t need Flash at all, although it does make it easier to click and listen in a web page.

Flash will play content over HTTP perfectly well, by the way: that’s how YouTube does it.

In a reply, James Cridland wrote:

HTTP downloads are not possible: we don’t own most of the content. That’s why you’ve spotted RTMP being used – it’s a form of non-invasive Content Restriction And Protection. I’m sorry we have to use it. But we have to use it.

I’m not blaming James for this. I’m pretty sure he understands. But someone, or someones, at the BBC actually thinks it’s worth trying.

It’s not. It’s a waste of time.

["connect",
 1.0,
 {"capabilities"=>15.0,
  "videoFunction"=>1.0,
  "audioCodecs"=>1639.0,
  "app"=>
   "ondemand?_fcs_vhost=cp48184.edgefcs.net&auth=daEcIaKaQdfaic
    ZcBa_aLa9dYbhdCaCc3d9-bizwQB-cCp-FnrDCqBnNDoGuwF&aifp=v001&
    slist=secure/6music/AMI_e6d01bf639fe37be3a42e423f9f38425_b0
    0c73d2_6m_lamacq_thu",
  "videoCodecs"=>252.0,
  "swfUrl"=>"http://www.bbc.co.uk/emp/player.swf?revision=3704",
  "pageUrl"=>"http://www.bbc.co.uk/iplayerbeta/episode/b00c73fc",
  "tcUrl"=>
   "rtmp://84.53.177.140:1935/ondemand?_fcs_vhost=cp48184.edgef
    cs.net&auth=daEcIaKaQdfaicZcBa_aLa9dYbhdCaCc3d9-bizwQB-cCp-
    FnrDCqBnNDoGuwF&aifp=v001&slist=secure/6music/AMI_e6d01bf63
    9fe37be3a42e423f9f38425_b00c73d2_6m_lamacq_thu",
  "fpad"=>false,
  "flashVer"=>"LNX 9,0,124,0"}]

That’s a decoded AMF packet parsed from a conversation between the new iPlayer radio player and the RTMP server. In other words, my RTMP library is progressing very well.

The default WiFi network connection tool on Ubuntu/Xubuntu is NetworkManager, which does a pretty poor job. I’ve been using Wicd as a replacement for about six months, and it’s a lot better, despite a few significant bugs (that have now been fixed in the codebase, if not in the currently released version).

However, I find on my EeePC, running Xubuntu Hardy, that Wicd 1.4.2 doesn’t reliably reconnect automatically to known networks after waking from sleep.

Wicd installs a script to run when the computer wakes from sleep in /etc/acpi/resume.d/80-wicd-connect.sh with this content:

#!/bin/sh
# Bring wifi network interface back up.

/opt/wicd/autoconnect.py

Unfortunately, autoconnect.py doesn’t. My hypothesis is that the driver for the wireless gets unloaded on suspend and reloaded on resume, and the pre-existing Wicd process can no longer talk to whatever it was previously talking to. So I decided to restart Wicd, too.

I changed /etc/acpi/resume.d/80-wicd-connect.sh to this:

#!/bin/sh
# Bring wifi network interface back up.

#/opt/wicd/autoconnect.py
/etc/init.d/wicd start

... and added a new file in /etc/acpi/suspend.d/80-wicd-stop.sh thus:

#!/bin/sh
# Stop Wicd to restart after resume

/etc/init.d/wicd stop

... which I made executable:

sudo chmod a+x /etc/acpi/suspend.d/80-wicd-stop.sh

And it seems to be reconnecting much more reliably so far, touch wood.

I live near what’s left of the Surrey Docks, part of which is now a marina. There are a number of houseboats there, along with other craft repurposed for habitation—a WW2-era US Navy boat, for example—and I’ve often thought that there’s a certain attraction to that kind of accommodation. It doesn’t hold quite the same appeal any longer. This is what I saw as I came home tonight:

I don’t know what happened, but it seems pretty catastrophic. Houses may get flooded, or burn down, but at least they don’t sink.

My sleeplessness is your gain. Thanks to Paul G’s useful research (reported in the comments of a previous post), we now know that it’s not really necessary to leap around in the file.

I’ve stripped out that unnecessary code complexity this morning. As a result, downloads are faster, and you can resume a partial download once more. Handy!

More information can be found on the project page.

I’ve spent my time at Mashed this weekend working on an implementation of Adobe’s proprietary RTMP protocol. This is used by many Flash streaming implementations; being able to replicate it means that we can begin to use streaming content in our own ways. That will open up a huge amount of online media.

So far, I’ve implemented the basic connection handshaking and transmission of packets. That should cover all the low-level stuff, and it’s a good start. In fact, I think it’s the hard part. The remaining work involves a bit of packet sniffing, but I can’t get Wireshark to work on my Eee PC, so it’ll have to wait.

I’m not going to have anything to demonstrate this afternoon, but I do have a lot of code to show: it’s all checked into my repository:

svn co http://paulbattley.googlecode.com/svn/net-rtmp