µTorrent 1.7.2 released

[Honeyfrog]

There was never an actual bug, just a new feature that freaked out some paranoid people. The feature is now off for private torrents.

[slipstream]

Huh. Why *paranoid*? Better call it *greedy* =) And actually a bug - since any kind of discovery except tracker must be disabled for private torrents.

[siin]

The feature is now off for private torrents.

meaning?

need to download the same ver again?

or to change it myself? (where and how?)

and if i do it, is the trackers will accept it and 'mark' my client as good?

[slipstream]

siin,

Did you actually read the announcement you've quoted? %)

Due to a bug in µTorrent version 1.7 and in 1.7.1, this client has been banned from the site. Please download 1.7.2 and use that instead.

Autoupdating your version of utorrent to 1.7.2 version is enough.

[siin]

Autoupdating your version of utorrent to 1.7.2 version is enough.

im using ver 1.7.2.

there is more:

2007-07-31

µtorrent 1.7.1 + 1.7.2 banned nævnte client er blevet banned fordi den sender forkerte data til trackeren. Dem som anvender den risikerer ban..

Please be adviced that above client has been banned due to false reporting to the tracker. Those who continue using this client risc ban too....

they add ver 1.7.2 too.

anyhow, is there bug fix release for this problem? or going to fix it?

[dAbReAkA]

human stupidity cannot be fixed

[slipstream]

they add ver 1.7.2 too.

Ah. Then it cannot be helped so far.

Most probably they mean that behaviour of not including the hashfailed downloads into stats. Follow this thread if interested - http://forum.utorrent.com/viewtopic.php?pid=264688#p264688

[siin]

well, it must be fix inside the client. (formal fixed release)

because, no private site will check every client to see if it fix.

[utorrentLover]

siin,i dont know what tracker u using but almost every site are allowed to use 1.7.2..and there is no bug in 172..cheers

[siin]

well, u can see here: http://nordic-t.org/index.php

and here too: http://www.torrent-damage.net/index.php

i cant cover all site who post same announcement.

but it's a broblem that the programer need to refer to. (?)

[DreadWingKnight]

Your second link grants access to 1.7.2

Obviously they don't see any problem (because there is none)

[siin]

i think it's one of 2 options:1. i think there is a problem when there is not.

2. u dont understand that the user who use this ver are in a big problem = bann.

what they (me too) should do? say to the owner of the site to ignore it, just like that?

[DreadWingKnight]

3> The tracker administrators who are still banning uT are thinking out of their ass.

If they won't give real proof of a problem, they don't deserve your traffic.

[usucdik]

I just started using the new version yesterday, and added torrents today. Some torrents were a bit messy with a ton of old trackers so I decided to clean it up, and at one point after editing the list and hitting OK the torrent COMPLETELY DISCONNECTED from every peer, halting the nice download stride to nothing.

What gives? It started downloading again a little while later, but why is it screwing with the peers when I touch the tracker list?

[Switeck]

When you edit the tracker list, µTorrent now disconnects (and hopefully reconnects) with peers and seeds on that torrent to prevent ratio cheating problems...which might also cause your ratios to be misreported (for better or worse!) to private trackers.

It shouldn't be a terrible problem unless you're "constantly" editing the tracker list.

[dAbReAkA]

shouldnt it clear the peer list? it's just disconnecting now but keeps them in the peer list and connects back again to the same peers..

[slipstream]

When you edit the tracker list, µTorrent now disconnects (and hopefully reconnects) with peers and seeds on that torrent to prevent ratio cheating problems...which might also cause your ratios to be misreported (for better or worse!) to private trackers.

How would that prevent ratio cheating problems if utorrent doesn't clear the peer list? Quite the contrary µTorrent is an ultimate cheater tool (which was also recently discussed on #utorrent) - one can just remove tracker url and leech the torrent in trackerless mode from the same peers/seeds.

[dAbReAkA]

even if it clears the peer list it would be the same.. other people have your IP address and will try to reconnect to u once u're gone..

[ICleolion]

What utorrent should do is if no trackers exist, then it should clear its peer list and only accept connections from DHT peers (not understanding all the handshake messages, etc, i'm not sure if this is possible, if it isnt then stop reading ). This way private torrents wudnt be ghost leeched because DHT wud be disabled. Again if only one of the trackers is removed from lets say a list of 3 trackers. Then utorrent shud stop the torrent, clear its peer list, restart the torrent and grab a fresh peer set from the remaining two trackers.

[slipstream]

What utorrent should do is if no trackers exist, then it should [..]

Exactly that check wouldn't help if private tracker url was not removed but tampered instead.

[usucdik]

This is starting to sound counterproductive to the main purpose of sharing in the first place.

Concerning what I brought up, I still don't understand why it waits a while before connecting to people again. I tried updating the trackers and whatever, but it just sits there and does nothing until it feels like moving again a minute later.

[Switeck]

Well, I can't say the policy is either a GOOD idea...or one that even works.

Disconnecting peers/seeds to prevent "cheating" may be a noble goal, but it fails in many ways due to overlooking that many peers/seeds will just reconnect to you quickly even if you clear your peer list.

I wouldn't mind if this behavior were scrapped completely, preferably on ALL torrents...but at the least on torrents that allow DHT and/or peer exchange. (In short, on non-private torrents.)

And for private torrents, this policy NEEDS to be improved or it's just a worthlessly bad idea.

[amc1]

Switeck - Azureus has been doing the same thing (dropping peer connections and "forgetting" saved peer connections) for private torrents since 2.5.0.4. I think it is a good idea, although it is limited in its effectiveness.

What would be better is if there was a mechanism for clients to communicate with trackers to find out if the peer that they are connected to (which may have connected to them) is "valid" or not. But to do that, you'd need trackers which would support such a scheme. And for trackers to support such a scheme, you'd need clients written which support the functionality...

It'd also help if those tracker admins which request such functionality would get round to testing it when the BT client writers actually write the functionality for them... they know who they are.

[Switeck]

It is unnecessary and unhelpful though for public (DHT-enabled) torrents to behave this way.

[Honeyfrog]

I, for one, am more that a little tired of watching developers asked to devote a lot of time to kissing the toes of, er, meeting the increasingly arcane requirements of insular private sites whose collective membership constitutes a miniscule fraction of all file-sharers.

Bittorrent is about sharing files, not policing them. These other people should stick to IRC and similar mechanisms for exchanging data among limited numbers of recipients; their speeds will be higher and their security tighter.

Disconnecting peers/seeds to prevent "cheating" may be a noble goal, but it fails in many ways due to overlooking that many peers/seeds will just reconnect to you quickly even if you clear your peer list.

That is exactly what they'll do -- and they'll be first in line to grab a fresh piece as new-connectees, just as if they were disconnect/reconnect-abusing BitComets raping an initial-seed.