Archived

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

Firon

µTorrent 2.0.4 released

Recommended Posts

Same problem here,more than one torrent off the same private tracker will not start , If I go back to 2.0.3, works instantly.. Also using Windows 7 x64 and The Fixed Build 21586

Share this post


Link to post
Share on other sites

Build 21586: I've seen a few tracker timeouts here too, and also in one of the previous 2.04 builds (think it was 21515). They went away after a while. Only torrents I currently have are from private trackers, if that matters.

I really didn't pay much attention, since I thought they were just tracker glitches, but they might have been the same issue a couple of other people have reported.

Share this post


Link to post
Share on other sites
As I posted here 10 minutes ago - http://forum.utorrent.com/viewtopic.php?id=83092 - quoting myself:

After 2.0.4 came out we noticed that our tracker suddenly spiked the load from usual 25-30% to 100% load (that's 2 x Quad Core Xeons 2.4 GHz), announce started to get more requests by a factor of 10 if not even more. Future investigation showed (by logging requests and other activities) that all requests witch fail with an error like "Torrent is not registered with tracker" or 50x errors are repeated by the uTorrent instantly! I logged some ips requests to get detailed stats to comfirm that - clients where sending a request every second.

To completly confirm that, I just downloaded a torrent from my tracker and added it to the uTorrent. Because my tracker is now under extreme load I get 502 error and uTorrent just repeats the request instantly in a loop of "request => 50x => request => 50x => .....".

Please fix that ASAP.

I confirm Psihius's comments about the huge traffic spike hitting the trackers.

This is our traffic graph for the last days:

http://img717.imageshack.us/img717/9905/hwgraphphp.png

This aggregates both the front-end/web interface trafic and the back-end/tracker trefic. Blue is incoming, green is outgoing.

As you can see, we went from a regular, mostly upstream web host, to having the upstream comparable with the downstream because of the bogus requests. The incoming traffic trebled. The outgoing traffic increased moderately because it was high from the regular load (forums, torrent downloads etc.) and the reply from the tracker is very short: "HTTP/1.0 200 OK\r\n\r\nd14:failure reason20:unregistered torrente"

I went ballistic when I saw this, thought we were attacked :). A trafic dump showed allot of "unregistered torrent" queries, all coming from uTorrent 2.0.4 clients, and a Google search later here I am.

Fortunately, our tracker is not PHP based, but a much more capable compiled daemon, that can still handle the load with a ~ 15% CPU usage.

Share this post


Link to post
Share on other sites

Can't find any 21586 in last night's dump (good or bad). A new dump I've done just now shows only good requests from 21586. So it seems it's fixed, if only the users won't dismiss (yet another) update dialog.

Share this post


Link to post
Share on other sites

I had 21515 and now 21586 and the survey links are still here :(

============

-- 2010-08-26: Version 2.0.4 (build 21515)

- Fix: make survey links never show up on XP

- Fix: started and stopped events now correctly sent to torrents with multiple tracker tiers. ============

Share this post


Link to post
Share on other sites
and the survey links are still here

On XP / SP? ?

I simply don't understand this - how hard can it be to simply comment that whole code section in the client ? Stop messing with OS related conditional statements :( You fail ... :P

Share this post


Link to post
Share on other sites

I've just upgraded to v2.04 21586 and it seems ALOT slower than the previous v2.0.3 20664. I can't seem to connect to as many peers. I fired up v2.0.3 and everything is fine.

Share this post


Link to post
Share on other sites

Did some more testing w/ v2.04 21586. I HAD disabled bandwidth management uTP in v2.0.3 because it was slowing the torrents. It was a long running, 10GB torrent.

Anyhow, I enabled bandwidth management, which made it run faster again, and after about an hour or so, I again diabled bandwidth managent and everything is fine now.

I'm just wondering as to why I must start my torrents w/ bandwidth management enabled, & after awhile disable it to have good torrent performance which almost saturates my connection? Can others replicate this?

Share this post


Link to post
Share on other sites

I've stepped back to 2.0.3.21177 and it's solved all the problems of 2.0.4.21586. The afore-mentioned tracker problems, internet shutdowns... it's kind of a mess. One thing I noticed was if the torrent has the following tracker list (for example):

http://tracker.openbittorrent.com:80/announce

udp://tracker.openbittorrent.com:80/announce

udp://tracker.publicbt.com:80/announce

http://tracker.publicbt.com:80/announce

http://genesis.1337x.org:1337/announce

Then the only trackers that'll show up in uTorrent's tracker tab are:

http://tracker.openbittorrent.com:80/announce

udp://tracker.publicbt.com:80/announce

http://genesis.1337x.org:1337/announce

That is, the spaceless (same machine) trackers only show up as the first line in the group. They all show up (properly) in 2.0.3.

Share this post


Link to post
Share on other sites
Then the only trackers that'll show up in uTorrent's tracker tab are:

http://tracker.openbittorrent.com:80/announce

udp://tracker.publicbt.com:80/announce

http://genesis.1337x.org:1337/announce

That is, the spaceless (same machine) trackers only show up as the first line in the group. They all show up (properly) in 2.0.3.

That's working as designed in v2.0.4 -- trackers on the same tier should only show the active tracker from that tier in the tracker window/tab.

Torrents shouldn't be spamming updates to lots of trackers every time.

I've used v2.0.3 as well and it handles tracker display the same way as v2.0.4 in tracker window/tab.

Share this post


Link to post
Share on other sites
scrim:

Yes, XPsp3 with Zune theme from MS.

Tried it, and couldn't reproduce the issue...

Share this post


Link to post
Share on other sites
I've stepped back to 2.0.3.21177 and it's solved all the problems of 2.0.4.21586

And created the problem of you being wide open for the major exploit fixed in 2.0.4

i rather have a good old ver than a screwup latest ver........double stepped back to 1.8.5 17414 ver., until utp show it's promises. for now, it's crappy.

Share this post


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