Custom Query (2447 matches)

from what I can see (please do correct me if I'm wrong and close the ticket), deluge doesn't seem to like using more than one thread to check a torrent even when there are several hundred torrents in the queue. This seems like a waste of resources and time, given that if:the load was spread across more cores, or n torrents could be checked concurrently (where n is the number of threads your CPU supports), or there was a setting to allow you to choose some way to more efficiently use the resources available, Deluge would be several times faster at starting up or adding multiple torrents where the data already exists.

tl;dr: spread checking torrents across available cores

sorry if this is a little incoherent, I've had a lot of coffee and not much sleep

more info on my current system just in case it helps: #deluged --version deluged: 1.3.3 libtorrent: 0.15.10.0

Using the GTK-client when connected to a remote daemon and loading the Preferences dialogue doesn't respect the 'Download to' / 'Move-Completed' / 'Copy .tor to' directories set on the server.

In this instance the server 'Download-to' is set to a path that won't exist on the client machine (a raid device /media/md0/...)

The client forces this to a directory that exists locally (e.g. /home/<user>/, for 'Download to'). If another setting (even in another tab) is changed and apply/ok are pressed, these directory changes are sent to the server.

Perhaps if connected to a remote daemon, the GTK path selection field shouldn't be used?

enable in options icon display in notification area set in windows settings that deluge icon in notification are is displayed always ( default is hide when inactive) quit deluge start deluge again settings are not remembered, my guess it that windows seems not to think its the same app for witch it remembered settings

platform tested is windows 7 x64 fully upgraded