Search on large collections slow.

[milohr]

Search on large collections slow.

[milohr]

@evertvorster okay, right now i implemented a qtimer, so it will wait 500 milliseconds after the search query has been entered. :)

[evertvorster]

I'll check in a bit when the repos have synched.
From your description, it appears that babe will now wait for 500ms for new input before starting the search. Its cool, but what if I am a slow typist? Would new input interrupt the previous search?

Thanks for looking into this.
How can I report issues on the KDE phabricator, it must be a pain for you to keep on opening github just to talk to me. Otherwise you can mail me directly at evorster at the usual gmail server.

-Evert-

[milohr]

@evertvorster right now i'm listening to the signal textEdited, so yes, if you are a slow typist the search would run and when you edited then i would wait another 500ms and then run the search again.
the solution i see here is to listen to the returnPressed instead, so the search would only run when the return key is pressed.

[evertvorster]

Hi there, Camilo. I checked the 500ms waiting fix that you put in, and it seems to work fine. However, if I just type 1 character babe appears to hang for a couple of minutes while loading the results. Thinking about this issue a little more... I suspect that you want to do the search automatically, and it does look cool to see the list of songs decrease as the search term gets more specific. Having to press enter would detract from the polish of the program, and so it is not the ideal solution. So, maybe there is another way. Can you, when you put in the search parameters, tell the program to only return say, the first 500 or 1000 songs? This should load pretty quickly, and then you can have babe check to see if there was another keystroke in the meantime. If there is not, then fetch the next block of results, check for keystroke, fetch the next and so on until done. Doing a partial fetch would also allow you to have something to display almost immediately, and the user can start scrolling. This way babe appears really fast, even on large collections. Kind regards, -Evert-

…

On 8 October 2017 at 00:45, Camilo Higuita ***@***.***> wrote: @evertvorster <https://github.com/evertvorster> right now i'm listening to the signal textEdited, so yes, if you are a slow typist the search would run and when you edited then i would wait another 500ms and then run the search again. the solution i see here is to listen to the returnPressed instead, so the search would only run when the return key is pressed. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#51 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALfL1fZEz7wMolbJ4_E7vsKDD05g-H9sks5sp_8ngaJpZM4PxWsX> .

-- Evert Vorster Isometrix Acquistion Superchief

[milohr]

@evertvorster that sounds goo. i will try it :)

[geneticdrift]

@milohr, there's a utility to create a large fake music collection. It might be useful for testing issues like this one during development.
It uses CDDB to randomly tag music files it duplicates from a template.