Summary: | Changing the grouping methods doesn't work in Jamendo database | ||
---|---|---|---|
Product: | [Applications] amarok | Reporter: | Sebastian Vahl <deadbabylon> |
Component: | Internet Services | Assignee: | Amarok Developers <amarok-bugs-dist> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | illogical1, nhn, rdieter |
Priority: | NOR | ||
Version: | 2.3-GIT | ||
Target Milestone: | 2.3.1 | ||
Platform: | Fedora RPMs | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Sebastian Vahl
2008-11-11 12:03:06 UTC
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. |