Setup failing due to unicode errors

[nhoad]

Running on FreeNAS 8.3, i.e. FreeBSD 8.3.

[130729-00:23] Starting server on port 10050 ...
[130729-00:23] running full update...
[130729-00:23] ERROR   : error while updating media: UnicodeDecodeError 'ascii' codec can't decode byte 0xc3 in position 1: ordinal not in range(128)
[130729-00:23] ERROR   : rollback to previous commit.
Traceback (most recent call last):
  File "/devsnd-cherrymusic-f45dbee/cherrymusicserver/sqlitecache.py", line 466, in update_db_recursive
    for item in generator:
  File "/devsnd-cherrymusic-f45dbee/cherrymusicserver/sqlitecache.py", line 577, in enumerate_fs_with_db
    for fs_child in File.inputfilter(item.infs.children()):
  File "/devsnd-cherrymusic-f45dbee/cherrymusicserver/sqlitecache.py", line 710, in children
    content = sorted(content, reverse=reverse)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 1: ordinal not in range(128)
[130729-00:23] items added 0, removed 0
[130729-00:23] ERROR   : error during media update. database update incomplete.
[130729-00:23] updating word occurrences...
[130729-00:23] media database update complete.

Platform should not be an issue here - the issue is that os.listdir is being passed a unicode string which has mixed results: http://docs.python.org/2/library/os.html#os.listdir

Changed in version 2.3: On Windows NT/2k/XP and Unix, if path is a Unicode object, the result will be a list of Unicode objects. Undecodable filenames will still be returned as string objects.

Which is what I'm getting - mostly unicode strings, but a few byte strings as well.

Changing that sorted call to something like sorted((s.encode('utf8') if isinstance(s, unicode) else s for s in items), reverse=reverse) works for me on Python 2.7, in the sense that it doesn't crash at this point, but I can't speak for how it will work for other setups without further testing. It does still crash at another point due to another UnicodeDecodeError, however.

Based on other reported issues about normalising to always use unicode where possible to match Python 3 as closely as you can, I'm not confident in submitting a pull request as this explicitly makes everything byte strings. That, and I don't know the code base, and it breaks Python 3 compatibility.

From a user experience standpoint, not being notified in the UI that something went wrong can be considered an additional bug.

[devsnd]

Thank you for your detailed report!

This is a duplicate of #315; We decided that we would encode every string as unicode inside cherrymusic instead of using mixed representations, since python3 is still considered to be the "main" platform for cherrymusic. We'll try to remedy those issues as soon as possible.

Anyway; If you'd like it to work rightnow, you can simply switch to python 3.
(You might want to delete the HTTP-session files when doing so, since cherrypy will complain about them being in the wrong format. This only means that you need to login once again, you can do so by rm ~/.local/share/cherrymusic/sessions/* )