I've been doing a bunch of Unicode testing of the SlimServer, and have one problem that I can't get past.  The Template Toolkit used to process the various skin's web pages doesn't handle UTF-8 characters correctly, which causes some serious problems with certain skins.

This is easily noticed with the Location field - paths to files that have utf-8 encoded Unicode characters in their name do not display properly.  I narrowed it down to the template engine by adding a new filter that produces a hex dump of the current string, and add the appropriate code to songinfo.html to display itemobj.path as hex, the hex dump shows the correct utf-8 encoding for itemobj.path, so it is being passed in to the template correctly.  (This is good - it shows that the SlimServer is doing everything OK.)  The resulting page returned from the template engine contains the incorrectly encoded character.  (In fact, a single "a-acute" comes back as four bytes.)

Some skins break because of this.  For example, the EN skin (used by Bagpuss and others) include the path to the actual file as part of the "Play this song" link.  Since the path is encoded wrong by the templating engine, the resulting link contains the incorrect path, and fails.

There might be another bug here, that some skins use the ID of the track for playing it, and some use the path.

I'm not a perl programmer, so debugging the template code is going to take more time than I have right now.  I'd be happy to work with the Slim folks on this, and pass on some of the tools I'm using, like the "hexdump" filter.

FYI, tested on both OS X 10.3.9 and 10.4.5, both using perl 5.8.6.