µTorrent 2.2.1 released

[Switeck]

Well, I would like this feature to be disabled (or by default) before I upgrade

It's not uTorrent, as DWK was hinting at, it's almost certainly SOMETHING ELSE.

You mean the thing where something on your computer interferes with uTorrent writing the resume state properly?

You'll need to do some troubleshooting to find what hostile software on your computer is preventing uTorrent from running correctly.

[hermanm]

My µTorrent notification for 2.2.1 beta build 23551 shows the HTML explicitly instead of a clickable link with blue underlined text.

[Firon]

are you on windows 2000? it only works correctly on XP and up.

[123459]

Firon, http://forum.utorrent.com/viewtopic.php?pid=547024 - please, help

[drizzle]

I, also, would like some news/status on the PEX flood ban issue.

BTW, it isn't just large swarms: 1 seed, 13 peers, and 2.0.4 banned a peer.

[Firon]

Just how often are you seeing it? We added some asserts in the client to see if 2.2.1 is sending out PEX messages more than it should.

The check is whether or not a PEX message was sent within the last 10 seconds (the spec says you're only supposed to do it once every 60 seconds).

[Switeck]

What about if a seed/peer quickly disconnects and reconnects?

Couldn't it (foolishly?) send a new PEX message?

[GTHK]

Being able to control the graph scale would make things more useful, It's a tad difficult to use the new utp delay graphing when max delay spikes over 4s leave the average delay little mounds at the bottom.

Making all files .!ut before finishing checking is pretty annoying.

[drizzle]

Just how often are you seeing it?

Not sure how you define 'often', but it seems some number get banned with nearly every public torrent I start.

Disabling PEX (and resetting the bans) picks up the peers.

As anecdotal (not statistical) observations - saw 'BitTorrent 7.2' getting banned a lot in one swarm, and 'Transmission 1.2' was the banned client in the small swarm mentioned above. I'd have to collect log files to see if that was a fluke or a pattern, but the bans I'm seeing "feel" excessive.

[Step]

Got this message almost every time when trying to add torrent from explorer by double clicking it's icon.

However uTorrent works normally and I can add it through menu or toolbar.

OS: Windows 7 Home Basic x64

[Firon]

Do not run uTorrent as admin.

[rafi]

because ?...

[Firon]

Because bad things happen. Like the above. Non-privileged processes can't really talk to privileged processes.

[rafi]

Ah... yeah.. I remember reading about it the enhanced uT 2.2.1 user's guide... And why didn't I hear of such limitation in any other application till now ?...

You might want to not call it operator error but a software related one. And if, for any bizarre reason - it HAS to be so, just issue a warning at uT startup and don't let it tun till the user behaves correctly as you see it... ;P

[Firon]

It's actually just a weird Windows limitation when UAC is turned on.

[Step]

hmm, also, never run uTorrent from applications runned as admin, e.g. TotalCommander

[rafi]

any other limitations ?... It is so difficult to just detect those situations in uT and abort the run ?

[fowl]

any other limitations ?... tongue It is so difficult to just detect those situations in uT and abort the run ? sad

It does... hence the error. Or am I missing something?

(the elevated instance could give permission for non-elevated instances to talk to it, but it's a lot of stuffing around in fairly sensitive areas. Apps like µTorrent should be run with as few privileges as possible anyway.

[drizzle]

Just how often are you seeing it?

more info - started up two torrents, with logging to a file.

bans extracted from log (edited to remove torrent names)

for torrent1, peer list has 93 entries, 15 banned

for torrent2, peer list has 21 entries, 3 banned

My gut tells me this is a 'flood detection' issue, not a 'faulty client' issue.

[2010-12-12 09:24:36] 118.251.34.231:39208 [uTP](torrent1): [µTorrent 2.2 (80.2)]: Disconnect: PEX message flood

[2010-12-12 09:26:14] 201.47.22.237:33905 [uTP](torrent2): [µTorrent 2.0.2 (100.0)]: Disconnect: PEX message flood

[2010-12-12 09:26:43] 76.28.24.29:2874 [uTP](torrent1): [µTorrent 2.0.2 (62.1)]: Disconnect: PEX message flood

[2010-12-12 09:26:44] 220.253.150.238:60058 [uTP](torrent1): [µTorrent 2.2 (3.5)]: Disconnect: PEX message flood

[2010-12-12 09:26:51] 86.164.91.168:42829 [uTP](torrent1): [µTorrent 2.0.4 (100.0)]: Disconnect: PEX message flood

[2010-12-12 09:27:16] 77.246.69.246:53896 [uTP](torrent2): [µTorrent 2.2 (67.9)]: Disconnect: PEX message flood

[2010-12-12 09:27:22] 86.51.59.189:1026 [uTP](torrent1): [µTorrent 2.2.1 (46.4)]: Disconnect: PEX message flood

[2010-12-12 09:32:59] 212.242.247.99:28213 [uTP](torrent1): [µTorrent 2.0.1 (100.0)]: Disconnect: PEX message flood

[2010-12-12 09:38:31] 220.253.9.84:60058 [uTP](torrent1): [µTorrent 2.2 (3.8)]: Disconnect: PEX message flood

[2010-12-12 09:44:03] 59.95.51.169:19427 [uTP](torrent1): [µTorrent 2.0.4 (0.6)]: Disconnect: PEX message flood

[2010-12-12 09:44:44] 210.89.51.114:16930 [uTP](torrent1): [µTorrent 2.2 (3.8)]: Disconnect: PEX message flood

[2010-12-12 09:46:06] 94.59.204.241:42395 [uTP](torrent1): [µTorrent 2.0.1 (100.0)]: Disconnect: PEX message flood

[2010-12-12 09:48:43] 79.101.89.189:10032 [uTP](torrent1): [µTorrent 2.0.4 (12.5)]: Disconnect: PEX message flood

[2010-12-12 09:51:40] 86.136.240.165:11219 [uTP](torrent1): [µTorrent 2.2.1 (8.2)]: Disconnect: PEX message flood

[2010-12-12 10:08:25] 92.233.217.140:52555 [uTP](torrent1): [µTorrent 2.0.4 (87.6)]: Disconnect: PEX message flood

[2010-12-12 10:23:01] 195.241.26.137:43676 [uTP](torrent1): [bitTorrent 7.2 (77.4)]: Disconnect: PEX message flood

[2010-12-12 10:24:24] 117.192.177.206:41625 [uTP](torrent1): [µTorrent 2.2 (61.5)]: Disconnect: PEX message flood

[2010-12-12 10:30:27] 202.63.41.130:59254(torrent1): [Transmission 2.04 (100.0)]: Disconnect: PEX message flood

[2010-12-12 10:33:54] 77.98.165.246:37075(torrent1): [Azureus 4.5.1.0 (100.0)]: Disconnect: PEX message flood

[2010-12-12 10:40:13] 24.108.241.62:27837 [uTP](torrent1): [µTorrent 2.2 (5.5)]: Disconnect: PEX message flood

[2010-12-12 10:56:49] 86.175.26.75:15708(torrent1): [Azureus 4.5.0.4 (100.0)]: Disconnect: PEX message flood

[2010-12-12 11:19:54] 94.128.90.16:28913 [uTP](torrent1): [µTorrent 2.0.2 (100.0)]: Disconnect: PEX message flood

[2010-12-12 11:25:20] 188.4.229.124:49505(torrent2): [µTorrent 1.8.3 (100.0)]: Disconnect: PEX message flood

[2010-12-12 11:35:47] 89.43.152.14:35421(torrent1): [Azureus 4.5.1.0 (100.0)]: Disconnect: PEX message flood

[2010-12-12 11:47:39] 79.78.179.161:13932 [uTP](torrent1): [bitTorrent 7.2 (100.0)]: Disconnect: PEX message flood

[123459]

Please, change logic:

Alternate upload rate _when downloading_

Because if i want to remove limit - i must copy value from Alternate upload rate when NOT downloading to Maximum upload rate(or reenter them).

With changed logic, i must just uncheck checkbox.

[Ultima]

Your use case is atypical. I don't see why the logic should be completely changed for an atypical situation.

The logic as is works perfectly fine, and has worked for everyone else who's ever used it -- why should it be changed now because the inverted logic seems inconvenient to you? All you're requesting is for the logic to be inverted. That's as simply fixed as just inverting when you tick the box yourself. I don't see why it requires you to force everyone else to follow your use case -- not when the existing logic already satisfies other users.

If I've misunderstood, then please clarify exactly what you're expecting.

[123459]

Ultima

1) It is just logically incorrect: Maximum upload rate is a rate, that are maximal for the user - i.e. there is nothing more than that rate.

2)If user wants to revert changes, then he must restore old value to the Maximum upload rate AND uncheck checkbox. This is one more unnecessary operation.

3)Isn't this quite obvious?

[DreadWingKnight]

"When downloading"?

You are wanting a behavior that is backwards to what the dialog says and what the function does.

"Alternate upload rate when not downloading" (emphasis added) is what the dialog says.

The setting is there for people who want one upload rate while downloading (the first option without the checkbox) and another upload rate when there's no downloading going on, only seeding (the option with the checkbox)

[fatspirit]

Please return old relocate functionality back! Now I unable to seed almost identical multi-file torrents (identical files are located in one directory and different files are located in different directories).

[Firon]

You can still relocate individual files. Still, we're not changing relocate, though we might add a separate function to rename the child folder instead.