GNOME Bugzilla – Bug 573071
Banshee hogs CPU on Next Track button click
Last modified: 2009-03-05 16:48:08 UTC
I'm running banshee 1.4.2 on openSuSE 11.1. I upgraded Banshee itself and some additional packages from the Banshee repository. Banshee loads OK. The first song (track1) in a playlist starts immediately on Play button click. Banshee CPU usage settles into around 4+%. If I click the Next Track button, the track (track2)starts playing immediately also. But Banshee CPU usage jumps to 90+%. The track2 continues to play. If I click the Next track button again (to play track3) Banshee interface does not respond to the request. The current track (track2) continues to play until it completes. Some time after completion (usually a couple minutes) the next track (track3) will begin to play. CPU usage continues to be 90+%. Through all this Banshee does NOT crash; the interface is very slow to respond and it takes a long time to complete the request. I've noticed the same behavior if using a specific playlist and in shuffle mode. If I let track1 play to completion (no Next Track button click), the next track plays but Banshee CPU usage again jumps to 90+%. I will attempt to attach the log from kill SIGQUIT.
Created attachment 129466 [details] kill SIGQUIT output for banshee 1.4.2
Does the CPU usage stay at 90% for several minutes between track changes ? Could you please start banshee with the following command from a terminal ? banshee-1 --debug-sql > banshee.log Play a few tracks, stop banshee and then attach the banshee.log file here. The file will show the queries banshee is making on its database and their execution time. Please also tell us how many tracks you have in your library.
Created attachment 129532 [details] banshee-1 --debug-sql log Per your request, debug log is attached. Also: Q: Does the CPU usage stay at 90% for several minutes between track changes ? A: Once 2nd track started to play CPU usage went to 90+% and stayed there until I quit the app. CPU Usage never dropped. Q: Please also tell us how many tracks you have in your library. A: 1284
Bertrand, Do you require anything else? Dave B.
Sorry, got distracted by other shiny bugs ;) There's a query that is ridiculously slow on your system : around 636162ms, that 10 minutes ! A similar query takes less than 10ms on my system. PLease make a backup of the database file : cp ~/.config/banshee-1/banshee.db ~/banshee_backup.db Then run the following command in a terminal : sqlite3 ~/.config/banshee-1/banshee.db "VACUUM; ANALYZE;" This will not modify your data, but it might help improve performance. See bug #555937 for a discussion about this. If this doesn't solve the problem, please send me the banshee_backup.db file by e-mail (adress is in the link on my name).
Bertrand, VACUUM; ANALYZE on the database seems to have cured what was ailing. Thanks for your help and patience. Have fun stepping on your shiny new bugs. :) BTW, bug 555937 seemed to indicate that it wouldn't hurt to periodically perform the above procedure. Any downside to doing so? Dave B.
I'm marking this as a duplicate of bug #555937 then. Out of curiosity, could you run "banshee --debug-sql" again now, try to find the query that was taking more than 600000ms and see how much it takes now ? Please add that in a comment to bug #555937. Except the time taken by the ANALYZE command being added to banshee's startup, I can't see any downside to it. *** This bug has been marked as a duplicate of 555937 ***
Dave, can you send the backup version of your database to Bertrand or me so we can try to figure out if there's something in it that we could detect and trigger the VACUUM/ANALYZE automatically? Thanks.