Version: 1.95 (2.0 beta 1) (using KDE KDE 3.1.4) OS: Linux I get strange slowdown while typing to the search field in Collection List. Example, I want to see The Gathering's album 'Mandylion' so I start to type to the search field: 'mand' at this point I have the following songs in the view as they all have the string 'mand' in them. file:/home/work/mp3/Blackmore's Night/Ghost Of A Rose (Limited Version)/01 Way To Mandalay.mp3 file:/home/work/mp3/Blackmore's Night/Ghost Of A Rose (Limited Version)/17 Way To Mandalay (Radio Edit).mp3 file:/home/work/mp3/Electric Six - Fire/01-electric_six-dance_commander-esc.mp3 file:/home/work/mp3/Hector/Lap/05 - mandoliinimies.mp3 file:/home/work/mp3/The Gathering/Mandylion/01 - Strange Machines.mp3 file:/home/work/mp3/The Gathering/Mandylion/02 - Eleanor.mp3 file:/home/work/mp3/The Gathering/Mandylion/03 - In motion %231.mp3 file:/home/work/mp3/The Gathering/Mandylion/04 - Leaves.mp3 file:/home/work/mp3/The Gathering/Mandylion/05 - Fear of the Sea.mp3 file:/home/work/mp3/The Gathering/Mandylion/06 - Mandylion.mp3 file:/home/work/mp3/The Gathering/Mandylion/07 - Sand and Mercury.mp3 file:/home/work/mp3/The Gathering/Mandylion/08 - In motion %232.mp3 At this point Juk is quite speedy, when I select one of those songs the yellow cursor-line follows immediately and if I move the window around it is repainted quickly. Ok, I add the letter 'y' to the search string so it becomes 'mandy' list is updated to represent those songs that have the 'mandy' in them, namely the Mandylion record. Now Juk slows down considerably, repainting the window takes about 2 seconds and when I select one of the songs with the mouse it takes about 2 seconds for the yellow cursor-line to follow. I can also reproduce this problem with other search strings, for example typing 'metalli' does not slow down but when I add the 'c' to the end it slows down. I do hope this explanation makes sense. .)
Seems that the bug database did not save my platform's information: I'm running Debian unstable with Juk from debian package also. I also forgot to mention that I have ~4400 songs in my Collection list and browsing it (without search) it very fast.
Ok, and you're sure that you're running KDE 3.1.4 not, i.e. 3.1.3? There was a bug in one of KDE's libraries that I fixed in painting lists that I think wasn't in KDE 3.1.3, but made it into 3.1.4. Oh, and also what's the CPU on the machine?
Right, It seems there is an error in kde packages in debian. Every About dialog tells me that I'm running kde 3.1.4 but packages have mixed version numbers, for example: kdebase 3.1.3-1 kdelibs-bin 3.1.4-2 So no, I'm not sure what version I have. :) CPU is 1.2G athlon thunderbird with 1G memory.
Ok, I'll give a description of what the bug was in pre-3.1.4 and we'll see if it fits. It's a little bit strange, but I'll try to explain. :-) Searching gets especially slow when items are far apart. When you search JuK is just hiding the items that don't match -- they're actually still in the list. Well, there are some calculations that happen when painting to figure out what the next item is. Before some of my fixes to the libraries these were very slow; they're much faster now. So, this problem became the most evident when there was a lot of space between the matched items. i.e. if when the search is empty these items might normally be separated by 100 or 1000 items or something. Can you try various sorting combinations to see if this fits? (Or if it even makes sense?)
It doesn't seem to be this problem. I tried it by creating some mp3's with the same title name but albums 'aaa' and 'zzzz'. Then I searched for those by title. I also compiled the 3.2beta1 kde from sources and it seems the slowdown I initially described is still there but it is not as radical. Juk version seems to be 2.0beta2.
When you add this last key that you mention does it significantly reduce the number of matches? What column are you sorting by? (I know these are weird questions, but they're related to some of the kdelibs internals and *might* give me a clue as to what's going on.)
As I reported in my initial raport, there are 12 songs before I add the last key. After that there are 8 songs. Sorting is by Artist.
I'm glad to report that this sluggishness is gone in Kde 3.2beta2 version of Juk. Also JUK's search seems to be much quicker overall. Great work.
Closing this bug as Juk included in Kde 3.2Beta2 releases does not have this bug anymore.
Ah, great. This makes me feel better about not being able to find a way to reproduce it. :-) (I suspect it was something that I fixed by accident along the way in the process of working on other optimizations.)