View Issue Details

IDProjectCategoryView StatusLast Update
0005147MediaMonkey 4Playlist / Searchpublic2009-05-08 20:46
Reporterrusty Assigned To 
PriorityurgentSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version3.1 
Target Version3.1Fixed in Version3.1 
Summary0005147: Search for exact text containing special characters doesn't always work
DescriptionIf 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.
TagsNo tags attached.
Fixed in build1237

Relationships

related to 0005004 closedLudek Full-text-search: characters such as '.' should be removed from the query 
related to 0005134 closedLudek Searching for special chars like '.' no longer works with new full-text search engine 
related to 0006170 closedLudek Searching for quoted strings via search bar no longer works after SQLite update (MM 4.0 only) 
child of 0003040 closedLudek Implement proper full-text search 

Activities

Ludek

2009-01-07 08:08

developer   ~0016041

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.

Owyn

2009-01-07 13:26

updater   ~0016050

Last edited: 2009-01-07 13:29

"artist:a-ha", the embedded "-" is (sort of) treated as not operator.

Ludek

2009-01-07 18:09

developer   ~0016058

Last edited: 2009-01-07 18:09

Fixed and covered by regression testing in build 1209.

Ludek

2009-01-07 18:40

developer   ~0016061

Last edited: 2009-01-07 18:41

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.

lowlander

2009-02-20 17:53

developer   ~0016815

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

rusty

2009-03-11 18:30

administrator   ~0017056

Last edited: 2009-03-11 18:31

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?

Ludek

2009-03-12 14:02

developer   ~0017068

Last edited: 2009-03-12 17:34

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).

rusty

2009-03-13 20:46

administrator   ~0017093

Verified 1227.

Ludek

2009-04-16 09:55

developer   ~0017497

Last edited: 2009-04-16 10:06

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.

jiri

2009-04-16 10:16

administrator   ~0017498

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.

Ludek

2009-04-16 12:55

developer   ~0017500

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).

Ludek

2009-04-16 13:11

developer   ~0017501

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.

peke

2009-05-08 20:46

developer   ~0017755

Verified 1244