GeeXboX 2.0 for low-power set-top Linux

There is no such thing as a "typical media center" any more than there is a "typical computer" or a "typical user." What people expect out of a set-top box — particularly one they have built themselves — varies wildly. Some users are primarily gamers, some are DVD and Blu-Ray nuts; some obsessed with high-end audio output and some with tacking on as many video capture cards as humanly possible. You can't please everyone. The GeeXboX project just released version 2.0 of its XBMC-based set-top distribution, and it seems to have settled on a target form factor: small, low-power devices with minimal storage. The decision has its advantages, but it may limit the distribution's audience.

UnboXing

If the name GeeXboX does not ring a bell, that could be because it has been more than two full years since the project made its last release — a lifetime in "chip years." The team went through several shifts in strategic direction in the intervening time, not the least of which was the decision to write a custom media center front end (named "Enna") and then later to drop it in favor of XBMC, which is rapidly becoming the de facto front-end of choice for set-top box distributions. XBMC is a natural fit, because GeeXboX originated as a distribution for Microsoft Xbox hardware (hence the name, though the jury is still out on the justification for the capitalization).

In the same time frame, GeeXboX also spawned a number of side-projects that have fared better than Enna. The most notable is OpenBricks, an embedded Linux framework designed for building custom distributions on a variety of hardware platforms. GeeXboX 2.0 is built on OpenBricks, and indeed supports 32-bit and 64-bit Intel processors as well as ARM chips — specifically targeting the OMAP 4-based PandaBoard and the NVIDIA Tegra2. OpenGL and OpenGL ES graphics are supported for most of the platforms (a complete matrix is available on the site), and hardware accelerated video playback is supported using VA-API, VDPAU, or Broadcom CrystalHD, with Mesa as a fallback for other hardware (e.g., ATI video cards).

OpenBricks is an interesting development framework in its own right, even though GeeXboX only uses a subset of it, because it provides only the minimal environment required for running XBMC and its helper applications. Some of the other GeeXboX side-projects also live on, including libnfo (a parser for the XML-based NFO metadata format popularized by XBMC), libvalhalla (a SQLite-backed metadata scanner that fetches images and scrapes information from an assortment of web sites like IMDB), and libplayer (a high-level video playback abstraction layer providing a unified API for Mplayer, Xine, VLC, and GStreamer).

The GeeXboX 2.0 release is available as an ISO image — a lithe 72MB in size — which can run from either CD/DVD or flash-based media, with persistent storage available when using flash. The distribution boots rapidly, directly into XBMC if left unattended, although a two-second GRUB 2 menu is available to boot into single-user mode for maintenance when necessary. The XBMC build shipped is the newest, version 10.1, and although GeeXboX does not pre-load many of the skins or media-specific extensions available, it provides optical disc support and automatic discovery of SMB, NFS, HTTP, FTP, ZeroConf, and UPnP shares on the local network. A healthy selection of plug-ins are installable through the interface, although they focus mostly on web video and on metadata (such as show information) meant to supplement a media library.

Maintaining a low profile

The focus on network-delivered video reveals the direction that GeeXboX appears to be heading, even though it is not explicitly addressed in the release notes. What the project has in mind as the primary use case for GeeXboX is a small, low-power set-top box — namely, one that can hardware accelerate video playback in exchange for having a slower CPU, and probably without a hard disk for local storage.

For example, with 2.0 it is no longer possible to install GeeXboX directly to a hard disk — the "preferred" option is to run it in live USB mode with persistent storage for customizations and installed plug-ins. There is certainly nothing wrong with running a live USB front-end, but by tailoring the distribution only for that usage, the user is forced into other decisions.

It is assumed, for instance, that another system will be present on the network to serve as the main repository for audio and video content (using one of the network sharing protocols mentioned earlier). Even if a USB hard disk is attached to the set-top front-end box to make files locally accessible, such embedded devices typically do not have the CPU power to transcode video (or perhaps even audio). So a low-power front-end necessitates a second desktop or server machine somewhere, whether the content comes through Bittorrent, optical disc rips, or any other source.

The same goes for DVR functionality; previous versions of GeeXboX used the Freevo DVR application, which was later dropped in favor of Enna. But 2.0 also deprecates support for video capture cards. It is possible to use XBMC as the front-end interface to MythTV (the most common open source DVR) with a plug-in, but with GeeXboX 2.0 the MythTV back-end process will have to run on a separate machine.

This adds quite a bit of complexity — MythTV is simplest to manage when run on a combined front-and-back-end — and despite the popularity of online video delivery, the majority of video is still sent over cable, broadcast, or satellite downlinks requiring a DVR to schedule and record to disk. I am not sure exactly what approach the retro-gaming crowd takes, but GeeXboX does support several console emulator plug-ins for XBMC. Presumably flash storage is not the preferred option for retaining a library of video game ROMs, and again it is assumed that other PCs will be on the network.

Within those restrictions, there is also the issue of package updates to consider. The XBMC core is not updated frequently, although user-installed plug-ins can be updated manually through the GUI. But it appears as though subsequent ISO releases are the only update mechanism available to users, even for bug-fixes. Several users reported on the forum that their LIRC-based remote controls did not function with 2.0, and were told to "wait for [the] next release" as the only recourse.

GeeXboX uses the opkg package manager, so if the project were to start providing individual package updates installing them locally would not be difficult. However, there is no real security model in place suitable for volatile media. GeeXboX runs with one user, root, with an easily-guessable password — nay, extremely-guessable — and runs a Telnet service by default. That is not critical for anyone running from a live DVD, but considering that DVD playback is one of the key features, live USB users are more probable.

The emphasis on slim devices as video playback front-ends may be a good one from a numbers perspective; most of the media-center distributions put their effort into supporting MythTV, which is a sizable undertaking, and "over-the-top" Internet-delivered video is drastically on the rise. But it is still kind of a shame to see options disappear for users. The 2.0 announcement notes that the "GeeXboX philosophy remains the same and we still aim at targeting the most PCs and devices as possible, in an as lightweight as possible way." In practice that is a little bit misleading, because what GeeXboX really expects is that users will use a separate machine to download, record, transcode, and store the media that they watch and listen to on the lightweight playback device. But the announcement does point out the low-end device target as well: "These devices just make the perfect fanless, energy-efficient HTPC [Home Theater PC] and GeeXboX just [makes] the perfect MediaCenter distribution for those."

Instant replay

Aside from the configuration assumptions and LIRC issues, GeeXboX 2.0 is a solid effort. It boots remarkably fast, and if the reports on the forums and mailing lists are anything to go by, the hardware video acceleration is robust on the lion's share of the GPU hardware typical users will choose for their own homes. Prices have dropped enough in recent years that a fully-accelerated VDPAU-capable card from NVIDIA can be had for under US $40, and the Intel GPU support for VA-API covers most of the other common set-top options.

The LIRC trouble is disconcerting, particularly because most set-top-style cases come bundled with IR receivers and remote controls over which the buyer has very little choice. But it is a pleasant surprise to see that 2.0 supports the Boxee Box remote from D-Link, an RF device with a small footprint and a full (in key-count, not in size) QWERTY keyboard.

XBMC itself has come a long way in recent releases, straightening out unnecessary complexity and confusing navigation quirks in the UI. The main competition for a distribution like GeeXboX is the fact that you can run XBMC on a desktop Linux machine with little to no effort. That said, when you visit the XBMC downloads page, you will not find any ARM builds, and you will have to worry about hardware acceleration and HDMI output on your own.

If you are prepared to build your own lower-power box to sit on top of the television, and manage your media collection from somewhere else, then GeeXboX 2.0 may be just what you are looking for. But if you want to run a self-contained media server or DVR, it is not. However, where the project goes next may surprise everyone. This release is the first salvo fired by the new "project renewal" effort launched in July. The possibility of package updates could make the project more useful for hard disk users, and some of the side-projects (such as libplayer) are interesting enough that they could attract a following of their own.

Lastly, as lightweight as version 2.0 is, the project still apologizes for its heft in comparison to the early, 3MB releases. Employing that level of fastidious byte-counting, there is still a lot of room for new functionality before the distribution has to start worrying about bloat.