Sunday, 9 December 2012

Amarok 2.7 Beta To Be Released Soon, Try Statistics Synchronization!

Heya, Amarok 2.7 Beta is slated to be released in any day now, one of the features it brings is Statistics Synchronization, a result of my GSoC project. Here's a short guide to get the best from it.

Unattended Synchronization

Getting started is utterly simple, just answer Yes to the above question that pops up when you connect a capable media player (currently just iPods) and you're done! Amarok will work hard in the background from that point to make sure your ratings, first/last played times, play counts and labels are synchronized between all participating collections (Local Collection is included by default) and won't disturb you unless there's a conflict. If you have Last.fm plugin configured, tracks recently played on your iDevice will be automatically scrobbled to Last.fm as part of the synchronization.

Conflicts & Synchronize Statistics Dialog

When you for example change a song rating simultaneously in Amarok and on your iPod, Amarok doesn't know what rating it should use. In this case, the last step of the synchronization is made interactive: a dialog with synchronization preview shows up. On top, you can see a few tabs:
  • Matched Tracks: the essential tab where the tracks that Amarok found to be in more than one of your Collections are grouped together. You can tell which tracks and fields are going to be updated using the background: light green above means a new/updated field and light red means an old/overwritten one. In case of rating or label conflict you can resolve it using the check boxes. Conflicts can also be resolved in batch using the buttons below the list, which affect all applicable tracks, not just the shown ones. You don't need to resolve all conflicts, the particular field of the particular tracks won't be synchronized.
  • Unique Tracks: a list of tracks found just in one collection. You can use this as a some kind of a difference view of your collections. This tab supports track dragging.
  • Excluded Tracks: sometimes a track matching is ambiguous. This can happen for example when you have 2 tracks with identical meta-data in your collection. Such tracks are excluded from synchronization in order not to cause disorder.

Manual Syncing & Last.fm

At any time, you can start the synchronization manually from Amarok Tools menu using the Synchronize Statistics... entry. You can override what collections and fields to synchronize in this case. If you have Last.fm plugin enabled and configured, you can also choose to synchronize your play count and labels with Last.fm; unattended synchronization with Last.fm is not possible, because that would put too much stress on their servers. Also please note that track matching when Last.fm is selected can be very time-consuming (one hour is not unusual), but you can use Amarok freely while this happens.
Synchronizing with Last.fm is a bit tricky, because by default it auto-corrects some common misspellings during scrobbling. So it can happen that even if you scrobble many track plays, it doesn't show up in Matched Tracks because Last.fm knows it under a slightly different name. Fortunately you can opt-out from auto-correction on Last.fm site and the change is applied also to your past scrobbles, both options have some downsides though:
  1. auto-correct off: your tracks are matched properly, but if you change your tags after some time (because of an actual typo for example), your play-count on Last.fm site will be split into 2 entries.
  2. auto-correct on: can track play counts even if you correct the tags over time, but you have to use Last.fm's preferred spelling or your track's won't match.

Configuration

You can configure all aspects of statistics synchronization in a new Amarok Configuration tab named Metadata. Apart from configuring which collections should be synchronized automatically you can decide what fields you want to synchronize and edit a list of labels excluded from synchronization (useful if don't what some of your Amarok labels to appear on your Last.fm profile).

Technical Remarks

Curious what the internal algorithms and principles of the synchronization are? Here you go:
  • Tracks are matched using their meta-data case insensitively. The framework itself and both iPod and Local Amarok collections can match using: title, artist, album, composer, year, track number, disc number. Last.fm can only match using title, artist and album. Common subset of matching fields of selected collections is used. That's why you can get tracks excluded from synchronization due to ambiguity when you include Last.fm in syncing.
  • Local Collection can synchronize everything.
  • iPod Collection can synchronize everything except labels, although and iPod won't update first played time by itself.
  • Last.fm can read play count, labels and rating (see below) and it can write labels and rating; play count is updated by means of scrobbling. In theory, first/last played time should be available too, but their API doesn't export it currently in a efficient way.
  • Last.fm rating is implemented using special tags like 4 of 10 stars. You can opt-out from using these, then Amarok will ignore this kind of tags.
  • Conservative reduction functions are used for synchronization of individual fields, for example minimum-of is employed for first played time and maximum-of for last played time. Play count uses maximum-of + special case for iPods that can report recent play count so that you don't miss anything even if you play a track simultaneously on an iPod and Amarok.

Tips

  • Use Last.fm synchronization as a back-up of your precious Amarok data!
  • Use Last.fm synchronization as a tool to synchronize your listening data from multiple places!
  • New! Use inter-collection synchronization and the new Nepomuk Collection to keep your Amarok ratings in sync with your Nepomuk (i.e. shown in Dolphin) ones. Nepomuk collection should be able to handle more fields in future.

Test it!

I've worked on this and tested it myself for a rather long time, but there will be for sure some bugs that got through. Please test this in Amarok 2.7 Beta or current git and report any bugs you find so that I have a chance to fix them for Amarok 2.7 final. Thanks and have fun!

Tuesday, 14 August 2012

Amarok 2.6 Released! Enjoy great iPod support & fixes all over the place

Finally, after endless weeks of waiting, the beast in the form of Amarok 2.6.0 has been released to the wild!
This release is a bit special to me because it is the first one to include a significant contribution from me - most notably the totally rewritten iPod support. I must say thank here to everyone who tested it in the beta phase; your bug reports helped to polish it to otherwise unachievable level for the final release.

My other personal favourites of this release include transcoding at more places and crucial bug fixes so that Amarok doesn't loose your ratings and stuff when it doesn't have to. This is just one item of the multi-page long list of fixed bugs.

In short, Amarok 2.6 shines like never and is an absolute must for you. :-) Do you like it? Me and other awesome Amarok & KDE volunteer hackers will meet in Switzerland's Randa to code, discuss and plan immersely, please consider donating to help us cover the expenses. Thanks!

Saturday, 11 August 2012

Amarok StatSyncing GSoC: week 12 - heat up your Last.fm accountz

Hi, apart from packaging Amarok 2.6 (look forward to it!) I've also made significant progress on my GSoC project about statistics synchronization in Amarok this week. In short, 2-way synchronization of your precious metadata with Last.fm works now.

Notice that rating and labels are already synchronized.
This was the last big milestone of my project and I'm happy to have it completed just before GSoC's suggested pencils-down date. I must say that implementing all the Last.fm stuff was easier than expected, but that's probably because of the solid foundations of the framework that have been laid earlier. :-)

Compare with screenshots from earlier posts.
What I've done this week:
  • Restructured internal code of StatSyncing::Controller to be even cleaner with regards to maintaining synchronizable collections.
  • Polished the UI of the Choose Providers dialog. It is much cleaner now and will make the KDE Usability team happy. See screenshot above.
  • Changed track matching to be case-insensitive. It would be a pity not to match 2 tracks just because the other one is not properly capitalized.
  • Implemented logic to synchronize labels across collections. For each track, you can tick which collections will be the sources of labels. Resulting labels are then the union of the checked ones.
  • Implemented matching with Last.fm tracks of your Last.fm Library; you have to have Last.fm plugin enabled and configured for this to work. Last.fm can match tracks by their artist, album and title.
  • Implemented reading of Last.fm metadata - it can provide play count and tags, and we use a trick to store rating using tags.
  • Implemented updating of Last.fm metadata - it can update tags and, with our little trick, even rating. See screenshot below.

My Last.fm tags look like this now. :-)
Problems I've faced:
  • First & last play dates sadly aren't provided by Last.fm, although they have the data. Fortunately the framework is flexible enough to gracefully cope with them missing. But I'll try to convince Last.fm staff to include them in their web API.
  • liblastfm has a bug in its Track::removeTag method which breaks tag removal. I've fixed it, but the bug will hit you unless you use my liblastfm branch or until liblastfm incorporates the pull request and releases it.
The lasts bits left to do:
  • Buttons for mass-resolution of label conflicts in the Matched Tracks dialog.
  • Configuration option to exclude some labels from synchronization.
  • Option in the Last.fm plugin to opt-out from using the fancy rating tags.
  • Better error reporting.
  • Further polishing of the Matched Tracks dialog as suggested by the KDE Usability team.
  • Scrobbling tracks played on iPods to Last.fm - all support code is ready, I only need to devise an algorithm for guessing scrobble times (we only have last played time and play count).
You can test my work by pulling and building the gsoc branch of my Amarok git repository clone. It works really well now! 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 weeks 10 & 11 week 12

Tuesday, 7 August 2012

Amarok StatSyncing GSoC: weeks 10 and 11

Yes, I'm still working on my GSoC project about statistics synchronization in Amarok. It seems that bi-weekly reports became common here. That's because I enjoy coding much more that writing about it. Last 2 weeks I've worked on reworking existing Amarok Last.fm scrobbling code and on back-end infrastructure for Last.fm synchronization.
Configuration is moved to a standard place per feedback on usability review
What I've done last 2 weeks:
  • Improved USB Mass Storage Collection to be more friendly towards statistics synchronization.
  • Reworked existing Last.fm scrobbling architecture in Amarok. Now there are ScrobblingServices and StatSyncing::Controller manages them and orders them to scrobble etc. This will make it easy for new services to be added in future (e.g. for Libre.fm). Existing Last.fm ScrobblerAdapter was turned to ScrobblingService implementation.
  • Changed memory-management of some internal classes to be less error-prone.
  • Moved some items of the existing "Local Collection" configuration page into newly created "Metadata" page. Local Collection page was overcrowded and some options didn't apply just to Local Collection.
  • Added statistics synchronization options to the "Metadata" page of the Amarok configuration dialog. This should be a solution to usability problems of the original "Synchronize Statistics" dialog.
  • Fixed various smaller bugs.
  • On a less related note, I did the Amarok 2.6 Release Candidate tarball, which took some of my time.
Problems I've faced:
  • Working on UI is time-consuming sometimes. Polishing UI behaviour (disabling not applicable buttons etc.) takes a lot of code.
What's next:
  • Last groundwork for Last.fm synchronization (which is nearly done now).
  • Actual synchronization with Last.fm!
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 weeks 10 & 11

Wednesday, 1 August 2012

Amarok 2.6 Release Candidate is out!

Are you waiting impatiently for KDE 4.9? Warm-up your compilers with Amarok 2.6-RC that has been released just now! There have been a couple of bigger fixes since Beta 1, so we want to make sure that nothing hits your grandma in 2.6 final. Give it a good testing and report possible bugs to Bugzilla as usual. Thanks!

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 Last.fm scrobbling first and then I've rewrote the class that actually scrobbles the tracks.
Little side-effect of Last.fm 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 Last.fm 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 Last.fm) 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 Last.fm 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

Tuesday, 10 July 2012

Amarok StatSyncing GSoC: week 7 aka Where are all my statistics? And where is Amarok 2.6?

Yes, I'm still working on my GSoC project about statistics synchronization in Amarok. Past week was a bit unusual, because I've worked mainly on fixing bugs in Amarok and not directly on statistics synchronization. I think it is justifiable, because a) the bugs are about data loss which includes statistics b) they block the 2.6 release c) my GSoC timeline allows me to do so as items for week 7 are already implemented d) the data loss bugged me for long time. :-)

What I've done this week:
  • Fixed bug 292245 where statistics, lyrics and labels of a song are lost if its meta-data are changed in Amarok and then it is moved. The fix is already pushed to master, enjoy!
  • Fixed bug 298275 where statistics of all tracks are lost in some cases such as toggling Local Files & USB Mass Storage Backend in Configuration -> Plugins (don't do it!). This turned out to be rather beefy patch series that currently awaits review (hi Ralf!) as it touches some delicate parts of Amarok.
  • Made SqlScanResultProcessor clean up the mess left by the Organize Files functionality (bug 289338), included in above series.
  • (Hopefully) made Amarok much more cautious when it comes to destructive operations in order not to lose precious data such as ratings when something goes wrong. For example, no entries are removed from the database if a serious error occurs before. Included in above series.
Problems I've faced:
  • SqlScanResultProcessor was rather hard to understand. I spend hours just to realise what's going on.
  • Debugging collection scanner is time consuming. I've performed countless code → build → restore database → test cycles.
What's next:
  • I'll file usability review request about GUI of statistics synchronization.
  • I'll move on to the second part of my project - Last.fm integration in statistics synchronization.
Fortunately, I finally succeeded and all data loss bugs I was able to reproduce are fixed now. This means that the Amarok 2.6 is closer now because both main fixed bugs were marked as release blockers. On the other hand, 2 bugs still remain and our release guy, Bart, is time-constrained currently (fortunately he documented the whole process well).

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)

Monday, 2 July 2012

Amarok StatSyncing GSoC: week 6

Yes, I'm still working on my GSoC project about statistics synchronization in Amarok. I've skipped one report, because last week I was busy with my university exam and real life. This week is another story, I've added synchronization preparation page (so that you can check what to sync), implemented automatic non-interactive synchronization and more.
New dialog this week: preparation for synchronization.
What I've done this week:
  • Factored Meta::Track::recentPlayCount() into capability, it didn't have much sense.
  • Added above page for the first step of the synchronization, added Back button to the second page.
  • Made Amarok remember syncing preferences: what fields and collections to synchronize. Local Collection and iPod collections are checked by default.
  • Implemented automatic unattended synchronization: checked (or enabled by default not-unchecked) collections will be synchronized automagically as soon as they appear or on start-up (with some delay to let them settle). If ratings conflicts are detected, it will fall-back to interactive mode and you can make the background job interactive as well.
  • Improved minor visual things (ratings are now nicely painted using stars) plus did some code clean-up so that first part of my GSoC approaches merge-ready state.
Problems I've faced:
  • I've fought with QTableView and sizeHint()s a bit, but I've won. :-)
  • The dialogs probably need usability and design review, sure I'll contact KDE Usability group before merging.
What's next:
  • According to my schedule, I've fulfilled week 5 and week 7 with this (funny). More importantly, first part of my project is roughly done by this week's advancements, and I'm quite happy with the results. I think that the unattended synchronization is particularly useful: you just tell Amarok what to synchronize once and it does everything else for you; that's what 99% users will be using most of the time in my opinion.
  • This week I'll finally start looking at Last.fm things.
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 6

Sunday, 17 June 2012

Amarok StatSyncing GSoC: week 4

Hi, in case you forgot, I'm working on my GSoC project about statistics synchronization in Amarok. This week, I've made the behaviour (as opposed to the looks) of the synchronization dialog perfect. Do you think I'm being too bold? Check the rest of the post. :-)
I add a couple of buttons each week, I promise I won't continue endlessly. :-)
What I've done this week:
  • Eliminated some false-positives in detection of rating conflicts (uses some heuristics, but will do)
  • Made "Updated Tracks" and "Tracks With Conflicts" combo-box options enabled only if there are actually some such tracks.
  • Made synchronization aware of iPod's recent play count feature - now the synchronized value is correct even if you play the same song in Amarok and on iPod simultaneously.
  • Added status bar so that you know the counts.
  • Qt's tree view combined with filtering can unfortunately forget which nodes are expanded. I've worked it around with some witty code. :-) On first show, tracks with conflicts have their nodes expanded.
  • Added the "Take Ratings From" button.
Problems I've faced:
  • While I'm generally satisfied with the dialog's behaviour, its appearance isn't particularly pleasing. I will for sure fix minor things like displaying rating with stars, but I'm not a usability expert. Fortunately, there seems to be an easy way to get it reviewed now.
  • To support iPods' recent play count, I've added a method to Meta::Track, which now seems rather unfortunate. I need to consult it with other Amarok developers, but probably I'll factor it into a Capability.
What's next:
  • Next week I'll make the synchronization dialog two-step: in step 1 you choose what fields to synchronize and what collections should participate.  What you see above will become the step 2.
  • I'm still a little ahead of my schedule and that's good. This means that I'll have a chance to look into Last.fm realms sooner. There is some activity on Last.fm code in Amarok from Harald Sitter recently (great!) and it turns out that rather big re-factoring will be needed.
You can test my work by pulling and building gsoc branch of my Amarok git repository clone, it already works! 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

Monday, 11 June 2012

Amarok StatSyncing GSoC: week 3

Hi, in case you forgot, I'm working on my GSoC project about statictics synchronization in Amarok. Previous report was rather early, this one is a bit late. The main success this week is that the synchronization actually works (best tested with iPods), hooray!
Progress on the Synchronize Statistics dialogue. You can see conflict resolution, updated fields would be in bold, but the are none.
What I've done this week:
  • Implemented ability to compute synchronized value for each field, this is shown in UI. Fields that are going to be updated are in bold.
  • Improve the UI to be able to sort, filter-as-you type and filter based on synchronization status (updated, not touched, having conflict).
  • Made the synchronization smart so that it for example doesn't want to update labels of an iPod track, which doesn't support labels at all.
  • Changed core Amarok classes so that first, last played time and play count can be written back to tracks.
  • Implemented actual synchronization worker on top of all this. The worker runs in a thread and is abort-able.
Problems I've faced:
  • There is currently no way to determine what statistics fields are supported by given Amarok collection. I had to use some heuristics as a temporary solution.
  • Setting some track fields is inconsistent in core Amarok classes. For example setRating() and setScore() are in Meta::Track while I really think they should be in a specialized class called EditCapability.
  • No other collection than the main one supports track labels currently (AFAIK), so I cannot really test this feature.
What's next:
  • I've already done much of the agenda for the next week, so:
  • I'll work on polishing the synchronization UI and behaviour a bit more to remove some corner-cases that currently exist.
  • I'll improve handling of rating conflicts: I plan the "Take ratings from..." button to mass-resolve unresolved rating conflicts.
You can test my work by pulling and building gsoc branch of my Amarok git repository clone, it already works! 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

Wednesday, 30 May 2012

Amarok StatSyncing GSoC: week 2

Hi, in case you forgot, I'm working on my GSoC project about statictics synchronization in Amarok. This is my second weekly report which comes a bit earlier because I'll be travelling to Budapest till the end of the week, but check the diffs, I've already done a week's worth of work. (or more :-)
UI showing how tracks from 3 collections are matched. Unique & Excluded tracks work, too.
What I've done this week:
  • Visible feedback for the job that matches tracks (little progress bar).
  • Renaming of core classes to have shorter names; all are in a namespace so no clash threats.
  • A class to handle one synchronization from start to finish (names Process).
  • 2 models (QAbstractItemModel subclasses) for matched and for single tracks to power the UI + helper model to share code between them.
  • Rudimentary UI for showing matched and single tracks as shown on the screenshot.
  • A bunch of smaller fixes to keep the code clean and maintainable.
Problems I've faced:
  • QStyledItemDelegate cannot display rich text. :'-( :'-(
  • QHeaderView cannot have minimum widths per each column. :-(
  • Keyboard navigation doesn't work in QTreeView once you set selectionMode to NoSelection.
What's next:
  • Performing the actual synchronization. Shouldn't be hard as everything is prepared by now.
You can test my work by pulling and building gsoc branch of my Amarok git repository clone, it already works (somehow)! 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

Saturday, 26 May 2012

Amarok StatSyncing GSoC: week 1

Hi, I'm Matěj Laitl and this summer I've been accepted to GSoC for Amarok to work on statistics synchronization between various collections and scrobbling services such as Last.fm. Here comes my first weekly report, enjoy reading it. :-) In short, I've worked on a background worker that will associate same tracks from various sources with each other.
Obligatory screenshot. Current visible effects of activating that action are none. :-)
What I've done this week:
  • Designed core (abstract) classes that will facilitate statistics synchronization for both collection and online service tracks: TrackDelegate and TrackDelegateProvider.
  • Implemented these interfaces for tracks from Amarok collections (e.g. Local Collection, iPod and USB Mass storage ones...).
  • Implemented controller, singleton class that is entry point to synchronization functionality in Amarok.
  • Implemented MatchTracksJob, a job that runs in background and matches tracks from multiple providers into track tuples with same meta-data.
Problems I've faced:
  • Encapsulating asynchronous API of some Amarok classes (QueryMaker) to be synchronous and thread-aware was a bit tricky.
  • I had hard time implementing lessThan() comparison function that needs third argument for Qt's qSort(). Function template did the job, but that made MatchTracksJob non-reentrant. :-(
  • It isn't clear what meta-data should participate in track matching. Some sources provide few of them (Last.fm provides just artist, album, title; sometimes less) while Local Collection and friends can provide much more. I've made MatchTrackJob generic with regards to matched fields with artist, album, title being mandatory and composer, year, track & disc number being optional.
What's next:
  • We've ongoing discussion with Bart Cerneels whether TrackDelegate is redundant or not. I've made sure to code in a way that it can be replaced in future without hassle.
  • The GUI to show matched tracks, providers etc.
You can test my work by pulling and building gsoc branch of my Amarok git repository clone, but beware that it currently contains an unrelated change (pending to be merged) that will make your Amarok database temporarily incompatible with current Amarok git master. Update: the change has been merged! 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

Wednesday, 2 May 2012

Accepted to (Amarok) GSoC, yay!

Hi, I'm Matěj Laitl and this summer I've been accepted to GSoC for Amarok to work on statistics synchronization between various collections and scrobbling services such as Last.fm.

First, let me thank Google for sponsoring such a wonderful programme that lets me code on open-source during summer - instead of having to take boring jobs involving proprietary software. Now, about my GSoC project.

"Statistics synchronization, sounds boring" you say? Maybe, but I'll polish it to perfection and the second part of the project, two-way synchronization with Last.fm, is as far as I know unparallelled among audio players. My personal goal is to make the UI as intuitive as possible, not getting in the way. My mentor is Myriam, Amarok's famous bug wrangler, user supporter and community worker so I'm pretty confident it will go smoothly.

For start I plan to come up with a couple of use-case scenarios and further iron-out the overall design (is it just me or do others get the best ideas while in shower?) during community binding period. (since I'm already quite bound to the community) :-)

What are your expectations for Amarok statistics synchronization?

Sunday, 15 April 2012

Amarok's rewritten iPod plugin: testers needed!

Little introduction first: I'm a student of theoretical computer science from Prague/Czech Republic and I've started contributing to Amarok last autumn by fixing some of its (mainly iPod-related) bugs.

It turned out that maintaining the iPod collection plug-in was rather painful due to its complexity that accumulated over time - and I got motivated to rewrite it from scratch by Amarok's Bart Cerneels. The effort is now over. Welcome the all-new iPod collection plug-in! (supports iPads and iPhones, too!)
Mandatory screen-shot of the rewritten iPod collection plug-in
What does the rewrite bring? Well, working playlists, transcoding, multiple concurrent transfers, working stale & orphaned tracks detection and elimination plus many more enhancements and bug-fixes. Thanks to the rewrite, some bugs in USB Mass Storage collection got fixed, too.

You'll get all these goodies with Amarok 2.6, which is slated for release in a month or (rather) two. But if you're brave enough, I encourage you to compile Amarok from source using Mamarok's awesome guide and try it now! Please report any bugs you find to KDE bugzilla and if it works, send me a screen-shot of the iPod Device Configuration dialog so that I know how it looks with models I don't have.

iPod collection plug-in is only tested on Linux and won't probably work out-of-the box on other platforms. There is a hope for Windows users, there seems to be an older version of the needed libgpod library in KDE on Windows repositories. It should be possible to port the newest version, 0.8.2, too. Have fun!