On Friday Roku finally released the SDK for their handy little Roku Video player (sometimes called a Netflix box since that was originally the only content you could stream). The SDK is free, all you have to do is signup at the developer page. The zip archive contains everything you need to get started hacking together a new channel for your Roku player.

For the most part development is cross platform. You are restricted to using their language, BrightScript, so there are no compilers or IDE needed. It helps if you have the make utility available on your system, the examples come with makefiles that will zip up the application and install it into your player with a single command. If you want nice images to show up while scanning through a video you will need to capture them from the file and create a BIF file to tell the player when to show the images. The biftool is currently only available on linux and Windows.

To be able to upload software to your player you need to enable developer mode. This is accomplished with a set of remote control keypresses. For some reason it took me about 10 tries before I got it to work. I’m still not sure if it depends on where you start from, but what finally worked for me was being at the top level channel menu with something other than settings selected.

Once that is done the box now has a simple server running on port 80 and a debug port on 8085 where you can view debug output from your app or from the system if the upload failed, or if parsing the script files failed. That’s all there is to it. No cumbersome app signing needed at this point. It makes it very easy to edit, upload, try, debug, repeat. If you want to actually publish your application as a new channel for the world to use the process is more involved and requires Roku to approve your application.

The SDK includes, among other things, a couple of video examples. One simply points to a URL and plays it (the URL is hard-coded into the application). The other is more fully featured and uses TED talk videos. It allows you to setup a hierarchy of categories using a couple of XML files. This is a good place to start for streaming local content.

The first thing I did was setup an Apache 2.2.13 server on my son’s Fedora11 system. I simply aliased the directory of mp4 videos and it was up and running. As a side note, Chrome (at least on OSX) can stream mp4 videos over http without installing anything else.

I then played around with the simple stream example to make sure I could actually watch the videos. They were encoded using Handbrake on either a OSX or Fedora system. Most are 1G in size or less, and I left most of the encode settings alone. I found that about the first hour streams fine, but after that point the player starts to rebuffer every minute or so. It appears to depend on the location in the file, so it may have something to do with how it was encoded.

The documentation included appears to be fairly complete. The have extensive documentation on BrightScript, and on the Roku extensions that you use to access to features of the player. I did find a couple of things that weren’t described in detail, but at this point that hasn’t hindered progress at all. BrightScript is a fairly simple language and anyone with programming experience should have no trouble catching on quickly.

The example video app uses a hard-coded URL for the source of the XML driving it. I added a keyboard page that prompts the user to enter the host or IP address of their video server. It saves this to the registry (persistent storage) so it only needs to be entered once. For the moment, this is really the only change I needed to make to the example application. Everything else happens on the server side.

I slapped together a Python script to take the names of my mp4 videos and generate the feed XML to drive the player. I used mp4info to pull the video’s bitrate and format from the file and insert into the movie’s description page. I don’t have cover art for them, so that got hard-coded to a default image. The script generates a static XML file for the Roku to load when my custom application is run.

At this point I can browse the movies and play them. Mostly. I’ve run into a couple of glitches, and am not sure exactly what the solution for them is yet. One is that it seems that at about the 1 hour point in the video playback it starts to rebuffer every minute or two. If I stop playback, restart and skip to the 1 hour marks it still happens, so it appears to depend on the point in the file, not the time spent playing.

The other is that the aspect ratio of many of the videos isn’t quite right. All of them seem to be squished to some degree or another. This is probably due to the Handbrake parameters I used when encoding them from the original DVDs. They look fine when played back on a PC but the Roku either isn’t properly sizing them, or I’m doing something wrong (more than likely).

Overall I am very happy with the Roku and the SDK. They have done an excellent job of documenting the system, providing example code and especially keeping it from turning into a brick. Several times I have managed to get it to lock up and reset itself. It has always come right back up with no problems. I am looking forward to seeing what other channels people come up with. On the top of the list for me is Hulu streaming, but I’ll leave that up to someone else to implement.

You can look at my code, for what its worth, at my bitbucket homevideo repository.

In all my years of using BackupPC I had somehow missed the archive feature. I’ve used it to recover files by writing them to a /tmp/ directory on a remote system or download a tar of selected files but hadn’t realized that you could also create a gigantic tar of all the files in the current backup. To get this setup I had to do several things:

• Add a new dns alias for the system to write the archive to. I use the same system that BackupPC runs on for this.
• Add a new host in the ‘Edit Hosts’ page, I named it the same thing as the new DNS alias
• Edit the new host’s config and in the ‘Xfer’ page set ‘XferMethod’ to Archive instead of rsync
• Change the ‘ArchiveSplit’ option to 1000 to split the tar into 1G files to make it easy to handle

And presto! I could now dump archives of the backups to the local system and then burn them to DVD. I also wanted to include a directory of all the files along size the archive. Since the tar is actually split up into pieces you need to join them together in order to get a full listing out of them. Since tar was written to be used with streaming tapes this means all you need to do is cat them to a tar process reading from standard input and write the output into a file. Like this: cat host.tar.bz2.a? | tar tvjf - > ./directory.txt

This streams all the archive files to tar which is reading from standard input and writes the output to the directory.txt file. This can take quite a while.

So at this point in the day I finally had the old system image written to a couple of DVD’s. Now it was time to switch the backup back on and catch up with the current system image. I added a few new directories to the list to backup (I usually only backup /etc, /root and /home). This included my new libvirt virtual images. In all it amount to about 96G worth of files. The LAN bottleneck is the 100Mb NIC in the backup system. It was pushing around 45Mb for several hours, chugging its way through the backup. Then something strange happened.

The backup server turned off. No warning, just click. nothing. I rebooted it, it ran its filesystem checks with no problems. I dug through the logfiles and there was nothing in them to indicate a problem of any kind. So I restarted the backup and it ran for about another 30 minutes before doing the same thing. This system never dies on me, or at least ever since I put in an Antec 500W power supply it doesn’t just die.

I started with the obvious, checking for bus errors in the logs. I ran memtest86 on it for a bit. Then I took a look at the BIOS health readings. Even after being relativly idle for 15 minutes the CPU temp was at 63C. Now, this system is a 2.9GHz Celeron D. The max temp is somewhere around 67C. So I was probably baking the heck out of the CPU and it was doing a thermal shutdown. Consumer CPUs like the Celeron just aren’t designed for this kind of abuse. But that never stops me from trying to squeeze every last cent out of a system.

The heatsink had what I’d call a moderate amount of dust on it, but it was mostly on the top not crammed down in the fins like I have sometimes seen. I pulled it odd and the CPU was glued to it with heatsink grease. I blew out the dust (canned air is so much fun!), cleaned things off, gave it some new grease and re-installed.

I fired up the backup and again after a short period of time it died. I finally setup the sensors package on the system and it told the story — it was still overheating. The fan was only running at about 2.7k rpms so I swapped in a spare Tornado fan, cranked it up to its maximum of  5300 rpm and restarted the backup. The CPU now maxes out around 57C and the backups all run to completion so things seem to be happy.

This also reminds me that I really need to blow the dust out of the heatsinks in the other systems around here — I don’t think I’ve done that in over a year. I really should have a regular maintenance schedule instead of waiting for failures to happen. I guess I need the extra excitement or something.

Last year I upgraded to a Core2 Duo system. Not realizing that some of them don’t have virtualization support I bought the cheapest one that NewEgg had available at the time. After a bit of thrashing about I realized that the E2200 I had wouldn’t support Xen, qemu or virtualbox. So I continued to use VMWare Workstation and a bare-metal Fedora9 installation for my build environment.

This wasn’t too bad a first. That is until I added a second ACER 22″ widescreen to my desktop and discovered that Fedora9 has trouble with the nVidia graphics chipset (GeForce 7050/nForce 610i) on this motherboard. The display resolution is squareish. On a widescreen monitor this results in everything looking short and fat. It isn’t terribly noticeable, but does become annoying after using it all day.

Thanks to Moore’s Law the prices on the low end Core2 Duo’s (E3300) with virtualization support have dropped to the same level as the processor I bought last year. Last week I swapped in the new CPU (<10 minute job), and moved my development environment over to Fedora11 and it’s excellent virtualization support using libvirt. I’ve mostly been using the GUI tools for setup and management and have been very happy with things so far.

One of the first things I needed to do was move the default storage pool onto my large drive (ok, 500G isn’t really large by today’s standards but it is the biggest one I have). I didn’t quite get the concept of storage pools at first and was trying to specify a new path when I setup the new virt. Instead what you need to do is edit the storage of the host system, add a new pool using a directory of files on the larger drive, and then create a new image file in the pool for use with the virt you are going to setup.

The next hurdle was getting bridged networking setup. Some of the virts that I use are test images for production web servers (I like to virtualize and test as much of the production environment as possible). To do this I followed the directions over on the libvirt webpage, basically editing a couple of files in /etc/sysconfig/network-scripts.

ifcfg-eth0 now looks like this:

DEVICE=eth0
HWADDR=00:21:97:9e:e1:15
NM_CONTROLLED=no
ONBOOT=yes
BRIDGE=br0

And a new file, ifcfg-br0 looks like this:

# Bridge device
DEVICE=br0
TYPE=Bridge
BOOTPROTO=dhcp
ONBOOT=yes
DELAY=0
NM_CONTROLLED=no

After doing this I restarted networking and now br0 shows up as the default interface when setting up new virtuals with the GUI tools. One snag I ran into is that BOOTPROTO=dhcp is case sensitive — DHCP will not work and will cause some amount of frustration until you realize this.

Within a couple of hours I was able to move my Fedora9 build and test environments over to virtuals, including the i/o intensive iso building process. I haven’t made any objective measurements, but it runs almost as quickly as it did on the bare metal install and significantly faster than when I tried running it under VMWare. Now my screen runs properly, thanks to the nouveau driver used in Fedora11, and I can fire up more virtuals without bogging down the system like it would with VMWare. I may miss the snapshot option of VMware eventually, but for now the virt-clone utility works just fine for my needs.