GNOME Bugzilla – Bug 601305
any update to podcast view uses causing long SQL queries (~5000ms)
Last modified: 2011-02-18 16:48:38 UTC
Any time I use the podcast view, banshee freezes for about 5 seconds while I have 100% cpu usage (that is 100% of both CPUs). If I change the selection criteria (eg Downloaded to All) the same thing happens. If I mark a podcast as old the same thing happens. Very annoying. I backed up .gconf/apps/banshee-1/ .config/banshee-1/ and .cache/banshee-1/ (There were no /apps/banshee or .config/banshee files on my system). I then tried `gconftool-2 --recursive-unset /apps/banshee /apps/banshee-1` but that does not seem to have made any difference. It still takes about 5 seconds of 100% cpu before the UI updates after I click on anything. I then tried just deleting all the files: $ rm -r .config/banshee-1 $ rm -r .cache/banshee-1 $ rm -r .gconf/apps/banshee-1 And banshee was responsive (once it had started, ps -ef reported that there was 9 seconds of time used by banshee after starting up). I've restored it, and it is unresponsive again. I have only 62 items in my music library. However I have 20 podcast feeds, with a total of 1699 items. I don't know if that would overly stress banshee? I would hope not. I tried 'banshee --debug' - there was no output during the periods of 100% cpu usage. If I disable it then banshee is nice and snappy. But when it is on, jumping around within the podcast functionality causes 100% cpu for a bit. When it is on, jumping around in other bits is quite fast actually, but as I generally use the podcast stuff that would be why it seems slow. Just a note about my usage - I only download a fraction of the podcasts, but I like to have them there and see what topics are covered so I can decide which ones to download. Is this a reasonable use case, or will I have to remove the podcasts that I only listen to the occasional episode of? It's not just generating a big list view that causes slowness. (New Items AND Downloaded AND All Podcasts) is normally around 10-20 items. If in that I mark an item as old, it still takes 5 seconds of 100% cpu to do that. I have downloaded git head, and the behaviour is the same. I thought I could use monodevelop to pause banshee while at 100% cpu and get a stack trace to see which bit of code it is stuck in, but I have been unable to do this. If someone can provide instructions for how to do this I am happy to post the stack trace. I use ubuntu 9.10, x86_64. The version in 9.04 didn't seem to have this problem. Originally documented at https://bugs.launchpad.net/ubuntu/+source/banshee/+bug/396268
You can get a stack trace by running the "kill ..." command given in this page : http://banshee-project.org/contribute/file-bugs/ My guess is that the CPU usage is caused by SQL queries. You can have banshee output all sql queries by running this command : banshee --debug-sql > sql.log Please attach the sql.log file to this bug.
Created attachment 147371 [details] Output of banshee --debug-sql
Notes on the above log: I selected the podcasts at 13:31:21 I changed All Items -> Downloaded at 13:32:35 I marked a podcast as old at 13:33:38 There were sometimes 2 seconds of cpu without anything being written to the log (I ran it as $ banshee --debug-sql | tee sql.log )
Created attachment 147376 [details] Stack trace during 100% cpu period obtained during selection of podcasts by $ kill -s QUIT $(pidof banshee-1); cp ~/.config/banshee-1/log ~/banshee1.log
Reopening as requested information has been provided.
These suspects are spending an awful lot of time: [Debug 13:30:28.349] Executed in 4655ms SELECT COUNT(*) FROM CoreTracks,CoreArtists,CoreAlbums, PodcastSyndications, PodcastItems, PodcastEnclosures WHERE CoreArtists.ArtistID = CoreTracks.ArtistID AND CoreAlbums.AlbumID = CoreTracks.AlbumID AND CoreTracks.PrimarySourceID = 2 AND PodcastSyndications.FeedID = PodcastItems.FeedID AND CoreTracks.ExternalID = PodcastItems.ItemID AND PodcastItems.ItemID = PodcastEnclosures.ItemID AND CoreTracks.PrimarySourceID = 2 AND PodcastItems.IsRead = 0 [Debug 13:30:31.222] Executed in 2871ms DELETE FROM CoreCache WHERE ModelID = 3; INSERT INTO CoreCache (ModelID, ItemID) SELECT 3, CoreTracks.TrackID FROM CoreTracks,CoreArtists,CoreAlbums, PodcastSyndications, PodcastItems, PodcastEnclosures WHERE CoreArtists.ArtistID = CoreTracks.ArtistID AND CoreAlbums.AlbumID = CoreTracks.AlbumID AND CoreTracks.PrimarySourceID = 2 AND PodcastSyndications.FeedID = PodcastItems.FeedID AND CoreTracks.ExternalID = PodcastItems.ItemID AND PodcastItems.ItemID = PodcastEnclosures.ItemID AND CoreTracks.PrimarySourceID = 2 ORDER BY PodcastItems.PubDate DESC Both queries appear a couple of times in the log with similar long runtime.
Sorry for the late reply. I suspect the queries found by David are not using the indexes as they're supposed to. If you still have this problem, could you please send me you database file by e-mail ? The file is ~/.config/banshee-1/banshee.db My e-mail is my bugzilla login.
any news for this report?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!