GSoC Status Update – Week 10

This is a status update for my Google Summer of Code 2013 project – implementing advanced statistics importers for Amarok. Please read the first post if you would like to know more about the project.


Last week I fixed Amarok 2.x embedded database importer. There were quite a few problems with handling an external database process:

  • if the QProcess object received commands (start(), kill(), terminate()) from a different thread than that which has created it, it resulted in wrong behavior, often in the form of a crash (can’t get much wronger than that)
  • the QProcess object does not encapsulate the process; it’s only an interface. When a QProcess object was destroyed while the process was still running, it issued a warning and killed the process with SIGKILL. Normally you’d want to stop an ongoing process with a SIGTERM, so manual lifetime management is needed
  • if the server has stopped (which it does, after a period of inactivity), calling QSqlDatabase::removeDatabase() resulted in a SIGPIPE signal from inside the MySQL driver
  • related to that, an old QSqlDatabase connection silently failed to work if the server has been restarted. There would be no warnings on QSqlDatabase::open().

There was also a question of waiting for mysqld process to be ready to serve. After some research I decided to adopt an approach that MySQL startup scripts (including the “official” script, mysql.server) use, which is to wait for the server’s PID file to be modified. Overall, I’m quite satisfied with the results; it’s reliable and fast enough.


By the way, there’s a new statistics synchronization target: Clementine.

clementine importer

I know how much you like pictures

This brings the total number of importers to six, and marks the end of implementing new importers. From now on, I intend to focus on existing code including, but not limited to, read-write capabilities and – of course – testing.


You may have noticed one additional target on the screenshot above: “Example.” Another thing I focused on this week was code deduplication and simplifying creation of new importers. To show off, I prepared a basic “Example” importer. Below is the full C++ code. Bear in mind that aside from the code, importers need a plugin’s *.desktop file and a CMakeLists.txt file. Also bear in mind that with this code the importer is already fully reconfigurable and instances of it can be created and removed at user’s leisure.

The effect

The effect

As always, you can check out my progress on my public Amarok clone. The branch is named gsoc-importers.

Thanks for reading!

2 thoughts on “GSoC Status Update – Week 10

  1. Anand R

    Hey – I use this Amarok’s feature to sync metadata with iPod. I have a question on field “Play Count”.
    Say, i listen to a song in my iPod twice and have listened on my laptop 5 times. When I connect to Amarok, when it syncs data should it not add the count instead of just replacing the count. At least there should be an option of having max of number or total.
    Keen to hear your views.

    1. Konrad Post author

      Hi! Please note that I’m not the author of the synchronization framework itself (it was a GSoC project of our release manager, Matěj Laitl). You’re right that an “optimal” way to do playcount synchronization would be to add the numbers. While I don’t know specific reasons Matěj opted for taking a maximum, I can come up with plenty of my own.

      The biggest of these is keeping track of what was already added – while we can do it through keeping a counter somewhere along with provider’s ID, if – for whatever reason – the ID changes we’re left with a mess of a playcount.

      Moreover, it operates on an assumption that the playcount reported by a specific provider is unique to it; in the case of providers representing media players this would mean that the playcount equals number of times a track was played by this specific player. This needn’t to be the case as other players also have statistics importing capabilities, and they can even utilize playcount stored in track’s own tags. We can easily end up counting plays multiple times, as Amarok doesn’t have a way to aquire such fine-grained information.

      Yet another point would be that two providers, let’s say representing Nepomuk and Local collections, can report the same track with the same number of playcounts, but StatSyncing framework doesn’t have means to determine that they are exactly the same. As it is right now, the framework doesn’t care if the provider is just wrapping a collection or maybe representing an iPhone, or even Banshee media player. I would argue that this is the correct way, even if we’re missing on small bits of functionality because of it.

      As you can see there are quite a few problems, and inside each of these are dozens of corner-cases. There’s no simple solution and it largely stems from the nature of statistics themselves – they aren’t standardized and every player/tag format/music manager has their own. Of course you should feel free to submit a wish on to get this implemented. :)

Comments are closed.