Folder scan fails with non-ascii path names

[tim-seoss]

scan fails for python2.7 due to (I'm guessing) unicode path components in the folder. Should I try python3 instead (I got the impression that's not finished)?

python supysonic/bin/supysonic-cli  folder scan main

[...]

    scanner.scan(folder, TimedProgressDisplay(folder.name, self.stdout))
  File "/usr/local/lib/python2.7/dist-packages/supysonic-0.2-py2.7.egg/supysonic/scanner.py", line 62, in scan
    files = [ os.path.join(root, f) for root, _, fs in os.walk(folder.path) for f in fs if self.__is_valid_path(os.path.join(root, f)) ]
  File "/usr/lib/python2.7/os.py", line 296, in walk
    for x in walk(new_path, topdown, onerror, followlinks):
  File "/usr/lib/python2.7/os.py", line 286, in walk
    if isdir(join(top, name)):
  File "/usr/lib/python2.7/posixpath.py", line 73, in join
    path += '/' + b
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe6 in position 19: ordinal not in range(128)

[spl0k]

Python 3 is on its way but not quite ready yet, there are some issues that still need to be addressed. In the meantime you can try checking out commit 8674965, scanning with unicode paths should work on this one.

[spl0k]

What I said earlier about a previous commit might be wrong. I'm unable to reproduce that error.
Did it happen after you added new file to a folder or after a simple git pull and folder scan?

What operating system are you running on? Filesystem type and encoding? Could you please post a path you suspect would trigger this error?

[tim-seoss]

This bug happened on initial install of supysonic during the initial directory scan.

After a bit of digging, this seems to be dying when it hits a directory which includes the letter μ encoded in CP850. The system is Linux with ext4, but the directory name predates the common usage of UTF8 (although that's now what the system has set as the default encoding) on Linux.

I can reproduce on a fresh install with:

#!/usr/bin/python3

from os import mkdir

mkdir ("A dir with a ".encode('CP850') + b'\xe6' + " - greek letter mu in CP850".encode('CP850'))

I also use mopidy (also python 2) on the same system, and it indexes and plays the tracks (it also displays correct track metadata, but this is probably coming from the mp3 tags). I suppose it must store and use path components as opaque byte sequences (except perhaps where it needs to do something like print them for debugging purposes, where it must workaround decoding errors).

I suppose supysonic could either do the same, or complain at scan time - giving the problematic path (as far as it can be decoded) as an error message?

[spl0k]

Thank you for the pointer.
You should now be able to use Python 3, but I'll try to fix this 2.7 issue anyway.