DC++ .706 Performance Problems

I think you should check your security applications (firewall, internet monitor, etc.. if you have any) to make sure they give the same permissions to the newer version. Start with this faq : https://answers.launchpad.net/dcplusplus/+faq/103

Thank you for the reference. Firewalling did not seem to be a problem, and checking this morning this problem still exists.

I uninstalled DC++ again, this time removing all files and settings, as leaving them did not resolve this prior. From a clean install, I started up again. Everthing seemed OK prior to configuring the client. Windows XP firewall has always been disabled, but I did go in through Norton Internet Security and make sure that I have an exception set for DC++. I began hashing my file base again, which needed many hours to complete. After about 8 hours, client is nearly frozen again, taking up 80-99% of CPU. I can't figure this out, as all I did was upgrade without changing any system or client settings. Looks like I'll have to go to another application.

Also, this appears to be similar to reported Bug #230991, but I do not receive any disk errors. Calling up task manager sometimes will produce two instances of DC++ (both showing not responding, as they are extremely CPU-intensive after upgrading to .706). There were no problems getting access to any of the drives I'm sharing with DC++, both before and after the upgrade took place. Another note is that the application hang does not correspond to disk activity. The first time the problem was generated (right after the upgrade), I maintained all my settings so the hash info was used for the new version. The second instance, after a clean install and re-establishing settings, I refreshed my shared folders as a background task and all seemed fine up through about 200 GB worth of indexing. Hours later, this task appears to have been complete (I can't look at my settings since the application barely responds), judging by the lack of intensive disk activity. But the result is the same as before. Any help regarding what might go wrong with file indexing is appreciated.

Thank you for the additional suggestions. I took some additional steps before the two above by running chkdsk on all drives, then scanning for spyware (I already ran an AV scan the other day).

Running DC++ without the autoconnect was helpful to check on program behavior without running network activities. By connecting to each hub I would normally autoconnect to, I found that one was the culprit. Checking further, it turned out to be some kind of issue with connecting to multiple users. If I select "automatically search for alternative download locations", this will call up other file matches, but brings the program to a halt. Turning this off seems to fix, but I lose the ability to download from multiple locations, which worked fine in previous versions of DC++.

More strange behavior: when I lost the connection with the one user I was downloading a directory of files from, I used the "remove user from queue" command in order to bring up other options for downloading the source directory, and this also brought the program to a halt. No reponse, and massive CPU usage.

I am not happy at all with this situation, and I'd like to explore further how to get back the functionality I had before the upgrade. Suggestions for the fix to at least get the program running again are appreciated, though!

I downloaded 0.706 to upgrade from 0.698 and I think it was five steps back. Well, not on all things. Nice with new tabs and fast connection to hubs.

The bad thing is that when connected to hubs, everything slows down and when pressing a button on mouse, program grinds to a halt and doesn't come to life for one to five minutes. Very annoying when scrolling thru user lists.
Another thing was program splitting files in 1 to 90 kiB parts, annoying if file is over 50 MiB, it takes forever.
I don't use autoconnect to hubs, it's better to connect manually one after another.

I gave 0.706 same rights in Zonealarm and everywhere as earlier versions but still these problems.

I'm now back to reinstalled 0.698 without reboot and it works like a dream!!!

I'm continuing to use 0.706, but I'm not happy about all of the changes. Autoconnect doesn't appear to be a problem in itself for me, but it was helpful to turn off for diagnosing the previous problem. Biggest issue: using auto search for alternative d/l locations. When enabled, the program did find other users with the file I was after (just as previous versions of DC++ have), but this choked system performance for some reason. The loss of this ability truly defeats any performance improvements in the program, as without it, you must wait for this ONE other user to have a slot available on their end, in spite of ANY NUMBER of other users having this same file or files! Ridiculous! I had to turn this off, and overcome that glitch per the following steps:

To d/l multiple one or more files from multiple locations w/o causing the program to halt,

1. Search for the file/directory you are after using the search window.
2. Queue up a user with this file/files/directory of files for d/l.
3. Within the d/l queue, right-click on the first file needed and manually select the option of looking for alternative d/l locations.
4. A new search window will open containing other users with this file (matching TTH hits). From this list, highlight all users (the entire block), right click on that, and select the proper location. The last item on the right-click list will be the default d/l destination, which should be the normal choice.
5. The program will now properly queue up these other users and begin the segmented d/l sequence.
6. Close the search window with the list of users.
7. Return to the d/l queue, and go to the next file on the list which has only a single user associated with it. Repeat for each file. (This is very tedious if there is a large directory of files.)

For whatever reason, these above steps (which should be running automatically w/o causing havoc), will not work in 0.706 for me unless I run them on one file at a time.