Bug#591298: Bug #591298: Banshee regression hopefully fixed in 3.7.2-1
Hi Ondřej, On 27/08/10 08:31, Ondřej Surý wrote: > can you try 3.7.2-1? I tried changing Ian's test case to use BY > RANDOM(); and it works fine for me. No improvement with 3.7.2-1, sorry. Here's the sluggish query, from Banshee's --debug-sql output: [1 Debug 09:30:09.750] Querying model for track to play in album:Next mode [1 Warn 09:30:09.753] HyenaSqliteConnection command issued from the main thread [2 Debug 09:30:31.893] Executed in 22140ms SELECT CoreAlbums.AlbumID, CoreAlbums.Title, MAX(CoreTracks.LastPlayedStamp) as LastPlayed, MAX(CoreTracks.LastSkippedStamp) as LastSkipped FROM CoreTracks, CoreAlbums, CoreCache WHERE CoreCache.ItemId = CoreTracks.TrackID AND CoreCache.ModelID = 43 AND CoreTracks.AlbumID = CoreAlbums.AlbumID AND CoreTracks.LastStreamError = 0 AND CoreTracks.PrimarySourceID = 1 GROUP BY CoreTracks.AlbumID HAVING (LastPlayed < 1282901369 OR LastPlayed IS NULL) AND (LastSkipped < 1282901369 OR LastSkipped IS NULL) ORDER BY RANDOM() LIMIT 1 CoreCache is a temporary, in-memory table. From the debug log I've recreated the statements used to create and fill it, and have two other files containing a single query each: one exactly as above, and another with all references to CoreCache removed. With the CoreCache parts of the query removed, it's very snappy: % time sqlite3 banshee.db.copy < banshee-init-core-cache.sql < banshee-next-shuffle-by-album-no-core-cache.sql 4478|Heartland|1282844295|1277228957 sqlite3 banshee.db.copy < banshee-init-core-cache.sql < 0.22s user 0.04s system 97% cpu 0.267 total But in its original form, it's reliably a hundred times slower, taking over 22s: % time sqlite3 banshee.db.copy < banshee-init-core-cache.sql < banshee-next-shuffle-by-album.sql 1063|Stars On The Wall|1282654498|1272661309 sqlite3 banshee.db.copy < banshee-init-core-cache.sql < 22.28s user 0.07s system 99% cpu 22.377 total It's equally slow if I make CoreCache a regular table. I've checked Banshee's Git history briefly, and can't find any changes relating to CoreCache that could have caused this. I wondered if some indexes have been binned or something. But, if I downgrade to libsqlite3-0 3.6.23.1-4 the slower query is miraculously fast again: % time sqlite3 banshee.db.copy < banshee-init-core-cache.sql < banshee-next-shuffle-by-album.sql 550|Happy Songs for Happy People|1280848000|1280848242 sqlite3 banshee.db.copy < banshee-init-core-cache.sql < 0.27s user 0.03s system 99% cpu 0.302 total I've uploaded my Banshee database, plus the three SQL scripts used, to http://willthompson.co.uk/misc/banshee-sqlite-bug-591298 in the hope that they'll be useful. Sorry for not providing sample data sooner! Regards, -- Will -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#591298: Banshee becomes extremely slow after sqlite3 3.6.23.1-4 => 3.7.0-1 upgrade
On 21/08/10 08:52, Laszlo Boszormenyi wrote: I've a test case for this bug, will contact upstream. It's about selecting a random song. Ah, yes. Iain, your test case is indeed fixed. Clicking Next is snappy enough with shuffle off, or shuffle by song, but shuffle by anything else is incredibly slow. -- Will -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#591298: Banshee becomes extremely slow after sqlite3 3.6.23.1-4 => 3.7.0-1 upgrade
Package: sqlite3 Version: 3.7.0.1-1 Severity: normal Hi, Unfortunately, this problem seems to be unfixed by 3.7.0-1.1 or by 3.7.0.1-1. With either version, Banshee freezes for several seconds whenever I hit Next, claiming that it is “Querying model for track to play in album:Next mode”. Downgrading libsqlite3-0 to 3.6.23.1-4 avoids the problem. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages sqlite3 depends on: ii libc6 2.11.2-2 Embedded GNU C Library: Shared lib ii libreadline6 6.1-3 GNU readline and history libraries ii libsqlite3-0 3.7.0-1.1 SQLite 3 shared library sqlite3 recommends no packages. Versions of packages sqlite3 suggests: pn sqlite3-doc(no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#587132: bustle: FTBFS: Could not find module `Graphics.UI.Gtk.Pango.Font':
On 30/06/10 10:23, Chris Lamb wrote: I think this tarball is missing the Bustle/ directory.. :) Blah. I wish cabal had a distcheck-alike. New tarball uploaded. -- Will -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#587132: bustle: FTBFS: Could not find module `Graphics.UI.Gtk.Pango.Font':
On 28/06/10 11:50, Chris Lamb wrote: Fancy refreshing the package a little for GHC 6.12 and doing another release? :) Done: http://www.willthompson.co.uk/bustle/releases/bustle-0.2.2.tar.gz and http://www.willthompson.co.uk/bustle/releases/bustle-0.2.2.tar.gz.asc -- Will -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#587132: bustle: FTBFS: Could not find module `Graphics.UI.Gtk.Pango.Font':
Hi, On 28/06/10 11:50, Chris Lamb wrote: Looks like libghc6-pango-dev doesn't provide Graphics.UI.Gtk.Pango.Font, it's renamed to Graphics.Rendering.Pango.Layout. Sigh. Well I guess that's more correct, but it's a bit of a pain from a backwards-compatibility perspective. I can probably just change it to the new name, and not worry about adding ifdefs or whatever unless it trips someone up. However, simply adjusting the import lines (and adding pango to cabal Build-Depends) doesn't work: * Bustle.hs:237:14: Ambiguous occurrence `eventKeyName' It could refer to either `Graphics.UI.Gtk.eventKeyName', imported from Graphics.UI.Gtk at Bustle.hs:45:0-21 or `Graphics.UI.Gtk.Gdk.Events.eventKeyName', imported from Graphics.UI.Gtk.Gdk.Events at Bustle.hs:47:0-32 Huh. * Also, I get a ton of deprecation warnings and suchlike. Yep, I saw a tonne of these too the other day, but didn't have a chance to look into it. Fancy refreshing the package a little for GHC 6.12 and doing another release? :) I do. I have a bugfix I want to release as well. :) I'll try to do that this week. Thanks for neatly itemising the problems! -- Will -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#477702: libghc6-configfile-dev: fails to install correctly; needs rebuild against new MissingH
Package: libghc6-configfile-dev Version: 1.0.4.1 Severity: grave Justification: renders package unusable Unpacking libghc6-configfile-dev (from .../libghc6-configfile-dev_1.0.4.1_i386.deb) ... Setting up libghc6-configfile-dev (1.0.4.1) ... Reading package info from "/usr/lib/haskell-packages/ghc6/lib/ConfigFile-1.0.4/installed-pkg-config" ... done. ghc-pkg: dependency MissingH-1.0.0 doesn't exist (use --force to override) dpkg: error processing libghc6-configfile-dev (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: libghc6-configfile-dev E: Sub-process /usr/bin/dpkg returned an error code (1) A package failed to install. Trying to recover: Setting up libghc6-configfile-dev (1.0.4.1) ... Reading package info from "/usr/lib/haskell-packages/ghc6/lib/ConfigFile-1.0.4/installed-pkg-config" ... done. ghc-pkg: dependency MissingH-1.0.0 doesn't exist (use --force to override) dpkg: error processing libghc6-configfile-dev (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: libghc6-configfile-dev I'm not really up on what's meant to happen next, but dpkg believes the package to be installed, and then can't remove it because pre-remove fails. Cue the judicious application of "exit 0" to get rid of the thing. This seems to be a repeat of #429486; can the dependency on MissingH be set more strictly? -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libghc6-configfile-dev depends on: ii ghc6 6.8.2-4GHC - the Glasgow Haskell Compilat ii libghc6-missingh-dev 1.0.1.0Library of utility functions for H ii libghc6-mtl-dev 1.1.0.0-2 Haskell monad transformer library libghc6-configfile-dev recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
