Mac port

I usually wait longer before releasing a new version, but I've been working on a user notes feature, and am quite pleased with how it turned out. So I figured, why the hell not. This is the equivalent of the user notes feature in the original Soulseek client, but with a better integrated, more prominent user interface that makes it less of a secret feature. To add or edit a user's note, use the corresponding context menu option. The attached note will appear next to their entry in your user list and any other list you put them in, meaning the unshared or ignored lists.

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.

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

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