Soulseek

Tonight's build of SoulseekQt for Mac is the first public version of SoulseekQt that's built as a 64-bit executable. Up until recently, I've been using a version of OSX tweaked for use with an AMD processor inside of a virtual machine. The difficulties this created were many. It was not stable, it was very slow, but worst of all it did not support 64-bit programs, and consequently could not run the newest version of Qt Creator. Instead, I had to settle for an older 32-bit version that linked against older versions of the Qt library and could never be updated.

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.

Tonight's build is all about extending the existing filtering mechanism to address a few of the longest-standing, most popular requests for SoulseekQt. Primarily that for bitrate filtering, but with a little extra, and built on a base that can be further extended to add new forms of filtering. You can skip all this and just head to the download page, as the filter box present on search result and browsed share pages now has a 'Filter Help' button next to it that will provide you with a more concise version of what I'm going to be saying here about the new filters.

• 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.

I've received a couple of reports about the client crashing in the last few weeks. It's been months since I've had a crash myself, but I'm also not a super-heavy user either. If your client is crashing, the best thing you can do to help me root out these crash-causing bugs is to generate and post a crash report. This is a very simple process on Mac, but a little more involved on Windows.

On Windows: