Bug 174851 - Changing the grouping methods doesn't work in Jamendo database
Summary: Changing the grouping methods doesn't work in Jamendo database
Status: RESOLVED FIXED
Alias: None
Product: amarok
Classification: Applications
Component: Internet Services (show other bugs)
Version: 2.3-GIT
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: 2.3.1
Assignee: Amarok Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-11-11 12:03 UTC by Sebastian Vahl
Modified: 2010-01-03 16:11 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sebastian Vahl 2008-11-11 12:03:06 UTC
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.
Comment 1 Sebastian Vahl 2008-11-11 12:04:32 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
Comment 2 Nikolaj Hald Nielsen 2008-11-11 14:45:49 UTC
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?
Comment 3 Nikolaj Hald Nielsen 2008-11-11 14:49:54 UTC
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.
Comment 4 Seb Ruiz 2008-11-11 21:45:41 UTC
Nikolaj, you might've forgotten to create an sql index on the genres table.
Comment 5 Nikolaj Hald Nielsen 2008-11-11 22:43:53 UTC
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. 
Comment 6 Nikolaj Hald Nielsen 2008-11-11 23:01:31 UTC
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. 
Comment 7 Nikolaj Hald Nielsen 2008-11-11 23:10:34 UTC
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
Comment 8 illogic-al 2008-11-12 01:12:11 UTC
oops.
Comment 9 illogic-al 2009-01-12 01:07:57 UTC
PING!
Comment 10 Myriam Schweingruber 2009-08-02 13:06:08 UTC
Nikolaj, any news on this? Do we still use the old API?
Comment 11 Nikolaj Hald Nielsen 2009-08-02 13:50:05 UTC
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.
Comment 12 Nikolaj Hald Nielsen 2009-08-02 13:50:15 UTC
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.
Comment 13 Nikolaj Hald Nielsen 2010-01-03 16:11:13 UTC
I think this has been fixed for quite some time now. We are using a newer xml file wich is updated with new content.