GNOME Bugzilla – Bug 593817
Significant performance issues with "Shuffle by Score" in smart playlists
Last modified: 2009-09-02 02:52:28 UTC
When a smart playlist has criteria based on score, setting the shuffle mode to Shuffle by Score causes major performance issues when changing tracks. 1. Create a new smart playlist with score-based criteria. Mine is: Last Played more than 2 weeks ago Last Skipped more than 2 weeks ago Score at least 90 2. Turn shuffle on, set to Shuffle by Score 3. Try to skip through tracks. For me, both of my CPU cores max out for several seconds before Banshee changes tracks. I thought that this could be due to the fact that all songs had such a high score, so I changed the score criteria to "at least 30". This increased the number of items in the playlist from 1500 to 3800, and causes the processor to use 100% for >10 seconds.
I re-committed the dropped index that supposedly should fix the issue, see last comments in bug 581103. Do you use the git master? If you do, could you check if you have CoreSmartPlaylistEntriesIndex in your database, and if it's the only index on the CoreSmartPlaylistEntries table?
(In reply to comment #1) > I re-committed the dropped index that supposedly should fix the issue, see last > comments in bug 581103. Do you use the git master? If you do, could you check > if you have CoreSmartPlaylistEntriesIndex in your database, and if it's the > only index on the CoreSmartPlaylistEntries table? Yes, I use git master. No, I don't know if I've updated it recently enough to include that commit. No, I don't have any idea how to check if I have CoreSmartPlaylistEntriesIndex. :-) I'll gladly check if you give me some step-by-step instructions, and in the meantime, I can at least clone a more recent version from git to make sure I'm up to date.
In order to check if you have the index, please run the following command in a terminal : sqlite3 ~/.config/banshee-1/banshee.db ".schema CoreSmartPlaylistEntries" This will print out the structure of the CoreSmartPlaylistEntries table and any index on that table.
Thanks for the tip, Bertrand. Here's the output: ~$ sqlite3 ~/.config/banshee-1/banshee.db ".schema CoreSmartPlaylistEntries" CREATE TABLE CoreSmartPlaylistEntries ( EntryID INTEGER PRIMARY KEY, SmartPlaylistID INTEGER NOT NULL, TrackID INTEGER NOT NULL ); For what it's worth, I got a new copy of git master and I'm still having the performance issue. I also tried testing on my laptop, and I think it has the same issue. The number of songs in the database is a lot smaller, though, and the laptop is absolutely awful, so it's hard to tell if the poor performance is from banshee or the laptop.
So it looks like you don't have the necessary index. Try running this (in one line): sqlite3 ~/.config/banshee-1/banshee.db "CREATE INDEX IF NOT EXISTS CoreSmartPlaylistEntriesIndex ON CoreSmartPlaylistEntries(SmartPlaylistID, TrackID)" As for why this happened, did you apply any patches that change the database schema?
(In reply to comment #5) > So it looks like you don't have the necessary index. Try running this (in one > line): > > sqlite3 ~/.config/banshee-1/banshee.db "CREATE INDEX IF NOT EXISTS > CoreSmartPlaylistEntriesIndex ON CoreSmartPlaylistEntries(SmartPlaylistID, > TrackID)" Well, that definitely took care of it. Thanks! > As for why this happened, did you apply any patches that change the database > schema? 3 patches. I have no idea if they modify the database schema, but you should know, because they're all yours :) banshee-auto-dj-v13, banshee-listview-sorting, banshee-multiline-cell-text
It was the auto-dj patch then, it adds a new database migration, at one point the migration number was the same as the one that added the missing index. You should take extreme care when applying patches that add database migrations, the file to watch is src/Core/Banshee.Services/Banshee.Database/BansheeDbFormatMigrator.cs I'm closing the bug as a dupe of bug 581103. *** This bug has been marked as a duplicate of bug 581103 ***