Search Very Slow (3 minute response)

[Rumzzz 35]

Hi @LukeAny progress updates for this issue?

This has really been negatively affecting my users, as a hung search for any user causes slowdowns for the entire server.

[Chillout 114]

Stable Server version 4.9.3.0 fixed the slow search for me. 

 

[slicedmass 6]

Agreed, issue is fixed for me too.

[Rumzzz 35]

I updated to 4.9.3.0. I think the multi-word issue seems resolved but there are still a few cases where searching takes minutes long (seems to be smaller word searches)

Searches that came back within 10 seconds: Ice Cube, Kanye West, Kid Cudi, Andy Clausen

Searches that take minutes to load: The Creator, Leon, War, don, tyler, mark

 

[Chillout 114]

@Rumzzz

You are right, there are still some searches that activates Emby server CPU meltdown command.

 

[Rumzzz 35]

@Lukejust wondering if this is still being looked into? I am still getting lots of hung searches and server lock-ups

[Luke 42307]

On 2/1/2026 at 9:29 PM, Rumzzz said:

@Lukejust wondering if this is still being looked into? I am still getting lots of hung searches and server lock-ups

Hi, yes we are still looking at it. Thanks.

[kingom 6]

Just found this thread, only want to say i'm experiencing the same problems since some weeks

[milindmody 2]

I have updated to 4.9.3.0 and this issue is still there for me. Any single word searches are fine but as soon as I have two or more words it takes 45 seconds to 1 minute to run a search. It's extremely frustrating. I preferred the older search. And I would still request an advanced search option based on IMDB # . 

Any guidance of time frame to get this fixed would be appreciated. 

[Luke 42307]

On 2/12/2026 at 4:09 AM, milindmody said:

I have updated to 4.9.3.0 and this issue is still there for me. Any single word searches are fine but as soon as I have two or more words it takes 45 seconds to 1 minute to run a search. It's extremely frustrating. I preferred the older search. And I would still request an advanced search option based on IMDB # . 

Any guidance of time frame to get this fixed would be appreciated. 

HI, we are working on improving this. Thanks.

[Rumzzz 35]

I will definitely be moving to the beta channel the instant this fix is out to test thoroughly.

[Rumzzz 35]

Installed version 4.10.0.7 beta just to see if the sqlite updates would help, sadly searching is still sporadically unreliable.

Still looking forward to a fix, hopefully soon.

Edited March 29 by Rumzzz

[HandsGroober 3]

Any update on this? A couple of short concurrent searches are enough to lock up the server entirely. 

[visproduction 338]

Would a built in delay to the search function help?  Typically, fixing a complex search is done on the server side where the product owner can distribute the demand to multiple servers. When the server is local to the admin, then fixing complex searches with more server bandwidth can be recommended, but won't help for admins that don't upgrade hardware.   So, maybe a built in delay to force complex searches to be more friendly, could limit the demand on the server to be more friendly.  This doesn't make complex searches work any faster, but perhaps would keep the server from locking up. Or throttle down (raise the LInux nice setting) search priority and just offer a text update "... Searching now through all the libraries..."   Just an idea.

 https://duckduckgo.com/?q=SQL+lokup+searches+with+delay+using+.js+script&ia=web
For Linux: https://www.geeksforgeeks.org/linux-unix/nice-and-renice-command-in-linux-with-examples/

Edited Saturday at 04:12 PM by visproduction

[Rumzzz 35]

Not sure if a delay or an increase in bandwidth would help much in this case. My Win11/13600k/32GB RAM machine will lock up just from a single search query.

If a proper fix to the query itself is going to take much longer, then I would honestly prefer reverting it (where searches would take 15 seconds every time, without locking up the server)

[bandit8623 235]

so weird that i have never had this happen.  on windows. i do have a 24 cores 48 threads though.  35Tb library.  on a hardware raid ssd setup though.  

when i do a search i dont even see cpu usage go up.

 

Edited Sunday at 12:24 AM by bandit8623

[Rumzzz 35]

That IS odd. My library is ~80TB but I think the difference in my case might be related to the number of artists/performers/composers that are tagged on my files.

I never see the Emby process use more than 15% CPU usage, even when it's locked up from a search query. I also have 10GB allocated to cache size in the settings, but the only time it's ever gotten close to using that is during a database clean/vacuum.

[bandit8623 235]

15 minutes ago, Rumzzz said:

That IS odd. My library is ~80TB but I think the difference in my case might be related to the number of artists/performers/composers that are tagged on my files.

I never see the Emby process use more than 15% CPU usage, even when it's locked up from a search query. I also have 10GB allocated to cache size in the settings, but the only time it's ever gotten close to using that is during a database clean/vacuum.

seems related then to the storage speed?  as cpu isnt bottleneck.

[Rumzzz 35]

Running a 2TB WD BLACK SN850X, not even half full so I doubt that is affecting it.

Really wish I could revert to the previous search until a fix is ready to test out.

[HandsGroober 3]

On 11/04/2026 at 12:35, HandsGroober said:

Any update on this? A couple of short concurrent searches are enough to lock up the server entirely. 

Apologies. At some point I allocated my emby server with only one vCPU. I'm not sure how this happened.

I've provisioned the server with eight vCPUs and searching is no longer a problem.

[Neminem 1633]

Yes search can be slow, if you run Emby on a underpowered pc.

This all started after search was reformed 4.9 server version.

Using delimiters is always a good option.

I guess its Emby's version of fuzzy search that comes into play here.

More CPU power / quicker search.

But WHY ???

Edit: Adding.

I also guess it depends on the numbers of extras.

Search = John

Media items to search = 127.236 less than a 3 sec.

 

Edited 50 minutes ago by Neminem

[Luke 42307]

Hi, we are working on improving this. Thanks.