The database has the CoreSmartPlaylistEntriesPlaylistIndex index, but
not the other one.
The CoreConfiguration DatabaseVersion is 31, that's why I suspected
Nicholas was not running the 1.5.0 release.
He told (off-list) me that it was quite plausible :
> I was building from git/svn a few times a week between 1.4 and 1.5 so
> I don't know at what point I made a new config and at what point
> database migration happened for me, probably before 1.5 was officially
> released.
On Mon, 2009-06-29 at 17:11 -0500, Gabriel Burt wrote:
> Hi Bertrand,
>
> The commit in question deleted these two indexes:
>
> + Execute ("DROP INDEX IF EXISTS
> CoreSmartPlaylistEntriesPlaylistIndex");
> + Execute ("DROP INDEX IF EXISTS CoreSmartPlaylistEntriesIndex");
>
> Can you check that the CoreConfiguration DatabaseVersion is set to 32?
> And, can you check that the bad index(es) that you found in his db
> are named exactly that? There was one or more very similarly named
> indexes at some point, I think.
>
> On Thu, Jun 25, 2009 at 1:52 PM, Bertrand
> Lorentz<bertrand lorentz gmail com> wrote:
> > Nicholas,
> >
> > Thanks for sending me your database.
> >
> > Here's what I found :
> > I think you were hit by this bug :
> > http://bugzilla.gnome.org/show_bug.cgi?id=581103
> > The fix was to remove an index.
> >
> > As you had 2 smart playlist based on PlayCount, those were updated after
> > each track was played.
> > For example, with your db, a query for one of these smart playlists
> > takes 7 seconds before applying the fix, and only 16ms after applying
> > the fix.
> >
> > Now the strange part :
> > That fix was committed a few days before the 1.5.0 release and the index
> > should have been removed when your database was migrated, the first time
> > you ran the 1.5.0 version.
> >
> > Were you running the actual 1.5.0 version, released on the 1st of June ?
> > Maybe you had a slightly older version, compiled from git ?
> >
> > --
> > Bertrand
> >
> >
> > On Tue, 2009-06-23 at 22:40 +0200, Bertrand Lorentz wrote:
> >> Nicholas, do you still have the banshee.db file that was causing the
> >> problem ?
> >> If you don't mind, I'd like to take a look at it to try to see what went
> >> wrong. PLease send it directly to my e-mail address.
> >>
> >> Fabian, could you file a bug about your performance issue ?
> >> See http://banshee-project.org/contribute/file-bugs/
> >> Please also do the following to provide more info :
> >> 1/ Run banshee with this command :
> >> banshee --debug-sql > banshee-sql.log
> >> 2/ Do the various operations
> >> 3/ Attach the banshee-sql.log file to the bug
> >>
> >> Depending on the content of the file, I might also want to have a look
> >> at your banshee.db file.
> >>
> >>
> >> On Tue, 2009-06-23 at 12:14 -0300, Nicholas Doyle wrote:
> >> > I had this problem when updating from 1.4 to 1.5. I think some DB
> >> > indexes get lost or something. Performance went right back up with a new
> >> > ~/.config/banshee-1 directory... at the expense, of course, of losing
> >> > all my configuration.
> >> >
> >> >
> >> > On Mon, 2009-06-22 at 14:07 -0400, Fabian Rodriguez wrote:
> >> > > Hi all
> >> > >
> >> > > After a while playing with a small collection of CDs, importing audio,
> >> > > etc., I decided to import all my audio collection into it and organize it.
> >> > >
> >> > > Before filing bugs or investingating more, I wanted to aks if it's
> >> > > normal Banshee (1.5, from Ubuntu PPA) brings my CPU usage to 100% for
> >> > > the slightest operations, such as changing tag information, searching,
> >> > > etc. I've disabled Internet operations thinking the delays were there
> >> > > but after looking at CPU closely everytime I modify or search anything
> >> > > in my collection, I see the same behavior. Even skipping to next song
> >> > > takes a few seconds.
> >> > >
> >> > > I am asking Banshee to handle 14K songs (yes, 14 thousand). I handle
> >> > > bigger & more complex databases (address books and email) on a daily
> >> > > basis without any issues, what could be the bottleneck ? Or what is the
> >> > > threshold at which Banshee becomes such a hog in resources ?
> >> > >
> >> > > Thanks for any hints.
> >
> >
> >
> > _______________________________________________
> > banshee-list mailing list
> > banshee-list gnome org
> > http://mail.gnome.org/mailman/listinfo/banshee-list
> >
> >
> _______________________________________________
> banshee-list mailing list
> banshee-list gnome org
> http://mail.gnome.org/mailman/listinfo/banshee-list
--
Bertrand Lorentz <bertrand lorentz gmail com>
> http://flickr.com/photos/bl8/ <
Attachment:
signature.asc
Description: This is a digitally signed message part