After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 740166 - Start freezes Banshee for several minutes
Start freezes Banshee for several minutes
Status: RESOLVED DUPLICATE of bug 740879
Product: banshee
Classification: Other
Component: User Interface
2.6.2
Other Linux
: Normal normal
: ---
Assigned To: Banshee Maintainers
Banshee Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-11-15 12:53 UTC by Philip Gillißen
Modified: 2014-12-19 09:43 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Banshee debug log during startup. (10.04 KB, text/x-log)
2014-11-15 12:53 UTC, Philip Gillißen
Details

Description Philip Gillißen 2014-11-15 12:53:41 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.
Comment 1 Shahbaz 2014-11-15 14:29:24 UTC
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.
Comment 2 Shahbaz 2014-11-15 14:32:54 UTC
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
Comment 3 Philip Gillißen 2014-11-15 14:49:48 UTC
@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.
Comment 4 Philip Gillißen 2014-11-25 18:30:50 UTC
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.
Comment 5 Philip Gillißen 2014-12-15 20:23:14 UTC
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...
Comment 6 Philip Gillißen 2014-12-19 09:43:23 UTC
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 ***