Archived

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

Firon

µTorrent 2.0 released

Recommended Posts

How is it possible that I can see IPv6 peers connected through PEX (X Flag) on private torrent?

privatepex.th.png

Share this post


Link to post
Share on other sites

The source is a bit of a misnomer. What this probably means is that you connected to a peer over their IPv4 address and in the handshake they told you their IPv6 address. For some reason the IPv4 connection was lost, but later uT was able to connect to their IPv6 address.

Nothing to worry about.

Share this post


Link to post
Share on other sites

No problems here, I'd just like to push for a future option of not using trackers. For instance by either an option that disables tracker support in the client or a setting that automatically removes trackers in newly loaded torrents. Whatever method would seem to be doable within the not too distant future. :)

Share this post


Link to post
Share on other sites
Greg:

in the handshake they told you their IPv6 address

if it's possible to still remember the IP4 address, and show the "country flag" and maybe the IP4 address as well for IPV6 peers - it can be nice.

Share this post


Link to post
Share on other sites

Minor typo:

-- 2010-1-25: Version 2.0 RC5 (build 17920)

- Change: update TCP/IP overhead estimation

- Fix: handle wrapping in uTP timestamps

- Fix: Crash in setup dialog when dialog is exited before server list is downloaded.

For the date, should be 2010-01-25 (Just for consistency)

Thanks for the update.

Share this post


Link to post
Share on other sites

Nice fix of the overhead calculation. Both limiters work fine .

Issues that still exist in RC5:

- upload speed - does not comply with external tools measurement

- calc_overhead - TRUE seems to still NOT be set by default (as previous version)

- color scheme legend is needed for the speed graph (payload/overhead)

- speeds - numbers better be reverted back to show full speed (for calc_overhead =TRUE). They seem like not complying to the limiters on the status bar.

Share this post


Link to post
Share on other sites

It seems that download overhead is now (RC5) being overestimated. Both an outside traffic monitoring program and my ISP statistics server show average download during the day about 4.1 kbytes/s, while utorrent considers download overhead to be about 5 kbytes/s.

Upload overhead, on the other hand, still seems to be underestimated - average up speed during the day according to ISP traffic usage statistics was around 97.8 kbytes/s, while average up speed during the same day according to utorrent was 88.6+-0.3 kbytes/s, which makes upload overhead around 9 kbytes/s. And utorrent says that it is hardly higher than 4 kbytes/s.

(As can be seen on the pic below)

utorrenti.th.png

Programs other than utorrent are unlikely to have affected the statistics much.

Share this post


Link to post
Share on other sites

I'm not sure I can see "your" 5KB DL , but 0.9K difference sounds quite good to me... :P

(and I didn't understand your UL related data.)

Share this post


Link to post
Share on other sites

Sorry, but that really isn't reliable enough information to act on. Any and all use of your connection can and will generate traffic in both directions. so unless you were exclusively using uTorrent and absolutely nothing else (and I mean nothing, not even an IM app) during the whole duration of your test, it's completely meaningless.

Anyway, this RC will very likely be the final one, as all remaining issues seem to be resolved. Hopefully by the end of the week we'll rebadge it as final.

Share this post


Link to post
Share on other sites

@Firon: "Anyway, this RC will very likely be the final one, as all remaining issues seem to be resolved. Hopefully by the end of the week we'll rebadge it as final."

This is one of the best news of this year. :-)

Many thanks for all involved.

Share this post


Link to post
Share on other sites

RC5 not responding after:

1. I captured tcp port in http-server

2. Start uTorrent. Of course, red symbol of connection.

3. Close http-server

4. Click on red symbol in uTorrent

5. Save&Close(port not changed, Automatic port mapping checked).

P.S. this is very bad, that "Kill process" not killing uTorrent. And uTorrent still visible in process list after logoff - logon. Windows 7 x64.

Share this post


Link to post
Share on other sites

@agmt "P.S. this is very bad, that "Kill process" not killing uTorrent. And uTorrent still visible in process list after logoff - logon. Windows 7 x64"

i heve the same problem since first versions of utorrent 2

Share this post


Link to post
Share on other sites

I've had the same problem when closing uTorrent (also on Windows 7 x64). I usually have to restart for it to stop showing up in the task manager.

Also, I upgraded to the RC 5 build today and now it says listening port error. Does this actually mean anything? My network is configured correctly and it has always told me the port is open in previous versions.

Share this post


Link to post
Share on other sites

Looking at the changelog doesn't really give a clue as to why this started happening again, but here goes:

RC 5 seems to have reintroduced a problem with uTP while uploading. When seeding at a high speed the connection will rapidly slow down when a peer using uTP connects. This happened with 1.8.x but was fixed in RC 3 and RC 4.

Changing bt.transp_disposition from the default 15 to 5 fixes the problem, but I thought you'd like to know anyway.

Share this post


Link to post
Share on other sites

FYI, I am running Windows 7 x64 and am not experiencing any problem with uTorrent obeying a "Kill Pocess" command in Process Explorer (or Task Manager) or being reported as running after I close the program.

Share this post


Link to post
Share on other sites

It still did that for me as of RC3 (where it was supposed to be fixed), haven't tried since then but looks like it's still the same problem Win7 x64 also.

Share this post


Link to post
Share on other sites

I have a somewhat serious issue.

I have a *.torrent file. I made 'Force Re-check' on a directory, which has some files as symbolic links (I have Win7 x64 which supports this), and successfully started seeding.

BUG: After each restart of uTorrent, this torrent is marked with 'Error: Invalid download state, try resuming'.

After choosing 'Force start' or just 'Start', it's state changes to 'Error: Files missing from job. Please, recheck.'

After rechecking it starts to seed again just fine.

Share this post


Link to post
Share on other sites

"open containing folder" on a torrent task, that is missing the torrent file (exidentally erased) - results in "open"ing the downloaded file itself. Since the file name and location IS known - uT should easily open the folder as well.

Also the "open file" menu operation is grayed/disabled, and as we can see - can be enabled.

Share this post


Link to post
Share on other sites

I'm been running V2, keeping up with the betas and RC's - on RC5 now. The total peer count reported in the upper window is still a much larger number than even the sum of the peers reported by individual trackers/dht etc in the lower window. Not a biggie, but not an inconsistency that I saw in v1.8x.

Share this post


Link to post
Share on other sites

Some UDP trackers report bogus numbers, so that throws off the peer numbers. 1.8.x did not support UDP trackers, but 2.0 does.

Share this post


Link to post
Share on other sites

but... eventually, uTorrent loads the actual peers' list from them, right ? so why not just count them and put the exact numbers in the trackers tab instead of the reported numbers ? at least for UDP trackers ?

Share this post


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