Good, I have been delving somewhat into this and solving this 'little' problem is not that simple. First of all the encoding is fixed to be latin is due to the fact that I use fromAscii and toAscii convertors in Qt. This is not exactly as we might want. However, the alternative: to use fromLocal8Bit and toLocal8bit (both would take the defined locale into account), do not preserver the convertion. so tolocal8bit(fromlocal8bit(string)) is not always the same as string; which leads to files we cannot open. Now, because I am converting certain sections of the software to be more unicode compliant we will start storing data in Utf8 format. The problem then become bytes that represent non-existing unicode characters. These are not preserved either and again -> file cannot be opened. The option to ask the user to actually force his filenames to be correct, also in the locale internationalisation, might be too difficult. Not everybody wants to spend 3 days renaming songs due to an ø or ü that is no longer valid due to a changed internationalisation, or due to a NFS share that reports the wrong information, or due to a zip file that didn't properly store the filename. Currently it is unclear how we can solve this problem.
Indeed I have the same problem. I think the idea to fix it should be to make the encoding depend on the LANG environment variable of the system.
The music-directory scanner assumes the filenames to be latin1 encoded. I am using UTF-8 (as most current Linux distros do). When filenames contain special characters as üöäø, bpmdj will show funny characters instead. I temporarily worked around that by renaming my files to latin1 (using convmv) but now they look strange in the shell, of course... (Anyway, as this is my first report: I am _deeply_ impressed by bpmdj! Thank you!)