Wednesday, 25 July 2012

Amarok StatSyncing GSoC: weeks 8 and 9

Yes, I'm still working on my GSoC project about statistics synchronization in Amarok. I've somehow skipped the last report (I was too deeply immersed in coding), to this one will be a bit more beefy. In short, I've fixed some bugs of the EngineController (the thing actually responsible for playback) that negatively affected scrobbling first and then I've rewrote the class that actually scrobbles the tracks.
Little side-effect of improvements: correction suggestions
What I've done in week 8:
  • The rather big patch series that fixed data-loss bugs was finally merged to master to be included in Amarok 2.6 release candidate. Please give it a good testing.
  • Improved EngineController and Phonon interaction with regards to meta-data changes.
  • Improved MetaStream classes that represent audio streams. They now implement statistics (and some other fields) so that you can for example see how many songs you've listened to on particular stream. The statistics are forgotten on Amarok exit though.
  • Improved detection of "track finished playing" in EngineController. This fixes the "play count increased by 2" bug and may fix other issues with weird playlist playback.
  • Above 3 fixes (and a little more) are included in a review request that I intend to merge into master for 2.6 release candidate and in enginecontroller-fixes branch of my Amarok repository clone. This should be the last thing blocking the RC.
What I've done the last week:
  • Rebased my gsoc  branch on top of liblastfm1 which is Harald Sitter's work on porting Amarok to liblastfm >= 1.0. I need some its features and Amarok 2.7 will depend on it anyway.
  • Made EngineController detect some meta-data changes in streams and interpret them as song changes. This makes scrobbling possible even when listening to an infinite stream.
  • Cleaned up some Amarok code interfacing to do it in more clean way.
  • Rewrote ScrobblerAdapter (responsible for scrobbling) to use all the new EngineController goodness. This allowed to ditch all the hacky code that tracked currently playing song by itself. This is also a preparation to splitting scrobbling code into controller/scrobbling service, which will allow to plug in different scrobbling back-ends (not just in future.
  • Fixed the MutiTrack API. Many streams (for example ones in the Internet category of the Media Sources pane) use it and it was a bit broken yielding broken meta-data updates, track-advancing, scrobbling etc.
  • Above fixes are published in my usual gsoc review request and are to be found in gsoc branch of my repository.
Problems I've faced:
  • EngineController code is convoluted. The worst thing is that there is a lot of code for special cases (multi-playback, multi-source, bounded-playback tracks) that is used infrequently. That code tends to break as it is little tested and sometimes not updated to reflect newest changes.
  • EngineController has to deal with different phonon back-ends and this is delicate. Phonon-vlc likes to emit aboutToFinish() twice in some cases while phonon-gstreamer likes to emit currentSourceChanged() twice and metaDataChanged() even more often (witch no reason). EngineController has to be written very carefully not to explode in case of such rough handling.
What's next:
  • Continuing the work on scrobbling and synchronization. I'm a little bit behind the schedule with it currently, but the way is paved now.
  • I'll need to push some changes to liblastfm to make everything planned possible. The upstream is however pretty alive so this shouldn't be a big problem.
You can test my work by pulling and building gsoc branch of my Amarok git repository clone, it already works quite well! I also publish weekly diffs with more technical details on KDE's review board which may be a more convenient way to review my code and to comment on it: week 1 week 2 week 3 week 4 (week 5 done in →) week 6 week 7 (master bugfix) week 8 (master bugfix) week 9


  1. UI for this is bad. I suggest to use Plasma Notifications for it. ;)

  2. I use standard Amarok notification system, this is a standard UI for "long" messages that all other parts of Amarok use. Changing these notifications is beyond the scope of my project.

    Fortunately, our logging system is modular, so you can easily write a back-end for plasma notifications (or rather standardised freedesktop notifications ) so that we can let our users choose. :-)

  3. If i could i would do it ;) I'm not a dev at all. Sorry. But, if you would find some additional time to write it for us, we would be thankful :)

  4. The thing here is that we (developers) don't know how many users would actually make use of it, and therefore we tend to focus on things that bother us more. KDE Brainstorm is perhaps a good place to convince developers that particular feature would be useful for many.

  5. Excellent work for the bug fixing, thank you!