What are "active torrents"?

[atkerr]

The term "active torrents" seems to have two different meanings in uTorrent. In the Category List, I might have 54 total torrents, 1 downloading, 53 completed, 4 active and 50 inactive, as shown in the picture. Here "active" means some UL or DL is taking place in the 4 active torrents.

http://i216.photobucket.com/albums/cc36/kerrat/uTorrnetactivetorrents-1.jpg

However, in the queuing section of the Preferences, where I'm asked to specify "Maximum number of active torrents (UL or DL)" I will not be able to activate a new download unless I specify a number greater than 54; the DL will remain queued indefinitely. Here "active torrents" really means "total torrents listed", whether actively exchanging data or not.

The picture shows that with one DL, four other torrents with actual activity and 50 inactive torrents, the DL will remain queued. It's uTorrent's recommendation that I allow 8 active torrents maximum according to my bandwidth test, but with these parameters, I can't start a new DL even though only 4 torrents are actually "active".

The point of all this is that the parameter "Max active torrents" in queuing prefs should refer to max ACTUAL active torrents instead of Max number of torrents listed.

My workaround on this is to ignore recommendations to restrict active torrents to a low number like 8 and specify a number like 80 which is large enough to cover any number of torrents I'm likely to have listed.

[Ultima]

To be considered active, the torrent has to be downloading or uploading at rates above the queue.slow_*_threshold value (bytes per second).

And don't start so many torrents simultaneously.

[atkerr]

But that's the point, most of them are seeding but inactive. Still, they're considered as active torrents when specifying max active torrents, even though they're not really active. The category list confirms this by calling them "Inactive".

[Ultima]

queue.dont_count_slow_* handles slow torrents blocking the queue.

[atkerr]

OK, I'll try that. Thanks.

[BlueDragon]

Did you give enough time to uT to start again the torrents after you changed the values in 'Maximum number of active torrents'? It may take a couple of min.

Also I suspect something is wrong in the situation you described. AFAIK the stopped aka inactive torrents do NOT count at all in the 'Maximum number of active torrents'.

Besides there are many other considerations which can be very important especially because a torrent occupying an active place from the queueing point of view always equals 1 (above the queue.dont_count_slow limit) but from the real activity point of view there may be huge differences in terms of bandwith usage. That is why most of the time you cannot reach an optimised situation if you rely on the presently implemented automatic mechanisms of uT for this task. In other words manual intervention will be required, at least that's what my experiences with uT teached me. Personally I prefer to control my main activities with force-starts (no queue story) and by setting up and / or dl limits on a per torrent base associated with low-medium-high bandwith settings. But again as stated, this is my personal opinion which others might (will) not share.

[atkerr]

Blue Dragon - thanks for your input. I wasn't referring to stopped torrents but seeding but inactive (no UL) torrents. These do seem to be counted as active torrents for queuing purposes, even with the "queue.dont_count_slow" markers active.

I agree with you that forcing a DL or UL will quickly get it going, regardless of position in the queue, but to me that's just one more step and such a forced torrent may keep seeding well past the point I've chosen to stop seeding, in my case 140%. So, there's a second step to stop it manually as well.

Another problem with the forcing approach occurs when I want uTorrent to go inactive for an hour or less while I burn a disk. Forced torrents of course do not listen to the scheduler, so more manual work - pausing the forced torrents, then restarting them when the burn is done.

As mentioned, I simply set my max active torrents to 80 so all my 50 or so inactive seeds can still remain seeding. The real problem for me is when the total of my actually active seeds starts to mount above around 8 or 10. Then I've got to stop some manually, and that's something I think uTorrent could help me out with if it would only recognize active torrents for queuing as those torrents with some actual UL transfers. The information is readily available as evidenced by the Active Torrents number in the Category List.

[BlueDragon]

I wasn't referring to stopped torrents but seeding but inactive (no UL) torrents. These do seem to be counted as active torrents for queuing purposes, even with the "queue.dont_count_slow" markers active.

Meanwhile I had a closer look to it and in the "uT logics" inactive means not active and may include stopped torrents or seeding torrents or downloading torrents (maybe also others like errors etc, I did not check this since I had none with this status while testing).

Also I tested what I was assuming and it came out exactly as I expected it. So I maintain that there is something strange in what you seem to experience with your settings because the inactive torrents are NOT counted as active even from the queueing point of view. To test it was very simple for me because I had enough torrents in various status states to get a good overview off the whole process and possibilities. What I did was simply to start all my torrents which were force-started (12) so they entered all in the queueing logics. My queuing settings were defined as 5 max active (ul or dl) and 4 max dl. At that time 2 were listed as active and 2 more were active but below my threshold (queue.dont_count_slow) of 3kb/s. At that moment I expected all the torrents to stay exactly the way they were e.g. none should have been queued. First about 5 (inactives) were queued immediately and I could not understand the logics behind this selection which was not making any sense to me (probably to uT though...). I don't discuss this further here because it would be to complex to explain. Anyway what happened is that about 2-3 min later all the newly queued torrents were unqueued at once as they should have been since the beginning. In the meantime no change at all at the activity level which could have been the reason for the unqueueing again. So my conclusion is that as I told you (out of own observations) you may need to wait a couple of min. to allow uT to adjust to the new situation. Moreover no need to set the queueing settings on huge values like you think would be necessary. That is clearly the situation on my system, this I can assure you.

About your other points, to me it's not a problem to "overseed" because anyway the minimum for any not already clearly overseeded torrent would be to reach 150% and I don't bother if I reach more because I did not manually stop my seeding on time. Every day I take a look at my torrents and I adjust what is needed, that has become my daily routine a bit like a ritual and I enjoy it.. Pausing and restarting is just 2 clicks away (select what needed or simply all and right click pause) so also this is not a problem to me. Seldom I need to pause but often I may limit the overall ul speed to get a better internet browsing experience since I maxed out my bandwith usage the rest of the time (everything fully dedicated to torrenting). Again 2 clicks away, just right-click on the status bar where needed and select the (customized) speed limit.