Search function in LR doesn't return correct results; often misses entries in the filesystem

[soarpasser]

Windows 10, 0.8.5 msi, WSL2

Issue -
Using the search box to search for entries can be very janky, as it often misses random entries in the filesystem.
However, while using the browser's native Ctrl+F search option in the "Categories" section one can see all the entries corresponding with the same search query in the filesystem.

Example:
Enter a search query and hit enter, only two entires can be seen listed

Go to "Categories", hit Ctrl+F and enter the exact same query, and all four of the corresponding entires are shown - which is supposed to be the correct result that the LR search returns

P.S. Interestingly, changing the search query in a way that shouldn't affect the search results (for example, removing a letter at the bottom of the search term) can cause LR's search to return different results.

Pressing the "rescan archive directory" button in LR settings does absolutely nothing except making my hard drive produce some horrible sounds as it tries to work hard through the entire filesystem.

The only way to get the LR search function to work as intended is by constantly changing the search query and pressing enter.

Here you can see that the search function finally shows all the intended results.

This suggests that there's probably something wrong with the search box in LR - And seeing that the "Categories" section has no problem displaying the correct entries on the filesystem, it makes me think that this definitely has something do do with the search function, rather than some other setting in LR or on my hard drive. Hopefully this issue can be resolved as it is incredibly annoying especially when trying to add and edit new entries to LR.

[Asinin3]

Can't reproduce, shows all 4 galleries for me with same search terms. Same result if i remove last letter from search

I'm on Windows 10 as well, but using nightly builds.

[soarpasser]

Can't reproduce, shows all 4 galleries for me with same search terms. Same result if i remove last letter from search I'm on Windows 10 as well, but using nightly builds.

Ah, well I'm using the standard build straight from the release page. Perhaps that's the difference and the issue isn't present in the nightly builds?
Also - this search term I listed above is just an example. The actual issue can happen with any random gallery and search query.

[Difegue]

I think this is a search cache issue somehow -- I believe this button should help instead of the rescan directory one:

The cache is normally busted whenever changes to the database happen, but it looks like it's giving you results based on incomplete DB snapshots somehow?
Changing the query slightly prompts a cacheless search in any case so it makes sense that you'd have the correct result that way.

[soarpasser]

That's even more interesting, as I've also tried using the "reset search cache" option together as well - Though I click that first and then proceed to do the database rescan. Issue still persists. Perhaps I should do it in the reverse order?

Edit: looks like it is actually the order that's causing the issue. After some testing, I've found that the search function only returns the correct results when I click all 4 of these buttons from top to bottom, and then enter the search query in the box.
**_This issue can sometimes still happen even if I do this though_**, but a quick restart of the LR client can fix that.
![image](https://user-images.githubusercontent.com/74951691/178179986-78437d32-b277-4d2a-8260-aebaa5b5e8f8.png)
For anyone that runs into this issue in the future, this could be a workaround.

UPDATE: THIS APPARENTLY DOES NOT WORK AFTER FURTHER USER EXPERIENCE & TESTING.

[soarpasser]

Reopening this issue as this problem seems to have gotten worse/not improved recently.
Again, archives that exist on the filesystem can sometimes not show up in search results at all despite being logged in LR's database. In some cases, doing the old trick of modifying the search query multiple times does the trick, but sometimes it doesn't.

Now, rescanning or clearing the search cache will not work when an exceptionally stubborn archive refuses to pop-up; in this instance usually only a restart of the application will fix the issue.
There is no reliable way to reproduce this bug.
I also couldn't find any logs related to this issue, so can't really figure out how this is happening either.

[Difegue]

With #555, I have severely reduced the amount of cache warm jobs due to search getting that much faster, which should improve phantom archive cases like what we saw here.

In any case though, filesystem watching on the WIndows versions is buggy thanks to WSL and can get worse depending on how/where the content folder is stored, so I can't guarantee issues like this won't still pop up.
Not much I can do about it besides suggesting using the Linux version on a dedicated NAS or something..