-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Search on large collections slow. #51
Comments
@evertvorster okay, right now i implemented a qtimer, so it will wait 500 milliseconds after the search query has been entered. :) |
I'll check in a bit when the repos have synched. Thanks for looking into this. -Evert- |
@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. |
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
|
@evertvorster that sounds goo. i will try it :) |
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-
The text was updated successfully, but these errors were encountered: