Jump to content

µTorrent 2.0.1 beta 18786


Recommended Posts

A minor GUI/tool-bar issue:

Tool-bar's "pause" button - will also resume a paused torrent. Was it designed that way ? if so - I suggest to change it's tool-tip/help to indicate it. if not - disable it when selecting paused torrent(s). Also , maybe modify the "start" tool-tip to "start/resume" ... or disable if when a paused torrent is selected.

Link to comment
Share on other sites

  • Replies 192
  • Created
  • Last Reply

Hey nice job with 2.0.1. Just some considerations:

Most of us don't use bandwidth limit or local peers. We don't need to keep looking at it all the time on the graph legend. So if these options are disabled/not used, hide them from graph.

I always keep uT displaying the download/upload graph. Please allow us to hide the graph legend.

Thank you.

Link to comment
Share on other sites


Please allow us to hide the graph legend.

@Seyss: in preferences->advanced->gui->

1. graph_legend - show/hide legends

2. transparent_graph_overhead = show semi-transparent legends

From my experience - better use FALSE for #2 to save 10% CPU ... :P They should either fix it or make FALSE the default...

@emc: I must say that I like this new "feature", cause you can see them much better that way... ;)

Link to comment
Share on other sites

Issues in build 18284 :

1. while uT keeps data+overhead under the global speed limits (calc_overhead=true), you forgot to do it that way also for limits you set per torrent/properties ... it now limits per the data speed, w/o takeing overhead into account.

2. in preferences->advanced->gui->transparent_graph_overhead = true causes ~10% CPU load (when the graph is being displayed). This should be set to default to FALSE or be fixed.

3. Connecting problem with uTP under the following scenario (XP, IPV6-torredo enabled):

- force starting a seed - torrent

- running a peer in another instance of uT, with different port (in uTP only , 10)

- "adding" the first seed (IP:port) to the peer

- downloading starts and finishes ok.

- stop the peer. deleting the data, re-checking the peer, and start again (same peers' list on both, shows IPV4 and IPV6 IPs)

- the seed will not let the peer connect again (loged error: "Disconnect: Not downloading")


- clear the peers' list of the seed

- the peer now connects fine.

This does not happen with TCP (5). The logs: http://pastebin.com/m5ee17b5e

I suggest to enhance the "get peer's list" funtion to show exact peer status for each (baned, inactivity timer, maybe other stats...)

general notes/issues :

A. having a few local peers, and disabling "limit local peer's bandwith" - not only lift the speed limit, but also disregard the # of upload slots per torrent for them. It this a bug a the design ?

Link to comment
Share on other sites

Can't say isp.bep22 works for me...

We have all required DNS records, retracker is hosted on my PC...

Here's nslookup, what BEP22 should do itself (some lines changed and/or omitted):

> 217.26.__._Name:    myhostname.itaec.ruAddress:  217.26.__._
> _bittorrent-tracker._tcp.itaec.ru_bittorrent-tracker._tcp.itaec.ru       SRV service location:          priority       = 5          weight         = 0          port           = 80          svr hostname   = retracker.local
> retracker.localretracker.local internet address = 217.26.__._

I stopped all torrents, then deleted manually added "retracker.local/announce' from several torrents and started them... Then, I expected to see those torrents to be announced to my retracker by BEP22, but that did not happen...

What I did wrong?..

Link to comment
Share on other sites

OK. Was copying some folders downloaded by utorrent, which I had removed from utorrent. They were still locked. Utorrent still running, so I closed it down, yet the folders are sill locked. Not only that, there are two invocations running, and when I try to terminate the (I have admin privs) the process, I get access denied.

Windows 7 Professional 64 bit

Link to comment
Share on other sites

Build 18284:

2 questions

1. I have my upload speed limited to 45KBytes/sec, of which 14 are being used for upload and 31.7 for OVERHEAD? Isn't there something wrong with that? Is there a setting I'm missing or something I should turn off?

2. Attempted limiting 4 downloading torrents to 5KBytes/sec upload speed, which produced the above mentioned totals, with most torrents only reaching a download speed of around 3.2KBytes/sec. These torrents have been running for an hour or so, and the graph is pretty consistent, so my question is why aren't these torrents reaching the specified 5KBytes/sec upload speed?

I'm concerned on why the upload overhead is SO high, when the download overhead appears pretty low in comparison (for example 738KByte/sec upload with 29.8KByte/sec upload overhead). This is problematic because it saturates my upload stream without being really able to upload much data (IE Overhead to Uploaded ratio is over 2:1).

If anyone can help reign in the overhead with either setting suggestions or maybe figuring out if this is a bug, it would be greatly appreciated.

Link to comment
Share on other sites

Firon, if you say its been like this for ages, then I'll let things be. One thing I still can't wrap my head around, why is the overhead in a 2:1 ratio to actual uploaded data? Seems incredibly high. Is there anything I can try to reduce it like limiting the number of connections, or some of the other advanced settings?

Link to comment
Share on other sites

Well, the numbers look a bit strange to me. Also you did not say what is your net.calc_overhead set to, or what's your max upload slots per torrent. If you'll look at my post - #31 - there is a also a bug that limits does not work properly on the per-torrent limit.

Putting all that aside, when using low UL limits the overhead is huge, since the packet sizes are now very small. I would leave only a 20/45K total limit. Another thing you can try first - is setting net.utp_initial_packet size to 8. But I'm not sure this is fully operational...

I agree that 31K overhead seems strange with 5K x 4 limits, but the "bug" of NOT limitting the overhead when you set per peer UL limit can explain it ... ;)

Link to comment
Share on other sites


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

  • Create New...