geezer

I'm using an external Seagate 300 Gig drive (reformatted to NTFS) on my notebook and haven't had any problems. Does switching back to 1.5 really make the problem go away for sure? I.e., are you sure it's something to do with µTorrent?

I have bad news.... All torrents which I downloaded with recent beta versions of µTorrent *prior* to 427 fail a "force re-check". Since I was still seeding these with 427 it means that ***I*** have been the source of hash fails for other peers downloading these torrents. So...................this means everyone (EVERYONE) who has been using any beta version of µTorrent prior to 427 MUST stop all their torrents and do a force recheck on every one of them or you will continue to "poison" the torrents you are seeding (or still downloading...see next paragraph). This also applies to any extremely slow torrents you initially started downloading with a previous beta version and are still downloading with 427. I had one of those too and its "done" percentage was reduced when I did a "force re-check" on it. This is why there have been several previous posts (from Firon and Boo, I believe) recommending that everyone stop and "force re-check" all their torrents. I think the problem has been known for a while now but no one has fully explained it.

Potentially idiotic question (sorry!): Does this only apply to people who have overriden the default number of half-open (pending) connections in µTorrent? I thought the default prevented µTorrent from hitting the max of 10, making it unnecessary to patch. Is LvlLord's patch optional or mandatory when using µTorrent's default configuration?

If the port column is not shown in the peer list, right-click on the header and check "port". If the port is blank for a particular peer, it means we don't know the peer's listening port yet because the peer connected to us and we haven't learned its listening port through some other mechanism like the tracker's peer list yet.

skynetman and Stone are right but what they don't realize is the only solution to the problem is for the default for outgoing connections to change from "disabled" to "enabled". No other scheme will work without giving away that it is a BT connection. The client which initiates a BT connection speaks first. If it speaks without encryption, the ISP starts shaping. Game over. ISP wins.

Build 418 is available: --- 2006-02-04: Version 1.4.1-beta (build 418) - Change: Optimizations to piecepicker algorithm - Fix: Encryption didn't trigger legacy mode properly - Fix: Deleting from RSS history forgot about sorting

Just guessing...maybe it puts the torrent at position 1 in the download queue rather than adding it to the end. The download queue position is indicated in the "#" column.

I bet I know what flag K is. I bet X has been changed to K so that X can be used for peer exchange. Have I guessed correctly?

Dumb question....what does K mean in the flags column? Peer exchange? Encryption? The strange thing is I'm seeing it from a mainline peer so I wouldn't think it was either PEX or PHE. Oh, I've also got a peer with a completely blank client column. Stealth client?

The main overhead is when you try to establish an encrypted outgoing connection but the peer you are connecting to doesn't support it. I originally imagined the handshake would fail very quickly and immediately fall back to the traditional protocol. That's not how it works. There is a significant delay before the connection is closed and retried without encryption. So if you are in a swarm with a bunch of other clients which don't support encryption, it will take you a good while to connect to them and start exchanging data. At least that's how I interpreted what I saw when I tried it. The ideal candidates for testing it out would be Shaw customers in Canada. From what I've heard they are severely shaped. But they gotta find some torrents populated with other people running the beta in order to derive any benefit.

That's already how it works. The only thing the settings control is whether it attempts it on outgoing connections and whether it is mandatory. Incoming encryption is always accepted (provided the implementation is compatible, of course).

If I don't think I'm being shaped, how dumb is it to go ahead and enable handshake encryption (with fallback)? Does handshake fallback add a lot of overhead? How effective is handshake-only encryption? Can some/most ISPs already spot the other protocol messages?

In the logger window, the "Banned" messages have boxes (placeholders for unprintable characters) rather than IP addresses after them. I'm running build 398.

In case any newcomers are interested, I've updated my RSS instructions to reflect the fact that wildcards (*) are now supported in Favorites filters. Please let me know if I've made any mistakes so I can update the post. Thanks! http://forum.utorrent.com/viewtopic.php?pid=36682#p36682

Cool. Splats are working. You can match on something like *h264* now. Thanks!!!