-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Folder scan fails with non-ascii path names #85
Comments
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. |
What I said earlier about a previous commit might be wrong. I'm unable to reproduce that error. What operating system are you running on? Filesystem type and encoding? Could you please post a path you suspect would trigger this error? |
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? |
Thank you for the pointer. |
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)?
[...]
The text was updated successfully, but these errors were encountered: