Multiple uploads issue

I'm not sure what exactly triggers my problem but I have upload slots set to "1" and after some time has past, I find that multiple uploads are going. It seems that this occurs when my screensaver ( engages, but I could be wrong. This wasn't an issue until later builds of QT (multiple upload slots option).

I'm currently using 9/26/11 build.

I'm not able to reproduce this problem, but I'll keep an eye out for it. Anyone else had similar experiences?

I've installed the newest build (10/18/11) and the problem persists. In addition to multiple uploads issue, Soulseek will now not respond (system tray) after I have minimized and let my screensaver engage. I can confirm that BONIC isn't the cause of my problem and that it seems to happen with any screensaver.

I have to use Task Manager to end the process to close SK. I noticed that when SK locks up like that, Task Manager shows CPU usage at 25 (I have i5-2400, quad-core) and around 149k for RAM usage. The numbers don't change.

Do you happen to know if you have a very large number of uploads in your queue at around the time of the lockup? Also, how many files are you sharing? I suspect this might have something to do with the new upload ordering algorithm which is meant to account for things like user group priorities and privileged users which has shown performance problems in the past (that I had addressed to a significant degree). The goal here would be to identify which area of the client is causing this performance issue. I'll post a link here later tonight that doesn't perform any kind of special upload ordering to see if it changes your situation. If that doesn't work I guess I'll have to think of something else :)

Thanks, Nir

I spent the day looking for possible slowdowns related to having a long upload queue. Things on my end started getting pretty problematic when I roughly crossed the 2,000 file mark. Part of the slowdown did have something to do with the upload ordering algorithm, so I've added an optimization that more or less takes care of it. You can try it out with this client, just make sure the executable is in the same folder as the usual DLLs. The other part of the problem is that the Qt UI gets pretty sluggish after a couple of thousand of entries in the upload tree. I don't really know what to do about that. If the new client doesn't take care of your problem, you can try and use the expand folders button to collapse all of the folder nodes. I noticed the UI slowdown doesn't occur in that case. Also if you don't have the 'clear complete/aborted uploads' box checked you can try that. It might help prevent the upload list from getting overpopulated. This is all assuming that any of this is causing your problem in the first place which it might not. No harm in trying I guess!

Thanks, Nir

I keep getting a login: sockets error after leaving it open for a while.

Thanks for pointing it out, this is a bug in the latest nightly build. I compiled a version of the executable that shouldn't have this problem: (needs to be in the same folder as the original SoulseekQt.exe). Has the freezing problem gotten any better with the last version I posted?

That newest build, I'm not seeing any hang ups from before. I did however notice that the multiple uploads issue does still exist.

One issue I have with the new client, is that it takes about 10-15 seconds for the window to appear when you start it up. I'm sharing around 36k files (4k folders). Is there anyway you can change the boot up procedures to make the client appear around 3 or 4 seconds? I realize with the large amount of files, the client would be unusable (even if it showed up), but just being able to tell that the program is running, sooner, is a benefit.

I also noticed that the newest build doesn't remember Expand Folders, Expand Users settings. Let me know if there's anything I can post or show to troubleshoot the faulty upload issue.


Took me a few days, but I finally managed to trap the extraneous upload situation on my end: I also addressed the issue of the UI only appearing after the shares have been rescanned, as you've requested. The UI will remain frozen in that time, as you said, though there might be room in the future to decrease the wait period for scanning large shares, or at the very least provide a progress bar.

Thanks, Nir