Search on large collections slow.

[evertvorster]

Hi there.

Firstly, thanks for making this super software, it's really nice. I have a large music collection with approximately 90000 songs.

When searching for anything in that collection, babe is extremely slow on the first keystrokes, and as the search term gets more specific it speeds up. I am guessing this is because a single character has a really large number of hits, and it takes a minute or two to load the entire list, then only does it insert the next character in the search, and so on.

When I type the text I am looking for in a text editor and cut 'n paste it into the search field, the search is almost instantaneous. (Probably because of the much smaller number of hits)

So, in order to support larger music collections, babe either has to wait until no more text is entered before it starts searching, or monitor keyboard input and abort any current search and start searching with the next input string.

I am using Arch linux, so I can test any fixes quite quickly. Kind regards, -Evert-

[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 notifications@github.com 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 https://github.com/milohr/babe-qt/issues/51#issuecomment-334970730, 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.