GNOME Bugzilla – Bug 740166
Start freezes Banshee for several minutes
Last modified: 2014-12-19 09:43:23 UTC
Created attachment 290749 [details] Banshee debug log during startup. When I start Banshee under Fedora 20 x64, it immediately freezes and takes several minutes (!) to be responsive again. I have to click "Wait" several times until I can start playing music. The same phenomenon occurs if I rate a track, play the next track or start a new track. Here are some specs about my Banshee/system/library: * Banshee 2.6.2 (2.6.2) * Fedora 20 x64 * ~50.000 tracks * Size of banshee.db 59 MB I disabled most of the plugins I once activated, but this doesn't help. I performed ANALYZE and VACUUM on the sqlite db and I dumped the complete database and reimported it, not changes. I removed almost all smart playlists, as they seem to slow Banshee down, but it has no effect. I created a debug log from today, without any load on my system. During start up, one core (of four) was 100% in use. I noticed three SQL statements which took a lot of time (> 11 seconds). Here is one example: [4 Warn 11:08:10.796] Executed in 112252ms DELETE FROM CoreCache WHERE ModelID = 4605; INSERT INTO CoreCache (ModelID, ItemID) SELECT 4605, CoreTracks.TrackID FROM (SELECT MIN(CoreTracks.TrackID) AS TrackID, CoreTracks.Year FROM CoreTracks GROUP BY CoreTracks.Year) AS CoreTracks WHERE CoreTracks.Year IN (SELECT CoreTracks.Year FROM CoreTracks, CoreCache WHERE CoreCache.ModelID = 39 AND CoreCache.ItemID = CoreTracks.TrackID ) ORDER BY Year At 11:10, Banshee was finally usable, so the startup took 4 minutes. I attached the log file so you can look into it. I don't use "Write metadata into files", but I use sync to files/folders and sort albums per Year, not per title. This might be cause for the slow statements, but I don't think it's the only problem in the startup. If anybody has some more ideas to try, just ask, I would be glad to fix this problem.
I want to confirm this bug report. The same thing happens to me (since I upgraded to Ubuntu 14.10, maybe). Startup of banshee takes a long time, although for me it's about 30 seconds, and every time a new track starts, there is a 5~10 seconds lock up, although the music plays fine. Running banshee --debug, I see some SQL queries that take as long as 13 seconds to complete, all involving deleting something from CoreCache. I disabled most of my extensions and the 5~10 second freeze between songs doesn't happen anymore, so I'm not sure if the root of those were also SQLite or not.
Actually scratch that last paragraph. It did happen again and it's always the slow SQL queries. One example when changing file: [1 Debug 15:30:13.537] OnEventChanged called with StartOfStream. Replacing current_track with pending_track: "XXXXXXXX" [4 Warn 15:30:17.402] Executed in 3227ms DELETE FROM CoreCache WHERE ModelID = 154; INSERT INTO CoreCache (ModelID, ItemID) SELECT 154, CoreArtists.ArtistID FROM CoreArtists WHERE CoreArtists.ArtistID IN (SELECT CoreAlbums.ArtistID FROM CoreAlbums, CoreTracks, CoreCache WHERE CoreCache.ModelID = 53 AND CoreTracks.AlbumID = CoreAlbums.AlbumID AND EXISTS (SELECT 1 FROM CoreArtists WHERE ArtistID = CoreAlbums.ArtistID) AND CoreCache.ItemID = CoreTracks.TrackID ) ORDER BY NameSortKey [4 Warn 15:30:25.418] Executed in 8010ms DELETE FROM CoreCache WHERE ModelID = 47; INSERT INTO CoreCache (ModelID, ItemID) SELECT 47, CoreArtists.ArtistID FROM CoreArtists WHERE CoreArtists.ArtistID IN (SELECT CoreTracks.ArtistID FROM CoreTracks, CoreCache WHERE CoreCache.ModelID = 53 AND CoreCache.ItemID = CoreTracks.TrackID ) ORDER BY NameSortKey [29 Debug 15:30:25.480] Starting - Saving Metadata to File [30 Debug 15:30:25.487] Finished - Saving Metadata to File
@Shahbaz: Thanks for the confirmation, especially that this occurs on Ubuntu, too. With Fedora it's sometimes problematic, as some libs are not updated that frequently.
I switched off the sorting by album year per artist, but Banshee still freezes on startup and change between tracks. One slow SQL is still the CoreCache thing, as you can see here: [4 Warn 19:28:52.878] Executed in 114231ms DELETE FROM CoreCache WHERE ModelID = 4605; INSERT INTO CoreCache (ModelID, ItemID) SELECT 4605, CoreTracks.TrackID FROM (SELECT MIN(CoreTracks.TrackID) AS TrackID, CoreTracks.Year FROM CoreTracks GROUP BY CoreTracks.Year) AS CoreTracks WHERE CoreTracks.Year IN (SELECT CoreTracks.Year FROM CoreTracks, CoreCache WHERE CoreCache.ModelID = 39 AND CoreCache.ItemID = CoreTracks.TrackID ) ORDER BY Year Unfortunately, I cannot check against git master, as Fedora does not provide the correct libgtksharp libraries at the moment (2.9 < 3.0). In the meantime, Banshee is unusable for me.
I just discovered the Fedora bug about SQLite: https://bugzilla.redhat.com/show_bug.cgi?id=1161844 It seems that this is the same statement which makes problems. Unfortunately, updating to SQLITE 3.8.7.2 2014-11-18 20:57:56 2ab564bf9655b7c7b97ab85cafc8a48329b27f9 did not help at all. There's also https://bugzilla.gnome.org/show_bug.cgi?id=740879 but I don't know if they are duplicates...
It is indeed a duplicate of #740879 I tested it with banshee-2.6.2-8.fc21 on testing, see https://bugzilla.redhat.com/show_bug.cgi?id=1161844 for more details. *** This bug has been marked as a duplicate of bug 740879 ***