GNOME Bugzilla – Bug 575110
Downloading Cover Art Eats CPU Usage Till Process is Killed
Last modified: 2009-03-23 22:46:32 UTC
Please describe the problem: Downloading cover art works up till ~99% where it will freeze and eat CPU cycles until Banshee is killed, even if the Cover Art downloading is canceled. Banshee continues to function normally during this. Steps to reproduce: 1. Download Cover Art 2. 3. Actual results: Cover Art is downloaded and then stops, CPU usages jumps to 85%+ for a Core 2 Duo. Expected results: That CPU cycles don't get eaten. Does this happen every time? If a new song is added to the library I think yes. Other information:
Could you run the commands given in comment 9 of bug #548131 ? I think it might be the same problem, and it seems the fix hasn't made it into 1.4.3.
It does seem to be the same bug, except I ran the commands from comment 9: sqlite3 ~/.config/banshee-1/banshee.db "select count(*) from coretracks where albumid not in (select albumid from corealbums)" sqlite3 ~/.config/banshee-1/banshee.db "select count(*) from coretracks where artistid not in (select artistid from coreartists)" and both return a 0 value. I am not sure what this means.
It means it's certainly a different bug. Could you please run the following command : banshee --debug --debug-sql > banshee.log reproduce the problem, and attach the banshee.log here.
Created attachment 130983 [details] log file Sorry the logfile is so large, I had to try and import music and download the cover art multiple times before I saw the error again.
The symptoms are the same as for bug #548131 : banshee seems to be stuck in an infinite loop running the 2 queries. But the cause seems different. Would it be OK for you to send me your database file ? I need to take a look at it to investigate further. It's ~/.config/banshee-1/banshee.db. Please send it to me directly by e-mail, my address is my bugzilla login (see the link on my name).
After looking at your DB, I figured out what's wrong : Some of the albums have a reference to a non existing artist. This is shown by the following query : select count(*) from CoreAlbums where ArtistID not in (select ArtistID from CoreArtists); So this is in fact the same underlying issue as in bug #548131 : 1. the query that counts the cover art to fetch returns >0, 2. but the query that selects the data returns nothing 3. Go back to 1 The fix for bug #548131 make the two queries identical, so it also fixes this case. I'm marking this as a duplicate, then. Corey, thanks for your help investigating this. *** This bug has been marked as a duplicate of 548131 ***