Created attachment 2075 [details]
Cyrillic characters show corrupt.

SlimServer Version: 7.0a1 - 12431 - RedHat - EN - utf8
Perl Version: 5.8.8 i386-linux-thread-multi
MySQL Version: 5.0.21-standard

Web-browser: FireFox 2.0.0.5

Created attachment 2076 [details]
Cyrillic characters show corrupt. (2)

Comment on attachment 2076 [details]
Cyrillic characters show corrupt. (2)

this is after hitting the 'Search' button

Comment on attachment 2075 [details]
Cyrillic characters show corrupt.

this is before hitting the 'Search' button

What browser are you using? If you have another browser available, could you please try it in eg. FireFox?

see comment #2

Internet Explorer 6 and 7 cannot open SlimServer at all -- they just hang "Opening page http://slimserver..."

In server.log I see the following error:

[12:53:48.0764] Slim::Networking::Select::select (237) Error: Select task failed: Undefined subroutine &Slim::Utils::Prefs::get called at /usr/local/slimserver/Slim/Web/HTTP.pm line 660.

Is this a known bug??

Firefox 2.0.0.5 opens the SlimServer page fine, and there are no errors in the log.

Sorry for not reading your reports... 

Concerning MSIE: that error message rather sounds like there was some code still using legacy prefs code. Do you have some third party plugins installed? What skin are you using? Does the page load if you force default (http://yourserver:9000/Default)?

One more false alert: it's not a plugin, but in the http code itself. But it is indeed MSIE only code. I've checked in a fix - thanks for reporting this back.

Back to your encoding issue: are you familiar with HTML code? Do you know Firebug by chance (an extension to Firefox)?

If you do so:
- do a search
- hit the right mouse button over a correct representation of the string in question, select "Inspect Element" from the context menu. What's the code for your character?
- do the same with a broken representation - do you see a difference?

One immediate problem is that the following query fails (I can see it via FireBug):

http://slimserver:9000/Default/search.xml?query=%D0%9F%D0%B0%D1%80%D0%BA&player=127.0.0.1

Try it! I get a malformed XML error.

The query '%D0%9F%D0%B0%D1%80%D0%BA' corresponds to word "Парк" UTF-8 encoded, where:

0xD0 0x9F == letter 'П'
0xD0 0xB0 == letter 'а'
0xD1 0x80 == letter 'р'
0xD0 0xBA == letter 'к'

I think someone forgot to specify 'UTF-8' encoding while processing XML, and it's defaulting to ASCII.
Thanks.

You can try to access http://www.3amok.com:32180 (it might be up)

Michael, well-formed xml error was because of the unescaped '&' character. Could you please replace:

    '&contibutor.role=ALL' --> '&contibutor.role=ALL'

in two files:

     Slim/Web/Pages/LiveSearch.pm
     Slim/Web/Pages/Search.pm

Thanks!

I found the culprit of this bug -- LiveSearch.pm:

                push @xml, sprintf("<div class=\"even\">\n<div class=\"browsedbListItem\"><hr width=\"75%%\"/><br/>%s \"$query\": $total<br/><br/></div></div>",
                        Slim::Utils::Strings::string(uc($type . 'SMATCHING'))
                );

It looks like $query is encoded in UTF-8 (since it's part of the URL). When it's inserted into the sting, it's butchered into ASCII. The code that works better is:

                push @xml, sprintf("<div class=\"even\">\n<div class=\"browsedbListItem\"><hr width=\"75%%\"/><br/>%s \"%s\": $total<br/><br/></div></div>",
                        Slim::Utils::Strings::string(uc($type . 'SMATCHING')),
                        Slim::Utils::Unicode::utf8decode($query)
                );


There is at least one more place that has the problem (when hitting the Search button, and "manualSearch=1") -- but this should give enough clue to a person who knows Perl and SlimServer. Thanks!

search html/xml fixed added to trunk at change 12441

Created attachment 2078 [details]
patch, with possible manual search fix.

try this and let us know how this works out for you. Do you have ok results with Advanced Search results?

The patch fixed the simple search :)

Advanced search has a similar problem: the result is found ok, but the following fields are turned to ASCII 'Парк':

    Track, Artist, Album, Comment, Lyrics

Thanks!

patch committed to trunk at change 12445 along with possible fix for advanced search.
please test and verify various results as I do not have a test set locally to use with this.

To repro the issue/confirm the fix, all you need to do is copy/paste word 'Парк' into all the mentioned fields, and then to do Search. If the fields come back as 'Парк' -- it's fixed. If you see garbage 'Парк' -- it's still broken.

I'll test the next nightly build tomorrow...

Thanks!

The build of 2007-07-30 appears to be fixed... both Simple Search and Advanced Search. -- Thanks a lot for your help!

By the way, version 6.5.3 has the same issue, plus the search itself is broken: it always yields 0 results when searching with Cyrillic characters. -- can these fixes be back-ported to the 6.x branch?

I'm not sure it's really fixed. The search still is not (or no longer?) working on Windows. We'll have to give it some more testing.

This bug is being closed since it was resolved for a version which is now released!  Please download the new version of SqueezeCenter (formerly SlimServer) at http://www.slimdevices.com/su_downloads.html

If you are still seeing this bug, please re-open it and we will consider it for a future release.

It's not working, and I actually never saw this work. Checked:

   Version: 7.5.4 - r32171

Fucking assholes!