Nightly Build 10/18/2011

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

Regarding the client crashing

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:

Multiple upload slots; A few extras

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.

Nightly Build 9/21/2011

In no particular order:

Nightly Build 9/13/2011

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.

Wish list, Unicode chat/bugfix

Not much to tonight's build. The wish list feature has been a long time a-coming, and so here it is. There was nothing stopping me from throwing together a quick hack to make wish list searches work on top of regular searches (or so I thought), but I wanted to provide a little something extra, as I try to do with all original client features I have to re-implement. Just getting the basics to work turned out to be more complicated than I had expected.

The Unsharing

The subject of banning is one that I've been reluctant to tackle in SoulseekQt since the very beginning. There are few topics in the history of Soulseek that have been as much the subject of strife and ill-will. Horror story after horror story, it seemed as if for almost every case of it being used to prevent download abuse, someone out there has been banning for all the wrong reasons. Because they didn't like what the other person was sharing, or often for no apparent reason whatsoever, and refusing to answer any questions; a situation I've been in myself in the past.

Progress bars, ETAs, status aggregates and more

Most of the improvements in tonight's build, a few days overdue after I lost my Mac and Linux virtual machines to some indiscriminate deleting and having had to rebuild them from scratch, are to do with the file transfers view. The first thing you might notice are progress bars, a decidedly nicer way to present each transfer's progress. This change is more than cosmetic however; You will also notice a separate progress bar for the total of your downloads from each user, and even additional progress bars for each folder, if more than one folder is being downloaded from a particular user!

User group download prioritization

New in tonight's build, the ability to prioritize the download order of users in specific groups, for those of you who want finer-grained control over their upload queue. By default all user groups are awarded a download priority of 0, which means the downloads of users in that group won't be processed in any special order. Raise it to 1 however by means of clicking the 'Configure User Groups' button at your User List tab, and your client will process their downloads before all but those in groups with even higher priorities.

Public Build 6: Threaded file transfer, stored size settings

The big change this time around, in response to the many problems the client had uploading files on Mac and Linux, is a complete shift of the file-transfer system from relying on Qt's single-threaded event model for handling socket communication to a multi-threaded, one-thread-per-transfer model. This went a long way toward simplifying things, and had the unexpected effect of greatly improving download and upload speeds on all platforms when the bandwidth capacity is there.


Subscribe to Soulseek RSS