GNOME Bugzilla – Bug 661125
massive delays for each device playlist
Last modified: 2011-10-10 12:58:30 UTC
The changes made to fix bug #657479 are causing massive delays for each playlist present on a device. This can at least be observed with an iPod, but I assume it will be the case for other devices too. In my case I've got 3 smartplaylists, all 3 present in the local library and on the device. An example is a "Recently Added" smartplaylist with just one date added rule. The delays can be observed when connecting a device and when selecting one of the playlists on the device. The following warnings will be displayed when connecting a device (one warning for each playlist present): [4 Warn 21:46:53.349] Executed in 44359ms SELECT COUNT(*), SUM(CoreTracks.FileSize), SUM(CoreTracks.Duration) FROM CoreTracks CROSS JOIN CoreArtists,CoreAlbums, CorePlaylistEntries WHERE CoreArtists.ArtistID = CoreTracks.ArtistID AND CoreAlbums.AlbumID = CoreTracks.AlbumID AND CorePlaylistEntries.TrackID = CoreTracks.TrackID AND CorePlaylistEntries.PlaylistID = 2 [4 Warn 21:47:41.519] Executed in 47095ms SELECT COUNT(*), SUM(CoreTracks.FileSize), SUM(CoreTracks.Duration) FROM CoreTracks CROSS JOIN CoreArtists,CoreAlbums, CorePlaylistEntries WHERE CoreArtists.ArtistID = CoreTracks.ArtistID AND CoreAlbums.AlbumID = CoreTracks.AlbumID AND CorePlaylistEntries.TrackID = CoreTracks.TrackID AND CorePlaylistEntries.PlaylistID = 3 [4 Warn 21:49:26.581] Executed in 93071ms SELECT COUNT(*), SUM(CoreTracks.FileSize), SUM(CoreTracks.Duration) FROM CoreTracks CROSS JOIN CoreArtists,CoreAlbums, CorePlaylistEntries WHERE CoreArtists.ArtistID = CoreTracks.ArtistID AND CoreAlbums.AlbumID = CoreTracks.AlbumID AND CorePlaylistEntries.TrackID = CoreTracks.TrackID AND CorePlaylistEntries.PlaylistID = 4 This means that Banshee is completely frozen and unresponsive for a total of 184 seconds (3 minutes!). Things will get worse in terms of time to wait when you select one of the playlists on the device: [4 Warn 22:44:46.847] Executed in 91852ms SELECT COUNT(*), SUM(CoreTracks.FileSize), SUM(CoreTracks.Duration) FROM CoreTracks CROSS JOIN CoreArtists,CoreAlbums, CorePlaylistEntries WHERE CoreArtists.ArtistID = CoreTracks.ArtistID AND CoreAlbums.AlbumID = CoreTracks.AlbumID AND CorePlaylistEntries.TrackID = CoreTracks.TrackID AND CorePlaylistEntries.PlaylistID = 3 [4 Warn 22:46:19.681] Executed in 92833ms DELETE FROM CoreCache WHERE ModelID = 190; INSERT INTO CoreCache (ModelID, ItemID) SELECT 190, EntryID FROM CoreTracks CROSS JOIN CoreArtists,CoreAlbums, CorePlaylistEntries WHERE CoreArtists.ArtistID = CoreTracks.ArtistID AND CoreAlbums.AlbumID = CoreTracks.AlbumID AND CorePlaylistEntries.TrackID = CoreTracks.TrackID AND CorePlaylistEntries.PlaylistID = 3 ORDER BY CoreAlbums.ArtistNameSortKey ASC, CoreTracks.Year ASC, CoreAlbums.TitleSortKey ASC, CoreTracks.Disc ASC, CoreTracks.TrackNumber ASC [4 Warn 22:47:55.962] Executed in 96118ms SELECT COUNT(*), SUM(CoreTracks.FileSize), SUM(CoreTracks.Duration) FROM CoreTracks CROSS JOIN CoreArtists,CoreAlbums, CorePlaylistEntries WHERE CoreArtists.ArtistID = CoreTracks.ArtistID AND CoreAlbums.AlbumID = CoreTracks.AlbumID AND CorePlaylistEntries.TrackID = CoreTracks.TrackID AND CorePlaylistEntries.PlaylistID = 3 [4 Warn 22:49:35.740] Executed in 99777ms DELETE FROM CoreCache WHERE ModelID = 190; INSERT INTO CoreCache (ModelID, ItemID) SELECT 190, EntryID FROM CoreTracks CROSS JOIN CoreArtists,CoreAlbums, CorePlaylistEntries WHERE CoreArtists.ArtistID = CoreTracks.ArtistID AND CoreAlbums.AlbumID = CoreTracks.AlbumID AND CorePlaylistEntries.TrackID = CoreTracks.TrackID AND CorePlaylistEntries.PlaylistID = 3 ORDER BY CoreAlbums.ArtistNameSortKey ASC, CoreTracks.Year ASC, CoreAlbums.TitleSortKey ASC, CoreTracks.Disc ASC, CoreTracks.TrackNumber ASC Undoing the change for the bug mentioned above will restore normal functioning again.
Thanks for tracking this down Age. I'm really puzzled about how that change can cause that performance problem. I don't understand it at all. I hope I can debug it soon and/or someone help me figure out! PS: Do you have another device different than iPod? It would be nice to know if this affects any DAP device or only AppleDevices.
I was able to reproduce the issue with my Android phone (HTC Legend). For me it took some 250 tracks before the warnings of the long execution time start popping up. The more tracks you add, the longer the execution time will be. Also, when you delete a series of tracks, the warning will show up for each playlist for each track you delete. This is a different issue. It's a waste of resources to update each playlist for each track deleted. Instead the update should be triggered when deleting a complete selecting is finished.
Forget all I said about bug #657479, after some more extensive testing I got different results. *** This bug has been marked as a duplicate of bug 648592 ***
(In reply to comment #3) > Forget all I said about bug #657479, after some more extensive testing I got > different results. Renaming the bug then.