qooxtunes is a webinterface addon for XBMC. It leverages the powerful qooxdoo
framework to present the user with a RIA interface that emulates some of the
best features of iTunes for library management. It currently only supports
music, but it could be extended to handle video and photos.
Why I built it
For about 4 years, I’ve used iTunes on a Windows machine with the media files and library
hosted on our family’s “shared drive” — a drive connected to an Airport Extreme via USB.
As we moved away from Windows, all I had left was a virtual Windows machine on my Ubuntu
laptop, and so access to the music library became difficult for the other members
of the family. Not to mention that iTunes over SMB is god-awful slow. Just changing the
genre of an album is a painful experience.
iTunes had some powerful advantages when we were carrying iPhones and iPods. But all four
members of the family are now using android, so that ecosystem benefit is not there
anymore, and it started to feel more like lock-in. Our kids are old enough that they want
to pull tracks from the library and put them onto their phones, so we really needed a way
for the family to be able to share the library effectively.
Doing my homework, XBMC looked like a good option, but it doesn’t really have any sort of
native library management. I thought about using Clementine, or even iTunes, to manage the
library, but there were two problems with that:
- Many users will host and manage the library on one machine and then stream via XBMC;
I refuse to keep a separate machine up and running just to listen to music on the stereo.
The power waste and inconvenience make this a non-starter for me. I want the library
to fully reside on the XBMC machine.
- I could host the files on the XBMC machine and manage the files over SMB using Clementine
or iTunes, but that’s a PITA. We have a couple Macs, an Ubuntu machine, and my wife’s
work-issued Windows laptop in the house. You’d have terrible path-related issues if you
tried to have those disparate platforms managing a single music library.
So I was left with the idea of hosting the files directly on the XBMC machine and building some
software to manage the library directly. I wanted an application that is as fast and fluid
as a native application — no clunky web-based interfaces would be good enough.
Here is where qooxdoo shines. If you haven’t heard of
qooxdoo for a variety of projects over the past 7 years, and I’ve always been successful with
What it does
Qooxtunes does a passable job of replicating the iTunes library view, where you can
see your entire music library in table form. You can edit individual tracks or
multiple tracks using an editor that is very much like the iTunes editor. You can edit playlists,
and you can export selected tracks to disk or download them via ZIP file. The former is usually
preferable, as it is much faster.
It’s hard to do the UI justice in words, so I’ll let
this video walkthrough do the talking:
Getting the software
If you’re really interested in the internals of the thing, read on for the technical
details. Otherwise, download
the software and kick the tires on your XBMC system. Don’t do any heavy editing without
making a backup. I’ve been using it on my Frodo system for a couple of weeks, but I can’t be
sure that it will function exactly the same on every XBMC platform.
qooxtunes is a unique webinterface addon in that it starts up a python-based web
service that runs on a separate TCP/IP port from the standard XBMC
This secondary web service is designed to do a few things that the standard
API does not provide:
- downloading song files in a ZIP archive
- listing m3u playlists
- reading/creating/editing/deleting m3u playlists and playlist folders
- saving metadata changes to multiple songs at once
The web service is found in qooxtunes-ws.py, and it uses some additional
- SimpleJSONRPCServer.py (part of the
- zipstream2.py (a quick-and-dirty modification to SpiderOak’s
This web service brings with it some limitations:
- the code only works with XBMC Frodo, since it makes direct database
access; the filenames and/or schemas could change between versions
- the code currently only works with sqlite databases
- because the web service runs on another port from the main web
application, it is considered “cross-origin”. The web service uses
the appropriate CORS headers, but be advised that some browsers
will not support this mechanism.
(more on CORS)
Obviously, I would love to get everything directly from the built-in
JSON-RPC API, but until all these features are available in the API, this
secondary web service will be required.
The client software uses the qooxdoo framework.
To build it, you need to download a copy of the library and unpack it into
the client/qx directory (e.g. client/qx/qooxdoo-3.0.1-sdk).
Then from the client directory, type “./generate.py build”. If you want to
do any debugging, I recommend doing “./generate.py source-hybrid”. This will
compile the necessary qooxdoo classes into an optimized JS file, but will leave
your class files separate for easy debugging.
You can deploy the code by running tools/deploy.sh. Note that you will need
to edit the file to set the appropriate path to your addon. This script will
also deploy the server-side python code.
The deploy script deploys the code in such a way that the build code (the
compiled and optimized code) is in the default location. But it also puts
the debuggable source version into place.
Access the build version at http://localhost:8080/
Access the source version at http://localhost:8080/source/
Note about SmartTableModel:
I included a copy of the SmartTableModel code in the source tree. We are not
actually using that copy during the build; the qooxdoo config.json
is configured to pull the SmartTableModel code from the contrib repo.
I just felt better having the source here as a “just in case” sort of thing.