Files with name contains question marks are in constant que.

Confirmed, also here on Linux, even with the 2014-11-30 build that I am still using.

I tried something silly like adding myself to Userlist and downloading from myself. And no, I haven't (yet) gone all nuts! ;-) For as long as a path contains Unicode characters (e. g. the longer dash I used for quite some time for year ranges might already show the issue), downloading is impossible and results in "file not shared".

The only way out currently is to entirely do without Unicode in paths and keep both folders and files "free of question marks."
Just it escapes me why in spite of using both latest Qt and a recent Ubuntu flavor for distro, Unicode support is still such a huge issue in Soulseek.

However, this issue only seems to occur with folders, not with files shared in them!
Just tried some folder with some Turkish music in it, and every character was perfectly reproduced ... except for a folder that used the same character set: question marks all over...

----

After even more testing...

With folders, one really has to keep to a very basic ASCII charset (#32 - #127). Not even extended ASCII works: for instance, French guillemets which I thought to use as a substitute for a separator (e. g. 90s RAP » HIPHOP) will fail badly. Not even the degree sign (°) works. But once I replace the separator by something very basic like a simple hyphen or a plus sign, it works.
Of course en dash and em dash are Unicode-only and totally broken likewise. I can confirm the very same thing: file is stuck forever in queue and won't download until the folder that you're downloading from is "fixed".

I would not be surprised that due to a bug, SoulseekQt only works in UTF-8 for files, but still uses ancient ISO-8859-1 for folders. Because French é DOES work, also for folders. But try to turn it to Turkish characters (non-8859-1 obviously), and you're in trouble.

On Windows, the Soulseek clients use standard Windows APIs for accessing files. For backward compatibility, Windows APIs do not allow creating or accessing files that have question marks (or certain other punctuation or leading spaces) in the file name. This is a limitation imposed by the standard libraries in the OS, not the NTFS file system.

So if you're on Windows and have such a file that you are trying to upload, your client can't read it.

And if you're on Windows and are trying to download such a file from someone, your client can't create the file on your system. (Years ago, in the feature requests section of this site, I requested that the Windows client allow for some basic substitution of the taboo characters, so that the files be created locally with modified names. It hasn't happened yet.)

Also, if you are trying to download such a file from someone who is on Windows with a non-Unicode client like the old Soulseek NS, their client didn't even index the file with its true name; the question marks are replacing unsupported characters. So when you try to download from them, your client is asking for a file which, due to the question marks, their client can't even ask Windows to access, and which doesn't actually exist with that name anyway. There's no way around this except to encourage the person to switch to a Unicode-based client or to rename their files with only ASCII characters.