uTorrent STILL ignores *some* seeding limits

[amber89]

The problem of uT going way over SOME torrents seeding ratio (AND also passes set minimum seeding time) has been going on for many (every) versions. Now, in uT Win v3.2.3 Previous post - same issue:

https://forum.utorrent.com/viewtopic.php?id=122266&p=2

Yes, most do stop at the seeding goal %. Some don't. More than just 1/ 100 or 1000 have the problem, but not consistently 1/ 5 or 1 / 10.

In THIS instance, 1/4 exceeded the seeding %. THIS instance, # of MB exceeded is small; OTHER times, exceeded volumes are substantial.

In previous post, I thought uninstalling / reinstalling ONE version fixed it, but that was only temporary or coincidence. Reoccurred in several of later versions, after my post, linked above. Has happened in every version I remember since my previous post (& versions before that).

In previous post, I u/l screens & data of every setting imaginable. No fixes for, or ID of the actual problem were ever reached (aside from me uninstalling / reinstalling). Now, I use uT as portable. Same issue. Doubt has to do w/ portable or "installed," since happens w/ both.

In attached screens, I had prefs settings:

Seeding ratio: 65%

Minimum seeding time: 1 min (I've tried other values w/ no success: 10, 30 min)

When torrent reaches seeding goal: Limit u/l rate to 0 (zero means stop)

1) there's no way a torrent exceeds seeding goal / %, (sometimes by 100's of MB), in < 1 min.

That's not the problem (unless seeding time setting has been & STILL is malfunctioning)

2) # of torrents that exceed the ratio is small & sporadic; but happens enough to be potential problem. Some I catch while still seeding, after they exceed the goal & stop them. Some continue seeding past their goal overnight.

3) There is never any apparent problem or error w/ files that exceed seeding goal (that I've seen in uT data, or data shown in my previous post on the issue). No problem playing these files.

Though nice of others to post, saying, "I tested & it stopped exactly on seeding %," it proves nothing. Most of mine stop correctly; enough don't, it's irritating & could be a problem w/ ISP caps, depending on HOW far torrent(s) exceed limit, overnight / when I'm not around.

NO MATTER if uT has started d/l torrentS or not (maybe seeding started before d/l), it should STOP u/l when seeding % and / or seeding time are met (here - ONE MIN.!).

Seems like an ongoing bug. I'd guess there's some other odd setting / combo of settings causing this

[ciaobaby]

And have you checked if those jobs that "exceeded" your ratio, did so BEFORE they went into seeding??

[amber89]

How could they exceed the seeding ratio before they ever started seeding?

Maybe I don't understand the question.

But, no - when they 1st start seeding, the listed ratio starts out near 0.

Also, the u/l amount starts near 0. Not like a faulty gas pump that starts out at $0.07, if that's what you mean.

It takes time for problem ones to exceed the ratio. Out of the ones that wind up exceeding the ratio, that I've looked at their progress - intermittently, as the d/l & seeding progresses, they appear to proceed normally. Don't exceed u/l or d/l rate limits. At least, while I'm watching.

One theory (nothing to back it up): If seeding begins before d/l starts, uT has a bug that doesn't count the u/l amt before d/l starts.

Or, if d/l rate for A torrent is much > than d/l rate, a bug? throws off the ratio control.

In specific cases, "Something" internally causes uT to ignore amounts already u/l; or resets the counter, part way through the process. If it COMPLETELY ignored seeding ratio, seeding would NEVER stop. But it always eventually stops, on the problem ones.

The "overage" is never by the same seeding ratio %, nor by same volume or same % in excess of selected file size.

Overage amt is > than can be accounted for by overhead or by wasted MB.

Since I have no logs or individual torrent's u/l & d/l history to look at, can't see what it was doing at the time it exceeded u/l ratio. Was it still d/l? Had it stalled for a long time? Did u/l rate suddenly exceed set limit, for some reason? Etc.

In most cases (& this one) I don't stop / pause / change que / change seeding ratio / change u/l or d/l rate limit, at any time before the torrent(s) finished d/l OR seeding.

[ciaobaby]

How could they exceed the seeding ratio before they ever started seeding?

Maybe I don't understand the question.

It's really very, very simple, the "ratio" is based on (uploaded data ÷ downloaded data) x 100

AND while your client is downloading from seeds and peers, your client is ALSO uploading to other peers (that's why it's called Peer to Peer) THEREFORE it is obviously possible to have uploaded MORE data than you have downloaded BEFORE the final pieces are requested thus completing the download.

Now in THIS scenario, because BOTH the seeding goal ratio AND the seeding goal time have to be reached BEFORE the goal is actually reached, seeding WILL continue until the specified period has elapsed.

[amber89]

Thanks. You initially asked,

have you checked if those jobs that "exceeded" your ratio, did so BEFORE they went into seeding?

You also said,

the "ratio" is based on (uploaded data ÷ downloaded data) x 100

If they haven't started seeding, u/l data = 0.

Zero ÷ any # always = 0. BEFORE it starts seeding, the ratio can only be 0 (if reported values are correct).

Part of what you said goes directly back to what I said. The uT seeding ratio algorithm (or what it USES) could be flawed. What?!? If seeding begins LONG before d/l starts, the ratio isn't met, because it would be n MB uploaded / 0 MB downloaded (division by 0 is undefined). uT probably ignores that situation, because sometimes this scenario is legit. Therefore, it could seed 1000%, if d/l never begins but seeding continues.

Meeting min seeding time. I said:

In attached screens, I had prefs settings:

Seeding ratio: 65%

Minimum seeding time: 1 min

Again, there's no way seeding ratio could exceed the ACTUAL ratio & target by 100's of MB in 1 min (in some cases).

uT is obviously not programmed (correctly) to compare the SELECTED file size, compare that to the data VOLUME to be uploaded AT a given seeding ratio and STOP it when the specified DATA VOLUME (a % of total file size) is reached.

If this is the case, it's using the wrong data to trigger stopping seeding. It should be using an actual data volume to seed, not the percent value entered (which obviously doesn't work for this purpose in certain circumstances).

If a torrent size is 100 MB & seeding % set at 150%, the TARGET u/l size is 150 MB.

uT may already calculate that, but isn't using it to stop seeding.

When 150 MB u/l target volume is met (even if not 1 MB has been d/l), uT should STOP seeding. It's met the intended, set goal, regardless that u/l data ÷ d/l data still could calculate a different seeding RATIO.

Using ONLY a calculated seeding RATIO, rather than a target seeding VOLUME, to trigger stopping seeding, can result in errors. I don't know what uT does w/ these values internally, but it does NOT seem to use target seeding VOLUMES to stop seeding.

[DreadWingKnight]

Are you downloading ANYTHING on these torrents?

[ciaobaby]

If they haven't started seeding, u/l data = 0.

Wrong!

If a torrent size is 100 MB & seeding % set at 150%, the TARGET u/l size is 150 MB.

Wrong again

Look at the values for 'Downloaded Bytes' and 'Uploaded Bytes' NOT "Size", according to your theory if parts of the jobs are skipped the job would NEVER be completed because the data on disc would would never reach the 'size'. OR if pre-allocate was set, NO actual pieces would be requested because the data size on disc would already be at the finished size as soon as as the job started.

Ratios are ALWAYS been based on DOWNLOADED data not the payload size.

[amber89]

Yes - they finish. I've posted before on this.

I believe it to be either random flaws in the calculated current seeded ratio, or uT relying ONLY on set seeding % pref (NOT on a target volume, based on seeding % x torrent size).

If set seeding goal at 70%; select a torrent of 100 MB.

If seeding begins before d/l & seeds 70 MB w/ 1 MB downloaded, it doesn't stop seeding (AFAIK), even though it's reached the seeding goal of 70 MB. uT apparently doesn't use the target seeding VOLUME as the trigger to stop.

It continues to d/l until finished, but also continues to seed (or may), until finished d/l'g. Best I can tell, in the above scenario, it allows both the seeding ratio & target seeding volume to be exceeded. At least, that's what I see in these cases.

I don't know exactly how uT is coded to handle all the different scenarios of u/l : d/l ratios or target volumes. What it shows on GUI & what it does internally are likely different.

But there's a flaw in logic or a bug. My guess is it doesn't use target volume as the trigger, which would be the most reliable method. Once it hits target seeding VOLUME (EASILY calculated, internally), it should stop - period.

[DreadWingKnight]

But there's a flaw in logic or a bug

So far the only flaw I'm seeing is in YOUR understanding.

When you download a torrent, the seeding goal is based on the total amount downloaded, not the size of the torrent. It has ALWAYS been this way.

Period.

[amber89]

DreadWingKnight - no misunderstanding on my part. Read again w/ feeling.

As simply as it can be put:

uT sometimes seeds WAY more than EITHER the downloaded volume (or selected file size), TIMES the seeding % set in prefs. Sometimes seeds 10, 30, 50%, N% more than downloaded volume times set seeding ratio %.

Did you not see in my screens, that it d/l 408 MB & seeded 486 MB, for a ratio of 1.192 (119.2%), when I had seeding ratio set at 65%? I don't know how to make it any easier to see the problem.

NOTE: most times, it involves MUCH more than 70 - 80 MB extra.

No matter what semantics one throws in, too many times, uT far exceeds the expected seeding VOLUME * OR * RATIO.

If a file selected is 100 MB & it eventually downloads exactly 100 MB (which is always what I see in the cases I'm referring to -it d/l's full selected sizes);

AND in prefs - seeding % I set 70% w/ a min time = 1 min, AND uT winds up seeding 155 MB - that's not a misunderstanding, it's a flaw. That is exactly what happens.

If you want to explain w/o sarcasm, how uT far exceeding the MAXIMUM POSSIBLE volume, that should ever be seeded, given EITHER the total downloaded volume OR the selected volume AND given the prefs seeding %, is not a mistake - please do. I would sincerely appreciate it.

ciaobaby,

You're ignoring the facts of what's happening.

I don't think I'm going to get anywhere, here, but...

IF... the ratio in GUI is defined as: (U/L volume / D/L volume) x 100,

then if 0 bytes have been u/l (NOT started seeding), the seeding ratio MUST be 0 (regardless of what the GUI shows). Because... ZERO DIVIDED BY ANY NUMBER = 0.

Whether uT is following law of mathematics, in what it displays or in its function - I don't know.

I'm not going to argue basic laws of math.

First, most probably don't care what the ratio shown in GUI is, if it's not accurate (if it allows > to be d/l than MAX possible, at a given MAX % for the MAX file size SELECTED).

Read that again carefully!

Also, I simply said, WHEN the target seeding volume is reached, it should stop.

Forget skipped files - if you mean, files not CHOSEN for d/l (those wouldn't even count). I mean % of SELECTED file sizes.

AND... in these cases, the downloaded file sizes are always = to selected sizes.

If the SELECTED OR DOWNLOADED file size is 100 MB & seeding % = 70, the FINAL u/l volume should NEVER be > 70 MB. It could be LESS than 70, if the entire 100 MB never finishes downloading. Besides, that's not the situation or specifics I'm talking about.

[ciaobaby]

apparently doesn't use the target seeding VOLUME as the trigger to stop.

Correct! Once the "volume" of uploaded data has been reached (in relation to the downloaded) it ALSO has to reach the time limit set for being in a seeding status

My guess is it doesn't use target volume as the trigger,

No need to 'guess' and get it wrong, you could read the user manual where it is explained.

So according to your theory:

If only 100MB of a 5GB job was selected and downloaded, would you be happy about having to upload 5GB to reach a 1:1 ratio???

[DreadWingKnight]

Did you not see in my screens, that it d/l 408 MB & seeded 486 MB, for a ratio of 1.192 (119.2%), when I had seeding ratio set at 65%? I don't know how to make it any easier to see the problem.

If this ratio happens before the download completes (yes it can happen, don't try to convince me that it cant, you won't win the argument) then it will keep uploading while still downloading. You will then, when the download completes, immediately stop.

[amber89]

dwk, let's see if I understand your comment. Maybe.

If this ratio happens before the download completes ... then it will keep uploading while still downloading.

I interpret that to mean (as I said - many times now), if the seeded volume (& ratio) exceed the "set seeding ratio" before the the download completes (or before it starts d/l'g), then uT may / can far exceed the expected (final) seeding ratio & volume? How is that different than what I said, many times?

Because it "can happen," doesn't make it acceptable.

I don't agree w/ answers about problems in software, like, "That's just the way it is."

** Many times, the exceeded seeding volume / ratio that I see are far larger volumes than attached screens show.

I'm suggesting that uT's seeding stop trigger have as its 1st ? (or important) condition:

"If actual seedED volume = the expected MAX download file size X the seeding ratio, is reached (uploaded), at ANY time before, during or after a file is finished downloading, the SEEDING will STOP, if user has it set to stop."

The "Max" expected (possible) d/l size would be the SELECTED file size.

That's the MAX it'd be allowed to u/l. If the actual file size d/l is < selected, it should still stick to the seeding % in prefs (CB).

The screens & many other instances exactly like them, are fact. That's what it IS doing, after downloads are COMPLETE. And it should NOT be doing that. There's an easy way to fix it.

ciaobaby - I really don't mean to be rude, but some of your comments (like last reply) are so far off topic & completely disregarding what I wrote; the facts & ACTUAL circumstances I presented, it's almost impossible to respond. It's like we're not in the same conversation.

AGAIN - the seed ratio (or volume) - as you said earlier, works off actual downloaded volume - NOT what's AVAILABLE to d/l. Why would I be concerned about 4.9x GB that I DIDN'T select or d/l, to reach some seeding ratio?

How did you ever interpret anything I wrote as indicating I thought seeding volume / ratio should be applied to anything EXCEPT downloaded volume? For me, selected & downloaded volumes are almost always identical.

[DreadWingKnight]

I'll sum up the rejection of this in one short sentence.

WE CAN'T CONTROL SWARM CONDITIONS.