Version: 2.2.2-beta1 (using KDE 4.3.4) Installed from: Gentoo Packages Amarok 2.2.2-beta1 gained support for custom labels assigned to each track, a feature already present in Amarok 1.4 series. It would be great if the 1.4 collection importer could also import labels from the old collection. It would make the transition even smoother! Anyways, thanks for such a great player and keep it rocking!
i have added label support for the amarok 1.4 importer using a current git snapshot. and i finally managed to import my labels. but it was a big struggle. in FastForwardWorker.cpp::run() the track->create<Capabilities::StatisticsCapability>(); call only works if the track isn't already in the database, but then adding the labels doesn't work. so what i had to do was removing the amarok 2 database, run the importer without having the collection scanned before, then scan the collection and restart amarok and then run the importer again to import the labels. on the second run track->create<Capabilities::StatisticsCapability>(); will fail but labels can be added anyway. i don't know what's wrong there but i don't think that the code i wrote should be added to amarok as long as it doesn't work correctly. btw. the problem that track->create<Capabilities::StatisticsCapability>(); fails on existing tracks of course does not only prevent the import of labels but also the import of statistics.
Daniel, do you have patches?
i didn't post them in the first place because i thought somebody could tell me something about the track->create<Capabilities::StatisticsCapability>() problem before i post buggy patches here. anyway, here is the patch file for src/databaseimporter/amarok14/FastForwardWorker.cpp
Created attachment 43842 [details] patch for the fast forward database importer to support labels (dirty)
(In reply to comment #3) > i didn't post them in the first place because i thought somebody could tell me > something about the track->create<Capabilities::StatisticsCapability>() problem > before i post buggy patches here. I found it!!! It took me whole day... It was buggy CollectionManager::trackForUrl() that didn't create capability delegate. The fix is in [1]. Daniel, would you mind if I tried to incorporate your patch into my repository clone on gitorious [2] and then request a merge to upstream? The branch already contains several cleanups etc. Sure I'm going to give you proper credit. [1] http://gitorious.org/~strohel/amarok/strohels-amarok/commit/1b1dc3ebe421b92fa2777f98ff6e04eecb0e724d [2] http://gitorious.org/~strohel/amarok/strohels-amarok/commits/importer-new Regards, Matěj
(In reply to comment #5) > Daniel, would you mind if I tried to incorporate your patch into my repository > clone on gitorious [2] and then request a merge to upstream? Of course not, that's the whole idea ;) Great to hear you found the bug, thank you for the good work. Greetings Daniel
Here we go, the merge request can be tracked here: http://gitorious.org/amarok/amarok/merge_requests/170 When on it, I tried to make it as robust as possible, importing now should behave correctly in almost all cases. Daniel, you may heave fun finding out what your patch evolved into and reviewing it. :-)
hi, just wanted to say that i'm using an amarok build with Matěj's changes to SqlRegistry.cpp for a while now and before that amarok would sometimes not let me edit the metadata of some tracks (disabled inputs in the tag editor and/or no url in the url line edit in the tag editor). this never happened again since i applied the patch, so it seems like this fixed the bug.
Daniel, if you check the merge request you would see that this is work in progress.
fixed in 22eaab5acaff44ba6c6f665cfecb72038b768491