GNOME Bugzilla – Bug 625783
Banshee becomes extremely slow after sqlite3 3.6.23.1 => 3.7.0 upgrade
Last modified: 2010-08-09 13:35:17 UTC
Originally reported at: https://bugs.launchpad.net/bugs/612370 affects ubuntu/banshee status confirmed affects ubuntu/sqlite3 status new subscribe tsmithe [This is a transplanted Debian bug, that also applies to Ubuntu] [Not sure whether this is a Banshee or SQLite bug.] After I upgraded sqlite3 (and its libs) from 3.6.23.1-4 to 3.7.0-1, Banshee becomes extremely slow. For instance, it hangs for a minute right after startup, and also for many seconds in between songs. Fwiw, strace(1)'ing the process shows nothing special. Downgrading SQLite and its libs to the old version fixes the problem. Note that the problem occurs with both Banshee 1.6.x and 1.7.x. Attached is a log of banshee --debug --debug-sql which shows the SQL queries performed, and the time taken for each one.
Created attachment 166942 [details] banshee --debug --debug-sql
Created attachment 166944 [details] Log running 1.7.3 with 3.7.0 I've made a comparative log with the new and old sqlite versions. Here's an example of a query which is extremely slow with the new sqlite: [2 Debug 23:32:13.252] Executed in 65507ms DELETE FROM CoreCache WHERE ModelID = 1; INSERT INTO CoreCache (ModelID, ItemID) SELECT 1, CoreArtists.ArtistID FROM CoreArtists WHERE CoreArtists.ArtistID IN (SELECT CoreTracks.ArtistID FROM CoreTracks, CoreCache WHERE CoreCache.ModelID = 39 AND CoreCache.ItemID = CoreTracks.TrackID ) ORDER BY NameSortKey I strongly suspect that this is a problem with sqlite itself though, so will investigate with upstream tomorrow.
Created attachment 166945 [details] Log running 1.7.3 with sqlite 3.6.23.1 This is unremarkable: just demonstrating that reverting to the previous version restores performance with the same database.
Confirming. Looks like a regression in sqlite 3.7 and it affects not only query performance but accuracy too - for example the play queue logic is completely broken when running banshee with sqlite 3.7, but it works fine with 3.6
*** Bug 625423 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > for example the play queue logic is completely broken Confirming, seeing that here as well. The play queue selects groups of 5 songs from the same album when it is instructed to pick random tracks instead. Additionally, I also see weird "current song pointer" behaviour with the new SQLite version. Ctrl-J in the main window focuses the wrong row. Not completely sure whether that is related though, but it might be the same problem as Alexander mentioned in comment#4. I'm bumping this report to "critical" since it makes the application totally unusable. I understand this might be a SQLite problem, but that doesn't matter for the bad use experience. Anyway, great to see so much progress on this in such a short time frame. Thanks!
(In reply to comment #2) > I strongly suspect that this is a problem with sqlite itself though, so will > investigate with upstream tomorrow. Hi, do you have a pointer to an upstream bug for this? I couldn't find one at http://www.sqlite.org/cvstrac/
No. As you will have seen, I reassigned your Debian bug to sqlite3 and made it RC there in the hope that the maintainer helps me triage. I'll file one there shortly too (or you can).
Fyi, progress on the Debian bug can be followed here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591298 This is also where this bug originated (not Launchpad, as stated in the initial bug description).
Same problem here with Archlinux.
Mailed upstream, waiting for moderation now.
Here's the response: http://permalink.gmane.org/gmane.comp.db.sqlite.general/58588 Seems confident that it will be fixed in 3.7.1.
Then I guess the correct change for banshee is reject the configure or execution phase if it detects the offending version of sqlite with a descriptive error.
*** Bug 625617 has been marked as a duplicate of this bug. ***
(In reply to comment #12) > Here's the response: > > http://permalink.gmane.org/gmane.comp.db.sqlite.general/58588 > > Seems confident that it will be fixed in 3.7.1. Thanks Iain! Is there an upstream ticket open for this issue?
(In reply to comment #16) > (In reply to comment #12) > > Here's the response: > > > > http://permalink.gmane.org/gmane.comp.db.sqlite.general/58588 > > > > Seems confident that it will be fixed in 3.7.1. > > Thanks Iain! Is there an upstream ticket open for this issue? Yep. Here it is: http://www.sqlite.org/src/info/13f033c865 …and even better, it's fixed! I don't think there's anything Banshee should do about this now. The autofoo isn't supposed to be for tracking any bugs that dependencies introduce, and I'm confident that sqlite will issue a new release with this fix in short order. In the meantime, distros can cherrypick the fix if they wish. I suggest RESOLVED NOTGNOME.
(In reply to comment #17) > Yep. Here it is: > > http://www.sqlite.org/src/info/13f033c865 > > …and even better, it's fixed! > > I don't think there's anything Banshee should do about this now. The autofoo > isn't supposed to be for tracking any bugs that dependencies introduce, and I'm > confident that sqlite will issue a new release with this fix in short order. In > the meantime, distros can cherrypick the fix if they wish. > > I suggest RESOLVED NOTGNOME. Amen.
Just to confirm, upgrading sqlite3 to the recently released version 3.7.0.1 completely fixes the issue.
No, ctrl+j still broken, though Banshee doesn't run slowly any longer when jumps to next song after the Sqlite3 updation to 3.7.0.1.
On Archlinux, Banshee 1.6.1 is still running slowly with sqlite3 3.7.0.1
3.7.0.1 doesn't fix the problem. See the bug link I posted above for the commits which do, and ask your distribution to backport them.
*** Bug 626432 has been marked as a duplicate of this bug. ***
*** Bug 626433 has been marked as a duplicate of this bug. ***