GNOME Bugzilla – Bug 372393
Random smart playlist not functioning correctly
Last modified: 2006-11-12 05:15:43 UTC
Please describe the problem: On adding a random smart playlist, the application seems to be looping the random search, and seems to add an infinite number of items. This is actually on version 0.11.1. Steps to reproduce: 1. Create a new smart playlist 2. Untick the "Match" criteria, so it's not macthing on anything 3. Tick the "limit" criteria, and change the dropdown to "random". Give it a name and click OK. Actual results: As expected, I get a random playlist of, n items. However, the items counter in the status bar keeps climbing by n, ad infinitum, leading to serious system slowdown. Expected results: A random playlist of n items (similiar to Amarok's "50 random items" playlist.) Does this happen every time? Yes. Other information:
I am using 0.11.1 and am not able to recreate this problem. I create the playlist, untick the "match", tick the "limit" and change to "random". The playlist of n items is created as expected and the items counter stays the same.
If it helps, I'm running the 0.11.1 from the Ubuntu "Universe" repositories. The problem on this machine is repeatable, so is there some other information I can provide to assist, e.g. library versions?
Shahid, two questions: 1. What exactly is the definition of the smart playlist that has the problem, including all settings on the smart playlist editor dialog. 2. If you switch to a different playlist and then back, do all the duplicate items still appear, or do they then disappear? Same test, different method: does the number in parenthesis next to the playlist name in the sources sidebar actually keep incrementing?
Gabriel: 1: - Playlist Name: "All:" (but this seems to have no impact) - "Match" unticked (so all "album is" options are greyed out - Limit ticked, set to 25 songs selected by Random - Predefined section is not expanded 2: - Switching and then returning gives the same problem with a growing playlist - The number in brackets next to the playlist name remains at 25 (it's just the item count in the status bar that increments.) I hope that helps, let me know if you need any more info.
So this is basically a duplicate of bug #344833 (tracks don't disappear when removed from a smart playlist - which also means they appear duplicated if the playlist is refreshed). I don't want to close this bug until I understand why your smart playlist is refreshing itself, though. More questions: 1. When does the count increase (eg when playing a song, etc) and how frequently (every second, every minute, ?). 2. Do you have any recent version of banshee built by hand so we can do some other tests? 3. Do you have any other smart playlists? If so, if you run banshee from the command line with banshee --debug, does it emit a log message (viewable on the command line or from Debug -> View logged events) saying you have a time-based playlist? If you remove all smart playlists but the one in question, does it still do it?
Created attachment 76374 [details] console output
Created attachment 76375 [details] Screenshot with unrefreshed playlist, and item count going crazy
Created attachment 76376 [details] Second screenshot with playlist definition
1: The count increase happens in two and five second gaps. The main screen also fails to show the larger playlist properly. 2: I don't have a more recent version than the version in the Ubunty Edgy repositories. 3: I've added an attachment which is the output of: banshee --debug >output 2>debug.txt Additional: I've added a couple of screenshots which should illustrate.
Ok, your output is pretty much worthless - just a ton of metadata jobs running. See if the problem continues with all other plugins disabled - my guess is that the metadata plugin is updating tracks and therefore triggering an update of the random smart playlist. Closing this as a duplicate of the appropriate bug. If you are having issues with this impacting your CPU, that is solved by the smart playlist rate limiting which should be in the next release. *** This bug has been marked as a duplicate of 344833 ***