Make 'dont_count_slow_torrents' configurable

[GoogleCodeExporter]

In hope that you could implement this before the v1.0.0 release (and if you 
find it useful)

I think these two things would be useful for 'dont_count_slow_torrents'
1. Allow to configure the speed limit that triggers the characterization of a 
torrent as "slow". Possibly having different limits for upload and download
2. Allow to configure the time spend in the above speed limit that will trigger 
the characterization of a torrent as "slow". Possibly having different 
thresholds for upload and download

Original issue reported on code.google.com by hammered...@gmail.com on 7 Jan 2014 at 1:20

[GoogleCodeExporter]

Could you please test this patch?

http://dpaste.com/2EQRZJA/

Original comment by arvid.no...@gmail.com on 11 May 2014 at 2:51

• Changed state: Accepted

[GoogleCodeExporter]

it's against trunk.

Original comment by arvid.no...@gmail.com on 11 May 2014 at 2:51

[GoogleCodeExporter]

I am away from my build machine. The patch looks solid though.

Question: Is there a special value (eg -1) to give to the limits that disable 
them? ie don't consider non-uploading torrents as inactive. Or maybe this 
doesn't make sense anyway.

Original comment by hammered...@gmail.com on 11 May 2014 at 8:35

[GoogleCodeExporter]

I forgot to mention that I'll test it later.

Original comment by hammered...@gmail.com on 11 May 2014 at 8:36

[GoogleCodeExporter]

there's still the "dont_count_slow_torrents". if that's false, none of this 
logic will apply to the queuing.

Original comment by arvid.no...@gmail.com on 11 May 2014 at 4:16

[GoogleCodeExporter]

(I'm still away from my build machine)

I am talking about separating the dl/up limits and thresholds. Maybe the user 
wants to enable the dl limit but not the ul limit. Atm I cannot think of use 
case where this is useful but utorrent supports separate dl/up limits and 
separate dl/up (speed based)thresholds and I think Vuze does too.

Does this seem logical to you?

Original comment by hammered...@gmail.com on 11 May 2014 at 5:18

[GoogleCodeExporter]

I tested it. Observations:

1. Pausing a torrent doesn't clear the inactive flag. If I afterwards unpause 
it isn't queued but it goes to downloading directly.
2. The dl and ul limits should be considered separately. It makes sense to 
consider a downloading torrent as inactive if the dl limit isn't reached but 
not the ul limit. The opossite is true for seeding torrents. The attached 
pictures from the Vuze's options illustrates my point.
3. Is is considered too much fine tuning if you have separate 
auto_manage_startup for dl and ul?
4. Finished torrents don't obey the upload queue limits upon completion. I have 
set my active uploads to 0 but when a torrent completes if goes straight to 
"seeding" status instead of being queued. Even if I reapply my queue settings 
it doesn't switch to "queued" status.

Vuze's options: http://www.imagebam.com/image/376eb8326536696

Original comment by hammered...@gmail.com on 14 May 2014 at 6:28

[GoogleCodeExporter]

regarding (1), the inactive flag should be cleared when paused. However, it's 
not obvious to me how this would affect its own state when being unpaused. I 
would expect it to just not count against the download/seeding limits.

regarding (2). The current semantics is that both the upload and download 
thresholds need to be met to be considered inactive (i.e. both rates need to 
stay below their limits). My understanding is that this would cover the use 
cases one might want, both for downloading and seeding.

The limits are against the payload transfer rates, so a seeding torrent will 
always have 0 download rates. I suppose the edge case is a downloading torrent 
whose download rate is low or zero, but it is uploading. That would still be 
considered active. Is that unreasonable?

(3) it's not clear that there's any important use case for this. I imagine that 
reasonable timeout is primarily determined by the kind of internet connection, 
and it would be the same for downloading and seeding torrents.

(4) is a good point. I should fix that.

Original comment by arvid.no...@gmail.com on 15 May 2014 at 3:59

[GoogleCodeExporter]

does (4) only affect torrents with some files marked as do-not-download?

Original comment by arvid.no...@gmail.com on 15 May 2014 at 7:39

[GoogleCodeExporter]

quick reply for 4:

I tested with single-file torrents

(comments on the other points will follow later)

Original comment by hammered...@gmail.com on 15 May 2014 at 10:16

[GoogleCodeExporter]

I cannot reproduce this in client_test in trunk. I pass in -^ 0 -v 1 with a few 
seeds already (which start off as paused). the download I add then is paused 
immediately as it completes.

Original comment by arvid.no...@gmail.com on 15 May 2014 at 3:53

[GoogleCodeExporter]

First of all, I should inform you that this weekend(plus friday) I might be 
totally unavailable. I might be available for comments, but not for build/tests.

1. Exactly. If I pause an active torrent that went active because of not 
reaching the slow limits it should get recounted against the queue limits if it 
gets unpaused.

2. To me personally it makes much more sense in the following situation. If I 
have many torrents in download queue that means I care about them being 
downloaded. I don't care if they are uploading or not in this scenario. If one 
torrent doesn't download fast enough I want to activate the next torrent until 
it maxes out my down speed.
On seeding torrents it doesn't even make sense to watch slow dl limit. Seeds 
never download.

3. Fair enough. I can't think of any valid reason to have separate timeouts too.

4. I'll need to retest. In my previous test: I had set my active upload limit 
to 0. I had 2 seeding torrents as queued (unpaused but because of the 0 limit 
they were queued) and some other seeding torrents paused. Also I had set the 
active downloads limit to 1. I had 2 torrents in the queue for downloading. I 
set the slow limits so high that the first downloading torrent would never 
reach them and to force the second to be active after the timeout. It worked. 
But when the first torrent finished, instead of being "queued" it went to 
"seeding" status.

Original comment by hammered...@gmail.com on 16 May 2014 at 9:17

[GoogleCodeExporter]

for (2), it's not enough to enable/disable the thresholds independently for 
your use case. downloading torrents would need to ignore the upload rate 
threshold (which seems like a reasonable behavior in general. effectively 
seeding torrents will ignore the download threshold).

Original comment by arvid.no...@gmail.com on 18 May 2014 at 10:20

[GoogleCodeExporter]

I made that change, and checked it in to trunk. please check it out at your 
next convenience.

Original comment by arvid.no...@gmail.com on 18 May 2014 at 11:42

[GoogleCodeExporter]

Tested with latest trunk. Now no matter what I set the limits to the next 
torrent never leaves the queue to start downloading. I suspect this is due to a 
comparison typo in the code.

Original comment by hammered...@gmail.com on 22 May 2014 at 8:25

[GoogleCodeExporter]

sorry. I made a mistake in my last commit. I just reverted it in trunk.

Original comment by ar...@bittorrent.com on 22 May 2014 at 10:07

[GoogleCodeExporter]

Ok. It seems to work now. (I tested with downloading only)
But there are still 2 things that don't work:

1. Pausing a torrent that became active due to the limits and immediately 
resuming it doesn't leave the torrent as queued but instead it continues being 
active immediately.
2. Still when downloads are finihsed the go to seeding status even though my 
queue upload limit is set to 0. I'll need to investigate more on this the 
coming week.

Original comment by hammered...@gmail.com on 22 May 2014 at 11:00

[GoogleCodeExporter]

> Still when downloads are finihsed the go to seeding status even though my 
queue upload limit is set to 0

Do you mean "session_settings::active_seeds" is 0? Otherwise I believe it's 
supposed to start seeding.

Original comment by ar...@bittorrent.com on 22 May 2014 at 11:12

[GoogleCodeExporter]

Yes active_seeds is set to 0.

Original comment by hammered...@gmail.com on 22 May 2014 at 11:17

[GoogleCodeExporter]

> 1. Pausing a torrent that became active due to the limits and immediately 
resuming it doesn't leave the torrent as queued but instead it continues being 
active immediately.

Let me rephrase this just to make sure I understand:

torrent A was started because _another_torrent_ (torrent B) was determined to 
be _inactive_. You stop torrent A, by setting the paused flag (but leaving the 
auto-managed flag set). You would expect torrent A to remain paused for some 
time. Is that correct?

I wouldn't expect torrent A to stay paused. There's still a slot to be filled, 
since slot B doesn't count. Unless you change the queue order, A would still be 
the next candidate to be started.

Original comment by arvid.no...@gmail.com on 23 May 2014 at 2:28

[GoogleCodeExporter]

No qbt unsets the automanage flag when torrents are paused so they can really 
remain paused and not get unpaused automatically. So I'll rephrase the 
situation to this:

Torrent A is considered inactive and because of this Torrent B starts 
downloading. After a while I pause Torrent B and unset the automanage flag. 
Immediately after that I unpause Torrent B and set the automanage flag. But now 
Torrent B instead of waiting in the queue for X seconds it goes directly to 
downloading.

PS: Now that I explained this thing I understand that I might be an idiot. If 
Torrent A is considered ALREADY inactive it does make sense to start subsequent 
torrents immediately upon unpausing(or adding to the session). So forget about 
this particular item. You seem to do the correct thing.

Original comment by hammered...@gmail.com on 23 May 2014 at 6:18

[GoogleCodeExporter]

am I correct in interpreting this as you're not aware of any remaining issues 
(with regards to this) in trunk? and I can close this ticket?

Original comment by ar...@bittorrent.com on 3 Jun 2014 at 4:42

[GoogleCodeExporter]

>am I correct in interpreting this as you're not aware of any remaining issues 
(with regards to this) in trunk? and I can close this ticket?

Almost. There still the problem where a finished torrent doesn't obey the 0 
queue limit for seeding and goes to seeding.

However, I haven't time to further test this atm. Maybe in a week.
Even if I am correct the bug should exist in the implementation and not in the 
API, so you can surely "fix" this later without breaking compatibility. (of 
course shipping with broken functionality is bad).

Original comment by hammered...@gmail.com on 3 Jun 2014 at 6:37