Greg Hazel

But what -kind- is it? Satellite? DSL? Cable? 3G?

New build: http://forum.utorrent.com/viewtopic.php?pid=377049#p377049 It should really fix the tracker "updating..." issue this time...

The logging build, or the regular build? While it's frozen, you could capture a crash dump and send it to me: In Vista, use Task Manager. Right-click the process and select the option to create a crash dump. In XP: ntsd.exe -p 4100 -e 4100 -c ".dump /mf c:\jit.dmp;q" where 4100 is the PID, and c:\jit.dmp is the resulting dump.

What build are you experiencing this on? 13485 certainly had this problem, 13559 should not...

Can you sample again? That really doesn't seem right... Maybe something else was happening on the network at the time? Are you setting rate limits? Try turning the rate limits off, sample that way too.

What kind of internet connection do you have? What is the ping time to google.com when uTorrent is not running? What about when it is running with uTP+TCP, and also when it is running with TCP only?

What about CPU usage of the logging build? Was that reasonable / improved? I guess the question is whether the logging build 13560 transfered at a slower rate than the non-logging build 13559.

Can you provide the feed where this occurs?

New build: http://forum.utorrent.com/viewtopic.php?pid=377049#p377049

Or maybe rss.dat, if they're being loaded from a feed. Can you show the modification times in the screenshot too?

That extra UDP traffic could be the DHT. Turn on net.calc_overhead as well, that should make uT more accurate.

Can you capture a Wireshark log of when that's happening?

Yes, it should, if there is a PTR record for that IP.

Please try 13520, which should generate "socket.log" and "utp.log". You don't need to run it for more than a minute or so once the transfer rates stabalize. Generate a pair of logs with uTP on, move them out of the way, and generate a second pair with uTP off. http://download.utorrent.com/beta/utorrent-1.9-alpha-13520.upx.exe

Same bug, it just happened to not crash. This is fixed.

Nice :-) I was wondering when the next alpha's/beta's would be comming. Confused. What is that supposed to be? UDP tracker capability, UDP hole punching or ...? Where is more info? Same here, more info please. Both can mean a lot of things. Sidenote; I didn't see any options in the Advanced Settings to control these functions. What is not in 1.9: UDP hole punching (yet?) UDP tracker What is in 1.9: uTP, the micro transport protocol. This UDP-based reliable transport is designed to minimize latency, but still maximize bandwidth when the latency is not excessive. We use this for communication between peers instead of TCP, if both sides support it. In addition, we use information from this transport, if active, to control the transfer rate of TCP connections. This means uTorrent, when using uTP, should not kill your net connection - even if you do not set any rate limits. What was in 1.8.1: uTP, but connection attempts were not initiated by default, and there was no control over TCP as described above. You can enable it, but likely you will see the uTP connections not transfering much data, because they are pushed out of the way by TCP. What this means for rate control: You are still free to set rate limits and use external limiters. The "Automatic upload rate" control is flawed enough for most people that it will likely be removed once uTP is well tested and deployed, since it entirely supercedes that feature.

30 seconds.

Not true. UDP trackers are unrealted to uTP.

Fixed, thanks!

Can you capture a wireshark log of uTorrent not working, then capture another log of Deluge working?

-1 isn't really a valid number. This happens to pick a very very large number, as you see.

PM is fine.

Well, "Connection closed" means the other side thought it was appropriate to close the connection. If you want to send me the torrent, I can verify that this is because they see that you are a seed, and are not downloading, so they disconnect.

Turn on Disconnect logging. What does it say when it disconnects from each peer?

Fixed. This was an issue with leading zeros in an IP address (like 082.x.y.z). Thanks!