SoulseekQt

The biggest feature in today's release, if not the most useful for the majority of users, is private room support. No longer do you have to switch back to Soulseek NS to accept private room invitations or to administer your private rooms! At least assuming everything works as it should, which I've only managed to verify insofar that two of my usernames were able to invite each other to and inevitably abandon "bs room 1" through "bs room 17".

Many of the complaints lately have, one way or the other, had to do with share browsing. Firstly, and quite understandably, a fair number have been baffled by the absence of any status tracking for share browsing requests. If your listening port is properly forwarded, either because the UPnP module managed to talk to your router or, much less likely, because you've forwarded it yourself, this is less of an issue. Most attempts to browse the shares of other users should be successful, and you've probably learned it's just a matter of waiting until the browse window pops up.

The idea of search correlations came to me about a week ago with a jolt and an a-ha moment as I've been going through my list of features in the original client that have yet to be implemented in SoulseekQt. One item in particular stood out as a real take-it-or-leave-it deal. Ye Olde and Notoriouse Things I Like recommendations system has reached a point of total entropy years ago. It's still in use, but almost nothing has changed. The things that were at the top of the list five years ago are still there, effectively unbudged.

Small update this time around. The biggest news is probably that the Windows version finally has a proper installer! Other than that a few small additions, including a couple of long-requested small features.

• Search and Share Browse filters now accept exclusion tokens preceded by a dash (-).
• P2P communication between two clients of this version or higher will be obfuscated in an attempt to avoid detection by ISPs that are crippling Soulseek peer connections. Completely unproven at this point.
• Client window is now shown before shares are re-scanned so as not to appear that the client hasn't started when scanning large shares.
• Client will now dump peer messages of improbable lengths, probably avoiding a crash.

There have been way more reports than usual in the last few months about Soulseek transfers being unusually slow for different users, from different places on earth at different times of day. We suspect many Internet service providers have taken to slowing down peer Soulseek connections, and have set out to try and do something about it. Since it's not clear what each ISP is doing in each case, we had to resort to a lot of guesswork. Our starting theory is that in many of these cases, protocol analysis is done by the ISP to identify peer Soulseek connections.

• UPnP initialization was moved to a secondary thread to speed up startup time.
• Client no longer crashes if sharing one or more files larger than 2GB when a peer requests shared file list. (Thanks to CNoise for his tireless work in helping hunt this one down!)
• Client now asks for username and password if run for the first time.
• Open File menu option for complete downloads, also works via double-click.
• Open Folder menu option for downloads.
• Login failure is now always reported, not just when providing an invalid password.

The main addition in tonight's build, as foreshadowed by the announcement title, is the ability to set the maximum number of active uploads past the heretofore limited number of just one. This started off looking like a relatively simple change, but ended up complicating things quite a lot, especially but not exclusively when it came to maintaining a maximum upload speed for several simultaneous uploads. I haven't been able to generate a very heavy upload stream on my end, so the whole thing is only moderately tested.

In no particular order:

Not enough for a full-blown announcement, too much for a one-line description on the download page. It was 9/13 when I started, I swear.