Let’s Explore
You have several download options if you want to test drive Media Explorer yourself. At the bottom of the project’s home page is a binary RPM, zipped and tarred source code, and brief instructions on building directly from the Git repository. The RPM targets MeeGo 1.2, but should be compatible with other current RPM-based distributions. You may want to search third-party packagers for your distro, however — after attempting source compilation, I had the best luck grabbing an Ubuntu package from Guido Iodice’s PPA.
The reason a binary package might be a good idea is that Media Explorer has a lot of dependencies — and I mean a lot. Almost everything in the standard GNOME stack, plus Clutter, GStreamer, Tracker, Grilo, MX, and several libraries for REST support, almost all of which require recent versions. After I wasn’t able to figure out how to update the right packages individually, I checked the wiki’s Installing page, which recommended I use the jhbuild build system. That’s a huge mistake; jhbuild is designed to build the entire GNOME environment, from source, and that’s what it will do if you fire it up. Unless you have the time and disk space for that, look for the binary.
But enough about installation; that same list of dependencies is actually one of my favorite aspects of Media Explorer: it is not a monolithic media archive, but instead builds a usable interface on top of existing components. That is very different from XBMC or MythTV, which maintain their own internal databases, search frameworks, and media discovery.
As a result, they can be painful to use. MythTV, for example, is designed from the ground up around recorded TV programs. Getting it to recognize other kinds of video files, music, and Web content requires custom plug-ins that shoe-horn content into the database, throw together an inconsistent UI, and break way too often.
Media Explorer takes a different approach. It relies on Tracker (which is an existing component on most desktop systems) to index the content, and the Grilo framework to notice that it is there. Grilo you may not be familiar with: it provides a “media discovery API.” The default version discovers media on your local filesystem through Tracker, but other backends for Web services like YouTube and Flickr allow for a single, integrated look at what you can access.
The practical upshot is that Media Explorer is very lean, and runs very fast. The overview includes five tabs: one each for audio, video, and still images, plus a search tab and custom playlist tab where you can build up a queue. The interface is smoothly animated in Clutter, and is accessible with the keyboard, mouse, or an IR remote. There is even a handy set-up tool that walks you through the process of assigning keypresses on your remote to actions inside the app.
Within each tab, navigation is simple. You get a full list of all of the content that Media Explorer knows about, with a thumbnail for each, and you can launch playback with a single click. In other words, there is no bookmark/save-for-later feature and no detailed file information screen. Just navigate and play. On the down side, the current version doesn’t seem to support folders, either, which would be a nice addition.
The playback is performed by GStreamer, and although there may be formats out there that GStreamer cannot decode, I haven’t run into them. The playback controls are simple and unobtrusive. Another benefit of Media Explorer’s non-monolithic design is that volume control and playback hardware are handled by the system’s media layer. Here again, too many other media centers try to re-implement their own volume control and video mode settings, usually with depressing (and incompatible) results.
Still, the real gem is that Media Explorer finds media content on its own by relying on Grilo and Tracker. It is tiresome to have to manually add content sources to multiple applications, particularly when all of your content stays in the same place. XBMC, although it bests MythTV in many UI areas, is still cumbersome in this regard. Plus, by building on top of existing utilities, Media Explorer fits in with the Unix philosophy of “do one thing, do it well.” No separate media storage, no separate database schema: the project is free to focus on better things.
And Now, a Riddle
On the other hand, Media Explorer does perpetuate one problem common to most Linux desktops, because it treats all media content the same way, as entertainment products to be consumed. That is simply not true. My hard drive has tons of images on it I never want to sit down to a slideshow of on the sofa: ads for the conference I help plan, screenshots for articles I write, icons and designs I draw, and all of the image files from my various personal Web sites. On top of those, my photo archive contains thousands of pictures, most in raw .CR2 format and with browser-unfriendly names like IMG-12345. Tracker (and, consequently, Media Explorer) sees only what the filetype is, and indexes everything into a single combined database. Like the old joke goes, what’s the difference between a professional photographer and an amateur? The amateur shows you all his pictures.
Likewise, my video folder contains pieces from projects I’m working on: trial exports, raw captures, effects snippets generated by Kino, and so on. I’m not a musician, but if I was, I would have recordings, samples, loops, and various mixes. If I were Bowie J. Poag, I’d presumably have hundreds of background wallpapers and all of their components. I do need access to those things, but I need it when I’m working in Kdenlive, Digikam, Ardour or Rawstudio, not when I sit down on the sofa to get my entertainment fix.
My point is that there is a big difference between content that we have on our hard drives for the purpose of entertainment, and content that we have because we’re creating something with it (whether for fun or for work). It isn’t Media Explorer’s fault that these are lumped together, in fact it is not even really Tracker’s fault. None of the Linux desktop environments correctly make that distinction. Tracker is configured by default to look in GNOME’s generic content folders: $HOME/Pictures, $HOME/Videos, and $HOME/Music (which, incidentally, is a misnomer: podcasts and ebooks are also important to today’s desktop user, but are usually not music). KDE has the same set of defaults. It’s all-or-nothing: all audio is equivalent, as is all video, as are all still images.
It seems like one could hack one’s way out of this by manually configuring Grilo and Tracker: create separate folders for different kinds of content based on whether they are work or entertainment, and change the indexing settings to match. Grilo even has back-ends for Web services, so maybe I shouldn’t have Tracker index my photos at all, but instead link only to my Flickr account.
But that’s a work-around for a design flaw that ought to be fixed at the source. A lot of people (rightly) criticized Apple’s iPad as being built for “consumers” and not for “creators.” In open source, our applications offer a much better experience, but our desktop environments still do not. These days we are all producers of content, even if it is as humble as Webcam portraits or video of our cat falling down the stairs. The distributions and desktop environments need to take notice of the difference, while it is still a problem mainly affecting the media-centric and not yet aggravating the masses.
In conclusion, though, despite the problems introduced by Tracker, Media Explorer is a big step in the right direction for the “media center” concept. It is lightweight, which will make thin-client set-top box users happy, and it is easy to navigate and robust in its media format support. The feature set is limited at the moment, but because Media Explorer builds on top of other solid projects for most of its low-level functionality, the development team has the time to focus on adding new user-visible features, instead of hacking format support and discovery protocols. Bookmark it.
