Amarok 2 uses MySQL embedded as a metadata store

There’s been a bit of turmoil in the Amarok and KDE communities the past week with Amarok’s decision to only support MySQL Embedded in Amarok 2. Jeff Mitchell has written about the Amarok design decisions made.

I’m a little bothered by this, as it forgeos all the “semantic desktop” work that has gone into KDE 4, namely what’s provided by the Strigi and Nepomuk libraries. One thing the whole semantic desktop concept entails is that other applications will be able use data another application stored, but without care to what that other application was or how it was stored. For example, I should be able to share the list of all tracks in my music library, how many times I’ve played tracks, what tracks I think are my favorite, etc across music players. This kind of abstraction is, obviously, good for users, but bad for developers of proprietary software. They don’t want you to easily switch between applications that they do not control. Amarok switching to it’s own database store is a stab at this kind of desktop interoperability. I’ve my own thoughts to add, though, that support what the developers are doing…

Amarok is an awesome application. Dare I say, it’s a killer application on Linux—on several occasions this past year I’ve recommended people install Linux just so that they could play with Amarok and see how much better it is compared to what they were using (yes, I’m looking at you, iTunes).

Before Amarok, I used Music Player Daemon (mpd). I stopped using it after a while: the playlist management wasn’t very good; it would eat those playlists that I spent a lot of effort to make; the GUIs available at the time were lacking; and it was very slow when working with tens of thousands of songs. Some of this may have changed but I’ve not been motivated to look back.

Enter Amarok: I switched because the playlist management was so much better. I setup a MySQL server on my workstation to store metadata, as SQLite was much too slow. Amarok backed with MySQL is very fast—I dare others to find a library-based music manager that is faster with the number of songs I’ve thrown at it.

Balancing desktop interoperability with performance is a delicate balancing act. Interoperability is the hot thing these days—look at how Apple’s line of integrated software and hardware continue to sip market share from the Microsoft-powered desktop. But when it comes down to it, performance and other more perceived benefits are going to win out over desktop interoperability. The Amarok developers’ decision to go with MySQL embedded is a good one that will hopefully keep people moving to Amarok over proprietary alternatives.

Like this article? Please support my writing! Flattr my blog (see my thoughts on Flattr), tip me via PayPal, or send me an item from my Amazon wish list.

Comments

Nikolaj Hald Nielsen's picture

I think you should read the follow up blog “Why Nepomuk could not fully replace (My)SQL in Amarok (yet)” http://blog.danielwinter.de/archives/32 by Daniel ( A Summer of Code student who has actually written a Nepomuk backend for Amarok 2 )

The basic point is, that there is nothing we would rather do than support Nepomuk, but it is just not ready for us to fully commit to it yet. The good new is that the MySql and Nepomuk backends are in no way exclusive, in fat, due to the design of Amarok 2, they will run quite happily side by side, so if Nepomuk and friends mature enough over time, the transition to using it as or main backend will be totally smooth.

So yes, going with MySql is a tactical decision for the short to medium term, but we are not burning any bridges and we do have a working Nepomuk backend. :-)

  • Nikolaj
Samat's picture

Just to make clear: I agree completely with the tactical decision to use MySQL long-term, because I already know long-term Strigi/Nepomuk integration will come once performance gains with those libraries are realized.

I, like many others, want nothing more than to continue to use the best music player on Linux.