Linux 32-bit: SoulseekQt-2016-1-17-32bit.tgz
Linux 64-bit: SoulseekQt-2016-1-17-64bit.tgz
See the Changelog for list of features and fixes.
Unicode is not possible without completely breaking the existing Soulseek protocol. It's definitely one of the first things to go into a next-generation, backward-incompatible version of Soulseek though, if the day comes.
I can add that all downloaded music begins with small (lower case) letters. It isn't so beautiful for a collectioбn though is quickly corrected by programs
Could it possibly handle files with characters it doesn't like differently? At the moment it just won't download them, perhaps it could give them a name it can handle, like DOS does? Even if it's like UNK~A5E7.MP3 it's better than not being able to get it, if we can see it's what we want from the folder name perhaps and grab that.
Can you give an example for the original form of a filename that the client can't handle? The new client has a much better facility of mapping an actual filename to what's seen as being shared, so something like that should be possible at least as long as the new client is doing the sharing.
>Unicode is not possible without completely breaking the existing Soulseek protocol.
Wait. Why utf-8 would break anything? It seems to work perfectly in alternative clients. And if you think about how utf-8 would "break" something for old clients, think first of a mess we _already_ see when browsing someone with different system encoding. It really can't get worse.
Like I said, I might be able to manage something by mapping unicode filenames to something more presentable as exposed to other clients. Let me see what I can do in due time.