Version: amarok-1.94 (using KDE 4.1.2) OS: Linux Installed from: Fedora RPMs Description of problem: amarok seems not to be able to change the grouping methods in the Jamendo database. If you try a different "Group by" method, the album list would be cleared until you restart amarok. Also amarok seems to not quit properly when this issue happens. At least the amarok process is still active (ps -ae | grep amarok) and you have to kill it manually to be able to start amarok again. Version-Release number of selected component (if applicable): amarok-1.94-2.fc10.x86_64 How reproducible: ever Steps to Reproduce: 1. start amarok 2. switch to Internet/Jamendo 3. Update the jamendo database and wait until it's finished 4. change to a different method in "Group by" Actual results: nothing is displayed Expected results: the albums should be displayed with the chosen grouping method Additional info: I've started with a clean amarok configuration as advised in one of the beta release announcements.
This bug is also filed downstream in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=470786 There I've also attached the terminal output: https://bugzilla.redhat.com/attachment.cgi?id=323052
I have had a look at this, and technically, it works, just very very slowly. On my system switching to Artist/Album sorting takes about 170 seconds, during which time, the service is blank ( and other db driven services, such as Magnatune cannot change their sorting mode either ) The query in question is: "SELECT DISTINCT jamendo_artists.id, jamendo_artists.name, jamendo_artists.description , jamendo_artists.country, jamendo_artists.photo_url, jamendo_artists.jamendo_url, jamendo_artists.home_url FROM jamendo_tracks LEFT JOIN jamendo_albums ON jamendo_tracks.album_id = jamendo_albums.id LEFT JOIN jamendo_artists ON jamendo_albums.artist_id = jamendo_artists.id WHERE 1 GROUP BY jamendo_tracks.id;" Just for fun, I tried running the same query against an old amarok sqlite db ( using sqliteman ). sqlite completed this particular query in between 0.2 and 0.1 seconds every time I tried. So as far as I can tell, this bug seems to be caused by the switch to mysql-embedded which obviously handles some queries a lot worse than sqlite, despite being faster in most cases. Any mysql gurus out there who wants to take a stab at this?
Interestingly enough, Genre/Artist mode seems to work just fine. So it seems that this issue occurs with any query that leaves out the genre.
Nikolaj, you might've forgotten to create an sql index on the genres table.
Seb, I tried adding various index,but that did not help. It's also interesting to note that if you enter a filter value, the same query ( with an added filter constraint ) just flies.
Looking into it even more, it seems that without a filter, the result set is just too large if you try to list all artist or albums without the genre as the top level. While it might be fixable by somehow tweaking our db, I think a much better fix would be to port the Jamendo service to the new dynamic Jamendo API which seems to be really powerful. http://developer.jamendo.com/en/wiki/Musiclist2Api This would get rid of the local db cache all together.
SVN commit 883026 by nhnielsen: This is what an old ( and slightly crazy ) boss of mine used to call "Brutal Bugfixing". Simply cut out the parts that are causing trouble. Remove the "Artist", "Artist / Album" and "Album" sorting modes from Jamendo as they cause the db to choke if no filter is set. The code has been commented out with an explanation, so if anyone smarter than me can make it work, feel very free to do so and reenable it, but for now I think it is better not to have the options. The "real" fix for the long term will be to redo the Jamendo service, post 2.0.0 to use the new fancy Jamendo API ( http://developer.jamendo.com/en/wiki/Musiclist2Api ) BUG: 174851 M +6 -3 JamendoService.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=883026
oops.
PING!
Nikolaj, any news on this? Do we still use the old API?
WE are still using an older Jamendo API that is no longer updated with new content. Changing this requires a significant rewrite of the Jamendo xml parser. If anyone is willing to have a go at this I would be happy to "mentor" them.
We are still using an older Jamendo API that is no longer updated with new content. Changing this requires a significant rewrite of the Jamendo xml parser. If anyone is willing to have a go at this I would be happy to "mentor" them.
I think this has been fixed for quite some time now. We are using a newer xml file wich is updated with new content.