Server Version#: 1.32.4.7195
Player Version#: 4.110.1
I’ve found search to be unreliable for local media ever since the new search was implemented and finally got irritated enough to investigate. Many times I’ve resorted to scrolling through my library to find what I want to watch since search doesn’t give me anything except the external stuff when certain words are included in the search query. In particular, this occurs when the word “the” is contained in the query.
In other clients I’ve tried, it’s hit or miss. For iOS, the local results pop in really late and there’s no indication that the search is still in progress. For Android, WebOS, and the Shield, the behavior is similar to the web. Unfortunately, the clients don’t indicate if a search is still in progress or has failed, so there’s no way to know if what you searched for doesn’t exist, if it’s still thinking, or if it’s failed.
My next step was to put the server logs into debug mode to see if it was actually returning results and indeed it did. With that in mind, it was time to see what the Web frontend was doing…
Looking at the browser’s DevTools, I identified the request responsible for searching the local media and observed that it was canceled at around 5 seconds.
For reference, this is the redacted request:
https://XXXXXXXXXXXXXXXXX.plex.direct:32400/hubs/search?query=the%20great&limit=30&includeCollections=1&includeExternalMedia=1&X-Plex-Product=Plex%20Web&X-Plex-Version=4.110.1&X-Plex-Client-Identifier=XXXXXXXXXXXXXXXXX&X-Plex-Platform=Chrome&X-Plex-Platform-Version=114.0&X-Plex-Features=external-media%2Cindirect-media%2Chub-style-list&X-Plex-Model=hosted&X-Plex-Device=OSX&X-Plex-Device-Name=Chrome&X-Plex-Device-Screen-Resolution=1920x1096%2C1920x1200&X-Plex-Token=XXXXXXXXXXXXXXXXX&X-Plex-Provider-Version=6.3&X-Plex-Text-Format=plain&X-Plex-Drm=widevine&X-Plex-Language=en
I opened the canceled request in a new tab and the expected XML was returned after a super long 16 seconds.
At this point, I’m reasonably confident in stating that there is some sort of timeout or race condition occurring in the clients. I was able to replicate this bad behavior every time I searched and even with queries that didn’t contain the dreaded “the” keyword–assuming the server’s response took longer than 5 seconds. The key to duplicating this issue seems to be to search something that would be contained in a large number of items which in turn makes the request take longer to process (the sample query above returns 1,445 results from my server if I modify the limit).
TL;DR:
- Clients do not properly handle slow responses to search queries. This results in no local results being displayed for some queries.
- Search does not offer visual indication of progress/status, so you have no idea if there are genuinely no results for a given hub, if the search is ongoing, or if the search failed.
- Response time of the server for search results suffers when there are many matching items.
