Search not working properly
turkeyphant
Member
in Bugs
a) Search is incredibly slow. For an exact match search string it takes often 20s+ to load results.
b) Search doesn't work for some short strings on web. I haven't experimented to find exact patterns but e.g. "ex" as a search string returns no results (this is expected as there is a three character minimum). But searching "ex:" misses many results including "ex:re" and includes results that shouldn't match (i.e. ones without the colon).
c) Likewise, search doesn't work correctly on the Android app. Here two character query strings are allowed. But a search for "ex:re" will not return the artist "ex:re". Again, I haven't experimented with all permutations where it doesn't work this is just one I have tested recently that isn't correct.
Comments
For me, searching is quite fast. On android app and web. It depends on the number of results. But I don´t have complaints about it.
Thanks for these. @turkeyphant if possible for (a) could you give me some searches that takes a long time for you?
See here: https://www.dropbox.com/s/8mcbkk668qncu34/2022-02-04%2012.40.42-1.mp4?dl=0
A search for the artist "Om" took 7 seconds and didn't even return the correct result.
A search for "alt-j" or "alt j" returns zero results.
A search for "ex:re" took about 18-19 seconds even though I had search this string previously.
Thanks! Have added these to the bug tracker to investigate.
A search for the artist "Om" took 7 seconds and didn't even return the correct result.
In the web app we mandate a minimum of three characters. I can't see a reason for this (I think it becomes quite difficult for a natural lanaguage search with such a small query) but I think it should be consistent between the app and the web. I'll try to return an error to make this clear.
I replicated this myself with the artist "Ty" - the query took 25 seconds and didn't return anything.
A search for "alt-j" or "alt j" returns zero results.
The problem here is that the "-" is taken as a negative operator, i.e. your query is "return all matches with 'alt' but not 'j'". I can make this work if I escape the "-" but obviously you shouldn't have to. I'll create a ticket for this.
A search for "ex:re" took about 18-19 seconds even though I had search this string previously.
When we create the query we surround it with "*" i.e. making the search string a search for that as a substring. This seems to make the query a lot slower. If I make a literal search for ex:re it returns one result (no T-Rex) very quickly. Tbh the results are much better if I remove the wildcard matching, and they are a lot faster. I've created a ticket to research this.
Thanks for the detailed response. Regarding the second point, that doesn't explain why "Alt J" returns zero results. I feel only edge cases would remain if the negative operator required whitespace before but obviously this is still not ideal. What is the escape character? Backslash?
I'm not sure why "ex:re" is such an outlier compared to the other examples in my video. Simply surrounding all queries with * doesn't seem to explain this.
What other operators and patterns are allowed in the search box?
Thanks for the detailed response. Regarding the second point, that doesn't explain why "Alt J" returns zero results. I feel only edge cases would remain if the negative operator required whitespace before but obviously this is still not ideal. What is the escape character? Backslash?
"Alt-J" contains a J. So if the query is "Alt and NOT J", "Alt-J" won't match. "Alt-K" would match. Honestly though, this is a fairly naive reading of the search syntax which is documented here: https://manual.manticoresearch.com/Searching/Full_text_matching/Operators .
Yeah, backslash is the escape character. I found I needed to add four of them!
I'm not sure why "ex:re" is such an outlier compared to the other examples in my video. Simply surrounding all queries with * doesn't seem to explain this.
Can you give me specific examples of what you mean by this - it might help me understand the searching syntax better myself.
1. I'm talking about "Alt J" not "Alt-J". It doesn't work without the negative operator either.
2. You day search is slow because of the * surrounding the query. That doesn't explain why some of my search terms are orders of magnitude quicker than others as all have the * around them.
In my experience, this type of thing is often variable in text search. One cause is if the string is short (this might be the origin of the three character rule). For example, I found even in a small test library that searching for "le" would take 20s, but much faster without the wildcards.
This is why I said I'll do more research and testing on this - I'm not sure if there are any "right answers" and it might have to be treated statistically.
I am also unable to use the search function. I've tried on the Android Astiga app, as well as a few others (substream, Ultrasonic) and I'm similarly not able to bring anything up.
Is there anything I should be doing to ensure my searches work consistently? Is it possibly an issue with the metadata of files? I notice other people are having similar issues.
Thanks for your help!
It is related to metadata because that is what is searched.
Can you give me an example of search terms that aren't working?
Does it work for you in the web app?