This is another post about collection backends in Amarok. The others posts explained the switch to MySQL embedded and tried to address some of the concerns. Jefferai also wrote a few things about Nepomuk in Amarok (and why it will not fully replace the sql based collections) which I want to comment on and add to.

There are user asking: “There is Nepomuk in KDE for storing meta data why the switch to MySQL embedded you could just use Nepomuk and drop sql collection all together.” With reasons like: “Nepomuk can do this and that better and one storage in KDE for everything is best.”  They are not complete wrong, there are good reasons to use Nepomuk (data sharing between applications, system wide searching, using strigi(and taglib) for collection scanning at a central place for all applications once, interconnect the data with other data (like let Kmail store where I got that song from), and others)

But Jefferai is right when he says that Nepomuk can not replace the sql collection for everyone and every use case. At least not for the short and longer midterm (;-)).

Why? Not everyone will or could run Nepomuk for different reasons. The most important one: It is a quite complex big software in terms of memory usage (though I think that will improve in time and the amount of available memory in computers is growing fast) and CPU usage. Another issue is: At least in the short and midterm it it will be significant slower than the MySQL based collection. It is not useless slow but well sqlite isn’t useless slow either (faster than Nepomuk atm) and people complained. So: For slower older computers, lightweight media devices, mobile devices, big collections, java “haters” even a perfect done Nepomuk collection with a bug free Nepomuk (we are not there yet…) would be out of question.

I expect some of those issues to improve over time. (I hope we will see a faster C/C++ based storage backend for Nepomuk). But still Nepomuk is a new technology and there is not much experience with it yet amoung users, developers and important here “developing users” (those who create small scripts and apps to work on the sql data from amarok to do different things with that, mostly for their own usage).

Don’t get me wrong: I like Nepomuk and it possibilities for Amarok. It is not useless slow. In fact I am using it as my main collection backend in Amarok for months now. But it is in a similar state as KDE 4 in pre 4.0 days. You could use it but it not feature complete, it is not really stable it has its issues and there will be major changes to some of its parts. Well I hoped to have it (and the related Nepomuk service) in a better shape by now. Sorry for that, my time is very limited at the moment but work has not stopped fully and I am still planing to bring it into a useful shape.

A few words on the Nepomuk service: It will monitor Nepomuk/Strigi for new music and use taglib to read data Strigi can not read (yet?) to fill it. It then creates new music (tracks, artists and so on) resources in the Nepomuk storage. It should also inform interested applications about new music. Overall it aims to have always all music of the user in an easy to access way available for use in media players, music management applications and others.

That should make it easier (and faster!) for Amarok (and others) to use the data.

For example at the moment (ontology not final) to get a QStringList of all artists of the music on the computer in your application is as easy as (when using Strigi, Nepomuk and the unreleased service) :

QStringList artists; QList<Nepomuk::Resource> artistsResources = Nepomuk::ResourceManager::allResourcesOfType( "http://purl.org/ontology/mo/MusicArtist" ); foreach( Nepomuk::Resource &artistResource, artistResources) { artists << artistResource.label(); }

The flexible Amarok 2 collection framework will allow both (Sql and Nepomuk) collection living together at users choice and maybe in a few years Nepomuk (with faster backend?) could become the default.

Again too long since my last blog post. For those who are new to my blog: I (DanielW in IRC) am the GSoC student working on bringing Nepomuk into Amarok.

So what has happend the last weeks? Amarok now writes statistics back to Nepomuk (playcount, last played date and so on). With the nepomuk search client and kio slave in playground you can search files for that (list for example all files played more than 10 times).

But what I really want to talk about are “real persistent playlists”:

Thanks to the new Filewatch service (already in svn (trunk and 4.1 branch))  Nepomuk can now track movements of files and update the metadata connected to them. (it uses KDirNotify and can only track file movements done from KDE applications).

I am using this in Amarok to have playlists which still work after renaming/moving files. This means you can:

• create and store a playlist
• close Amarok
• move the files around/rename them
• start Amarok and your playlist still works

Amarok also monitors changes to the data at runtime. I first planed to make a screenshot (without it, it is not real but you can not see it on a screenshot. So I made a screencast. Here it is (download in high quality (6 MB))

(sorry for poor Youtube quality, get the real one)

Now the technical part:

It works by creating and storing a uuid for every track used in Amarok. It then uses this uuid in the URL of the playlists. That works but is no perfect solution. In the long term (after SoC) I will have to create track (and album) resources (which link to the actual files) in Nepomuk. This will solve this without the uuid and bring other possibilities but also a lot of new problems.

You can try it out now (it is in svn of Amarok) but expect bugs and missing features.

And..

see you there