Shareaza becomes unresponsive whenever a download is in progress

[abolibibelot1980]

Shareaza [v. 2.7.10.2] becomes almost totally unresponsive whenever a download is in progress. At first, when I had about 2000 downloads in the queue and the TigerTree.dat file was about 300MB, it happened only when a file was being downloaded at a high rate, usually upward of 100KB/s (which was already annoying enough but manageable as it didn't happen so often). Now that I have about 9000 downloads in the queue and the TigerTree.dat file is almost 550MB (I couldn't say if either of both of those conditions have any bearing on that issue), it happens every single time a download is in progress, even with a measly rate of 1KB/s. When it happens, the CPU load of the Shareaza.exe process is usually stuck at 13%, which means that it maxes out the CPU's single thread capacity (Intel i7 6700K => 4 cores / 8 threads). I couldn't find any workaround whatsoever, except shutting down the connection globally, or pausing any active download if I need to do something else, like browsing a list or adding new downloads, but even that is made extremely tricky since I can barely do a single action every 30 seconds or so, and when it behaves like this I often have to repeat the same action repeatedly (for instance : attempting to pause a download, or attempting to do a selection) until it is actually performed, while it stubbornly continues the transfers. Then when all downloads have stopped, it becomes normally responsive again. I don't know what is causing that but it's a major annoyance. Preserving user interaction should be paramount. And with multi-cores CPUs being prevalent now, it would seem to me (even though I'll admit knowing very little about programming) that any single-threaded program makes a very poor use of the available processing power.

Someone described a similar issue with a quite astonishing level of verbosity in this thread from 2012, reporting the results of his experiments (most notably splitting his very large library or wiping the TigerTree.dat and Shareaza.db3 files) — and as often on such forums the replies were irrelevant, unhelpful and unnecessarily harsh.

[ansani]

Ok! I was able to replicate in my setup. I found the glitch in the hash code. I've updated the library weeks ago and - now - it seems the issue is fixed. I will release the new build in a few days.

[abolibibelot1980]

I'm beginning to use v. 2.7.10.4 alpha just now, and I'm glad to report that at least that issue has (so far) completely disappeared With 2 downloads active (albeit at a low total rate of ~5KB/s) the interface is perfectly responsive (I will have to see how it behaves with higher transfer rates). Don't know what kind of magic you did to achieve this but kudos to you ! (Even more impressive as it's considered an alpha release and it's already more stable than the last official release.)

EDIT : Well, it's still getting slow and freezing quite often when there are more simultaneous downloads and/or a higher total transfer rate, and perhaps also more active file searches at the same time, but at least it remains responsive enough to preserve interaction, and I can pause active downloads if really needed, which wasn't even possible at this point with v. 2.7.10.2, so it's a vast improvement anyway. I'll have to refrain from adding too many new downloads while the queue deflates a little bit, hoping that it will improve matters in that regard. I'm still concerned about the sheer size of the TigerTree.dat file, which has now reached 558MB and doesn't seem to ever stop growing, even if I remove large folders from the library. What exactly is the purpose of this file, and what happens if it's simply deleted ? (According to the person who created this forum thread I mentioned above, not much of anything happens, which is quite puzzling.)

[abolibibelot1980]

Well, today with the latest 2.7.10.4 2012-12-27 release, it's getting stuck almost as often and as annoyingly as before with v. 2.7.10.2, with 3 simultaneous downloads on average, and a total transfer rate which can be as low as 10KB/s... Not much has changed since yesterday (in fact there are significantly less downloads in the queue — well, it's gone from slightly over 10000 to about 9700, which is still quite a lot), so this is certainly puzzling. Strangely, when it gets stuck like that, if I manage to either open the settings window, or to get a hold of the scroll bar and not let go of it, it becomes sort of responsive again, but as soon as I either close the settings window or let go of the scroll bar, it resumes this [frozen for about 30 seconds / unfrozen for about 1 second] cycle. I tried disabling the “Interface.TipsDownloads” option, figuring that perhaps those tiny windows being constantly updated based on which file the pointer is hovering over could contribute to the issue, but it hasn't improved the situation significantly (only when it does get stuck the main window does not get cluttered with a dozen such tiny windows). It would seem like certain sources are more prone to triggering this than others — and it can be sources with a very low available transfer rate — for reasons I fail to hypothesize. For instance I've had a reasonably responsive interface with a download at an average rate of 20KB/s, whereas one specific source with a measly transfer rate of about 0.3KB/s triggered freezes whenever it was actively transferring.

EDIT : As soon as I sent this message, Shareaza was back to being as snappy as ever, with 3 downloads at ~70KB/s on average, now this is definitely very puzzling! O_O Sometimes I wonder if I'm being actively tormented by unseen forces taking great delight in witnessing my endless suffering — this is one of those times... But this may be consistent with what I wrote above : another specific source which has a transfer rate usually around 3KB/s stopped transferring about half an hour ago, and it would seem like it coincides with the interface being snappy again. That one is a Shareaza client, but I can't see the exact version as it appears hidden in the corresponding tab[*]. I could try to provide more info about those sources if needed.

[*] Yet another small annoyance : sometimes the client name is only partially displayed in the upper area of the browsing tab, when an unidentified number appears before. In this case I can read this : Browse : paulo (xx.xxx.xxx.xxx:6346) [1045/1263] - Shareaza 2. And so the version number is hidden. And I don't know what these numbers between square brackets are supposed to be, as neither of those corresponds to the number of shared files for instance (1568 in this case) or anything else I could think of (not much else actually).