Jump to content

µTorrent 2.0 released


Firon

Recommended Posts

  • Replies 659
  • Created
  • Last Reply

Top Posters In This Topic

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.

Link to comment
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. :)

Link to comment
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.

Link to comment
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.

Link to comment
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.

Link to comment
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.

Link to comment
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.

Link to comment
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.

Link to comment
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.

Link to comment
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.

Link to comment
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.

Link to comment
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.

Link to comment
Share on other sites

Archived

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


×
×
  • Create New...