Archived

This topic is now archived and is closed to further replies.

Firon

µTorrent 2.2.1 released

Recommended Posts

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. :(

Share this post


Link to post
Share on other sites

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

snagprogram0001.gif

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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).

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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

123ww.png

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

OS: Windows 7 Home Basic x64

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Ah... yeah.. I remember reading about it the enhanced uT 2.2.1 user's guide... :P 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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

Please, change logic:

Alternate upload rate _when downloading_

1886.png

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

"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)

Share this post


Link to post
Share on other sites

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).

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.