Deluge Forum

Whenever I load up Deluge, it is fine. However, upon beginning/continuing a torrent file the GUI tends to lock up/freeze intermittently. If I completely stop/pause the torrent everything is fine, but otherwise the client is next to dead.

Another thing: As of this latest build, sometimes Deluge will not properly exit entirely and cause a lagfest in Windows. It reports to be using no resources, but everything is slow and stuttered. This past time I had to manually close three or four duplicate processes of deludged.exe *32 before everything returned to normal.

Using XP x64, completely updated.

I have the same problem with deluge 1.1.8 whenever i start a new torrent the GUI seems to be unresponsive, the problem remains even if i stop/pause the torrent file. My OS is win xp 32.

I've been playing around with this on my VM and found that "fixing" the crippling microsoft did to the tcp/ip stack has solved the 'laggy' issue. I used a program from this site: http://www.lvllord.de/?lang=en&url=downloads to increase my max half-open connections to 100.

Tried that and this is my result:

Well I give up. I'm going to another client. Thanks anyways.

Best wishes

So once you have patched xp do have to change the limits in Deluge.

MikeMike wrote:Well I give up. I'm going to another client. Thanks anyways.

Best wishes

I understand your frustration, but give 1.2 a try when it comes out.. I've changed the design quite a bit to alleviate these types of issues.

I''ve encountered the same problem (regular gui freezing) and I may try the patch.

Surely any problems with connections should not affect the UI at all, given that the UI should be running in a separate thread or with some form of Model View Controller or equivalent to prevent a connection wait from stalling the GUI. OK I admit I'm just speculating on the cause of the issue being thread related given that I don't have knowledge of the program (or any Python programming ability for that matter ).

Deluge is threaded although I think some calls in 1.1.x are blocking.
Threads (and concurrency in general) are somewhat hindered in python due to the GIL.

The UI communicates to the daemon through xmlrpc and if there aren't enough half-open connection slots available then it will appear to stall or lag waiting for a slot. This has been fixed in 1.2 since we use a different rpc method with only 1 connection, instead of multiple as with xmlrpc. Furthermore, the new classic mode runs in a single process, so for those not utilizing the daemon functionality there are no rpc connections at all.