View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005147 | MMW v4 | Playlist / Search | public | 2009-01-06 23:25 | 2009-05-08 20:46 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 3.1 | ||||
| Target Version | 3.1 | Fixed in Version | 3.1 | ||
| Summary | 0005147: Search for exact text containing special characters doesn't always work | ||||
| Description | If a field contains e.g. 'Full 1:00' and the user then searches for "1:00" (in quotes) via the searchbar, no search results are returned. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1237 | ||||
| related to | 0005004 | closed | Ludek | Full-text-search: characters such as '.' should be removed from the query |
| related to | 0005134 | closed | Ludek | Searching for special chars like '.' no longer works with new full-text search engine |
| related to | 0006170 | closed | Ludek | Searching for quoted strings via search bar no longer works after SQLite update (MM 4.0 only) |
| child of | 0003040 | closed | Ludek | Implement proper full-text search |
|
|
Jiri also indicated that "# 1" doesn't work. i.e. "help!" works "o'connor" works "# 1" doesn't work "1:00" doesn't work Should be covered by regression testing. |
|
|
"artist:a-ha", the embedded "-" is (sort of) treated as not operator. |
|
|
Fixed and covered by regression testing in build 1209. |
|
|
Re: artist:a-ha You must enter artist: "a-ha" to get the result (otherwise SQLite's engine doesn't return right results) Should be documented as well. Fixed in 1209 too. |
|
|
Verifying in 1223 field:"xxxxx" doesn't seem to work, field:xxxxx does. ie. artist: "a-ha" doesn't give results. "11:00" works "#1" works "gimme!" works |
|
|
Tested 1226: a) a-ha doesn't return results (my understanding from comment 16061 is that this was fixed) b) artist:"a-ha" doesn't return results c) #1 doesn't return any results (should have a hit for Album = 30 #1 Hits) d) Help! - the ! is ignored. Is that intentional? |
|
|
a) a-ha doesn't return results - this is ok, as I wrote in the note: You must enter "a-ha" to get the result (otherwise SQLite's engine doesn't return right results because - it ignores such chars) b) artist:"a-ha" doesn't return results - fixed in build 1227 and covered by automated regression test c) #1 doesn't return any results (should have a hit for Album = 30 #1 Hits) You must use "#1" similarly like in case of a), but true is that #1 should return all tracks including 1 similarly like google does (fixed in build 1227) d) Help! - the ! is ignored. Is that intentional? Yes, the ! is ignored, similarly to the most of full text search engines including google. Rusty, in order to understand better the logic: I currently use the SQLite3 full text search engine that ignores such a chars ('/','\','?',',','|',':','.','_','(',')','[',']','&','@','#','+','*','!','-',';') as described in 0005134. But if the string is quoted then I use the MM 3.0 behaviour, I strip quotes from the string and use SQL's LIKE condition which is slower and distinguish between 'a' and 'á'. If you want we could perform this for any text string including such special chars in order to keep behaviour similar to 3.0, but note that this would not ignore accents ('a' is not same as 'á') for such a strings therefore I chose that the strings must be quoted (which I think is right). |
|
|
Verified 1227. |
|
|
Re-opened, because Rusty and Dale requested clarification of what MM is supposed to return for item a) and why searching for 'a-ha' doesn't return results until you quote it. Request is here: http://www.mediamonkey.com/support/staff/index.php?_m=tickets&_a=viewticket&ticketid=4410 Answer is here: The problem is in the way how SQLite FTS3 engine currently indexes words like 'a-ha', it splits the word on the delimiter and creates two words in order to index them ('a','ha'). The results are that searching for 'ha' finds 'a-ha' and searching for 'a' also finds 'a-ha', but searching for 'aha' doesn't find 'a-ha'. We could fix it by customizing the FTS3 engine so that also word 'aha' would be indexed when indexing 'a-ha', but because we are in MM 3.1 RC state we decided (with Jiri) to defer it to MM 4.0. Btw. We should maybe enter a new bug for this because the original problem was related to the quoted strings and it has been already fixed. |
|
|
Just to clarify the technical side of the proposed solution: In case there is a separator in a word (like in 'a-ha'), the word would be indexed as three words 'a ha aha', so that all combinations are found. That seems to be the only way to satisfy all the users, since sometimes the separator is meant one way, sometimes another. |
|
|
Yes, for MM 3.1 we could just prevent from the case when user enters 'a-ha' and no results are found. We could partially fix it by considering 'a-ha' as 'a ha'. This way he will see all tracks including both 'ha' and 'a', i.e. also all 'a-ha' tracks (without a need to rebuild the full text search index as the former solution requires). |
|
|
The latter solution is safe and doesn't require rebuilding of full text search index therefore I used the solution for MM 3.1. Fixed in build 1237. |
|
|
Verified 1244 |
