I noticed that the search for music files immediately fires the search while typing the first few characters.
That might be nice for some use cases, but it has a negative side effect, at least on larger libraries: as soon as the search starts with some incomplete typed input string, it is busy with db query and to process the results. So any new characters typed in will only be executed as a new search with huge delay, as the running search with the incomplete input blocks the new search for some time.
That makes the search function kind of laggy.
Maybe adding an option ‘immediate search on/off’ can let the users decide what is more usable for them.
If I “copy” and Paste the text I am looking for it finds it straight away…thats great.
But if I am typing I only manage the first two or three letters before its off looking. comes back with a load of rubbish before I can enter the next two or three letters…rinse and repeat.
As it is the current search method is really very clunky indeed.
It is as if its trying to be fast, but in doing so drastically slowing itself down.
As my gran used to tell me " less haste more speed"
Had a delve today into what is going on…
Volumio3 search starts to search after 2 characters have been entered, with only 2 characters the results are endless and sluggish.
I was sure Volumio2 wasnt like this so loaded up an old copy of 2.917 and sure enough V2 waits for 3 characters to be inputted before searching and the results are so much more meaningfull and alot less sluggish.
So until this idea of “waiting for enter” to be considered or even implemented.
You can edit a file in Volumio3 so that it waits for 3 (or however many characters you want before searching) quite easily.
LMK if you want to know more