I enabled SQL debugging and here's the query that was run when I searched for the string 'mfsl'.  Looks like 'mfsl' is being turned into 'HASH 0X6CE724C'.

SELECT COUNT( * )
FROM tracks me
     LEFT JOIN contributor_track contributorTracks
               ON ( contributorTracks.track = me.id )
     LEFT JOIN comments comments ON ( comments.track = me.id )
WHERE ( ( ( comments.value LIKE ? ) )
  AND ( ( contributorTracks.role = ? )
   OR ( contributorTracks.role = ? )
   OR ( contributorTracks.role = ? )
   OR ( contributorTracks.role = ? ) ) )
	 
'%HASH 0X6CE724C%', '1', '2', '4', '5'

It's the official 6.5.2 build no nighly or other build.
It's in Slim/Web/Pages/Search.pm

The original code is:

# Normalize the string queries
#
# Turn the track_title into track.title for the query.
# We need the _'s in the form, because . means hash key.
if ($newKey =~ s/_(titlesearch|namesearch|value)$/\.$1/) {

$params->{$key} = { 'like' => Slim::Utils::Text::searchStringSplit($params->{$key}) };
}

# Wildcard searches
if ($newKey =~ /comment/ || $newKey =~ /lyrics/) {

$params->{$key} = { 'like' => Slim::Utils::Text::searchStringSplit($params->{$key}) };
}

The line "if ($newKey =~ s/_(titlesearch|namesearch|value)" catches the comments_value (was comments in 6.5.1) and produces the hash. If you change to the following it works again:

# Normalize the string queries
#
# Turn the track_title into track.title for the query.
# We need the _'s in the form, because . means hash key.
if (!$newKey =~ /comment/ && $newKey =~ s/_(titlesearch|namesearch|value)$/\.$1/) {

$params->{$key} = { 'like' => Slim::Utils::Text::searchStringSplit($params->{$key}) };
}

# Wildcard searches
if ($newKey =~ /comment/ || $newKey =~ /lyrics/) {

$params->{$key} = { 'like' => Slim::Utils::Text::searchStringSplit($params->{$key}) };
$newKey =~ s/_(value)$/\.$1/;
}

Ok, it's not beautiful but it works.
And this is a change in 6.5.2 that I don't understand. It's simply renamed from comments to comments_value without considering the side effects of the "_"/"." and hashing.

I see the same behavior that Jim describes on Windows XP. However on Mac OS X no matter what I put in the Advance Search Comment field the result will be all the tracks in the library. Only if I leave the field blank will I get 'No search results'.

Created attachment 2030 [details]
patch

The problem is the second searchStringSplit causing the already handled comment_value key to be processed again into the hash.

comments_value has to be used in the form because "comments.value" from a web template is interpreted as a hash <key.value>.  comments_value gets changed to comments.value in Search.pm so that the query will use the correct table and field <table.field>.

(In reply to comment #4)
> Created an attachment (id=2030) [edit]
> patch

That works on my WinXP Pro server.

Why the platform difference in behavior?  In the forums Michael Herger reported that comment searches were working fine for him - I'd assume that was on a Linux server.

Yes, I'm running slimserver on Linux.

One more question: do you use wildcards "my text*" or just the string you're looking for? (Both is working for me...)

no idea.  I'm not on michael's system (perhaps he wasn't searching on ONLY a comment).  It is just as strange to read claims that it worked previously.  Without the comments_value field, the sql was failing with an error due to an invalid "comment" field. this is what was fixed as part of bug 4797)

as for the osx difference, I think we need the d_sql log output to make any sort of judgement on that.  

you'd have to ask dan about the wildcards. I seem to recall that * is ignored, as we always do a search for the given string as part of another.  I expect searching for foo*bar will give you proper wildcard-type results.  My feeling is that the comment in the code is a bit of a misnomer.

(In reply to comment #6)
> One more question: do you use wildcards "my text*" or just the string you're
> looking for? (Both is working for me...)

My guess is that the '*' is simply getting stripped out when the search term in normalized. I can search for either

remaster

or

@#$%^remaster%$#!~

and get the same results.

fixed in trunk at change 12178
and in 6.5.3 at change 12179

Works for me on both Mac OS X & Win XP.

This bug has been fixed in the 7.3.0 release version of SqueezeCenter!

Please download the new version from http://www.slimdevices.com/su_downloads.html if you haven't already.  

If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.