Slow search with default skin

[mherger]

The update seems to have fixed the full search and the quick search for me although the quick search needs three letters before it starts compared to two in Material skin but that is probably intentional.

Yes, that’s a deliberate choice to not overload the server. As you can imagine a search for „I“ could return a massive results list.

[slartibartfast]

Oh, are you "measuring" the time taken once you hit Enter on that input field? That would be the same search. But if you just type, you should get a "live search" (only works if you have a player connected). That live search is almost instant with a 100k tracks library.

The update seems to have fixed the full search and the quick search for me although the quick search needs three letters before it starts compared to two in Material skin but that is probably intentional.

[kidstypike]

8.4 should get an update in a bit. I was missing a "LEFT" in a JOIN (for those familiar with SQL). Fixing this brought one query down from 3s to 0.05s .

Update seems to have fixed the search problem for me.

Thank you.

[slartibartfast]

Oh, are you "measuring" the time taken once you hit Enter on that input field? That would be the same search. But if you just type, you should get a "live search" (only works if you have a player connected). That live search is almost instant with a 100k tracks library.

If I just type in the live search box then it is faster but still slower than Material skin. It is flaky though. If I type "Bl" it doesn't start searching. If I type Bla" it searches and I get results sometimes quickly and other times after 10 seconds or more. If I then add "c" to search for "Blac" I see "loading" forever.
Material skin starts searching at "Bl" and updates the search results instantly as more letters are added which must be how the live search is meant to work.

[mherger]

If the quick search is accessed by the search icon in the "Menu" line at the top of the page then that is just as slow as the search from the menu item for me

Oh, are you "measuring" the time taken once you hit Enter on that input field? That would be the same search. But if you just type, you should get a "live search" (only works if you have a player connected). That live search is almost instant with a 100k tracks library.

[mherger]

8.4 should get an update in a bit. I was missing a "LEFT" in a JOIN (for those familiar with SQL). Fixing this brought one query down from 3s to 0.05s .

If the quick search is accessed by the search icon in the "Menu" line at the top of the page then that is just as slow as the search from the menu item for me

Definitely not what I'm seeing. Can you enable logging for database.sql, run a search, then see which request was taking the longest?

[slartibartfast]

Can you confirm this is with the search from the Search menu item, and NOT with the "quick" search at the top of the menu panel?

FWIW: I see much slower responses from that menu item in Default, too. And I see the same in 8.3. The big difference here is that the quick search at the top as well as Material use the "search" CLI command, whereas the main menu item uses the old page rendering code.

If the quick search is accessed by the search icon in the "Menu" line at the top of the page then that is just as slow as the search from the menu item for me

[mherger]

Same problem here.

Full text search for "Black" took 42 seconds. (practically instant with material). Freezes changing to next track.

Can you confirm this is with the search from the Search menu item, and NOT with the "quick" search at the top of the menu panel?

FWIW: I see much slower responses from that menu item in Default, too. And I see the same in 8.3. The big difference here is that the quick search at the top as well as Material use the "search" CLI command, whereas the main menu item uses the old page rendering code.

[slartibartfast]

Just for information, I do NOT have a slow search problem with LMS default skin.
I use the latest LMS 8.3.1 version running on Linux Mint 20.3 (64bit) , installed on a server with Intel ATOM dual core CPU. Full details below.

Logitech Media Server Version: 8.3.1 - 1674060640 @ Wed 18 Jan 2023 06:28:30 PM CET
Hostname: ATOM
IP: 192.168.178.11
HTTP Port: 9000
OS: Debian - EN - utf8
Platform: x86_64-linux
Perl Version: 5.30.0 - x86_64-linux-gnu-thread-multi
Audio::Scan: 1.02
IO::Socket::SSL: 2.067
Database Version: DBD::SQLite 1.58 (sqlite 3.22.0)

Mine is latest 8.4 nightly

[CJS]

Just for information, I do NOT have a slow search problem with LMS default skin.
I use the latest LMS 8.3.1 version running on Linux Mint 20.3 (64bit) , installed on a server with Intel ATOM dual core CPU. Full details below.

Logitech Media Server Version: 8.3.1 - 1674060640 @ Wed 18 Jan 2023 06:28:30 PM CET
Hostname: ATOM
IP: 192.168.178.11
HTTP Port: 9000
OS: Debian - EN - utf8
Platform: x86_64-linux
Perl Version: 5.30.0 - x86_64-linux-gnu-thread-multi
Audio::Scan: 1.02
IO::Socket::SSL: 2.067
Database Version: DBD::SQLite 1.58 (sqlite 3.22.0)

[slartibartfast]

A little more detail might help... what LMS version did this start with? What kind of search? Is full text search active? What platform, OS, storage?...

No idea when it started, I was investigating reported slow search in an earlier version of Material skin when I compared it to default and found it was just as bad. Material skin is now fast again. As kidstypike says just a standard full text search. I also used "black" as one of the test search terms. It was taking well over 30 seconds. Raspberry Pi OS Bullseye on a Pi4 4GB with a USB hard drive.

[kidstypike]

A little more detail might help... what LMS version did this start with? What kind of search? Is full text search active? What platform, OS, storage?...

Same problem here.

Full text search for "Black" took 42 seconds. (practically instant with material). Freezes changing to next track.

Storage m2 sata SSD. 70K music files.

Pi4B 4GB.

First observed today testing slartibartfast problem.


Logitech Media Server Version: 8.4.0 - 1674060761 @ Wed 18 Jan 2023 06:48:58 PM CET
Hostname: pi4music
Server IP Address: 192.168.1.247
Server HTTP Port Number: 9000
Operating system: piCore - EN_GB - utf8
Platform Architecture: armv7l-linux
Perl Version: 5.32.1 - arm-linux-gnueabihf-thread-multi-64int
Audio::Scan: 1.05
IO::Socket::SSL: 2.071
Database Version: DBD::SQLite 1.58 (sqlite 3.22.0)
Total Players Recognized: 3

[mherger]

A little more detail might help... what LMS version did this start with? What kind of search? Is full text search active? What platform, OS, storage?...

[slartibartfast]

There seems to be be an issue when performing a search in the default skin. The same search in Material skin is blazingly fast while the default skin is glacially slow. I am pretty sure it hasn't always been this slow. It displays "loading" for an awfully long time.