Jump to content

µTorrent 2.0.3 released


Recommended Posts

other Bug as well Update does not wait long enough to exit throws up an error saying utorrent is still open (needs to wait upto 30-60 secs) utorrent is waiting for connections to be fully exited or the big 173gb torrent i have here is holding utorrent up when it should not be (torrent it self is complete but running)

it still updates thought (as i can see overhead an UTP have been moved)

Default should be ask unless you have picked not to show download location

UTP does not throttle enough so UTP limit has to be ticked as well

Link to comment
Share on other sites

  • Replies 294
  • Created
  • Last Reply

Top Posters In This Topic

Yet another bug, related to update (that you can also call a missing feature), is that the updater does NOT backup the old exe (and maybe the .dat files as well) BEFORE he download/replace with the new one :(

Link to comment
Share on other sites

+1 robertltux

Now when we download torrent, it just downloads the files to the folder that is set rather than creating a new folder in the folder that is set and putting the files in that new folder

Edit: I think I just experienced a bug. I had this old video in my downloads folder but i was downloading a new video with utorrent. Then i deleted the old video and halfway through the download of my new video, I tried to play it but it showed my old video instead...

Edit: Ok so i tried to remove the torrent completely using the remove and delete torrent + data option but instead of just deleting the torrent and it's data it removed the entire downloads folder. The only file inside the downloads folder was the torrent

Link to comment
Share on other sites

Now that I've read this thread and understand the new behaviors, I like them.

The new default download location is the system download folder; which has a default of %userprofile%\Downloads (for me on 7)

I'm assuming the new linux builds will also be using the similar XDG paths -- /home/<username>/Downloads on ubuntu, for instance. (And please please please use the modern ~/.config/utorrent/ because folders like ~/.utorrent/ are ugly & deprecated!)

If I don't have a download location set in the preferences, and both Directories->"Always show dialog on manual add" and UI Settings->"Show a window that displays the files inside the torrent" disabled, They're dumped in my profile download folder, which I don't want. (I boot 7 from a 32GB VHD file, as such I keep as much as possible out of my profile using Folder Redirection.)

If I do have a default download location set, but neither tickbox is set, I get the behavior I wish; No dialog and dumped to H:\UserData\Downloads\ on the local 2TB drive.

From there, ticking "Show a window that displays the files inside the torrent", and clicking a torrent in firefox does not have the behavior I expect: The torrent-contents selector dialog to show up with the H:\ path prepopulated. Instead, the file is silently added, but to the preselected H: path instead of the profile download folder, which I suppose is correct, just a bit odd.

Alternatively, unticking that, and ticking "Always show dialog on manual add", and clicking a torrent has a different behavior: A destination path fileselector window is opened, with the *last selected path* prepopulated. (In my case, it was H:\UserData\Downloads\Ubuntu\10.04\)

It is only when all three are enabled that I get the behavior I expected, the torrent-contents selector with the preselected default download path.

While this is mostly understandable; it is confusing and requires the user to play with the options to discover the behavior they wish. I applaud the configurability, though, each option is useful in it's own way and will satisfy most users if they're properly informed of what they get from each option.

Hope this verbose explanation of the behaviors helps others understand the relation of the options.

Link to comment
Share on other sites

Bug: uTP download speed limiter is mis-behaving:

1) bandwidth->apply rate limit to transport overhead - checked

2) bandwidth->apply rate limit to uTP - checked

3) bt.transp_dispsition = 26 (uTP only)

Under those conditions:

a. when ONLY setting individual torrent DL limit - it does not obey #1 (overhead is over the limit). btw, this applies to TCP as well.

b. when ONLY setting global DL limit - it fluctuate under the the limit (about ~1-5% below)

Global limiter - might be adjusted a bit, and individual torrents' limit should also obey #1, unless you like to add another control for uTP limiter inside it.


Link to comment
Share on other sites

@lostinlodos: could you post a screenshot of your speed graph showing the rate limit being exceeded? It could be local peers as well, which by default are excluded from the rate limit.

@Drazick: This bug has been fixed and will be in the next 2.0.3 beta release

@Rafi: I believe this behavior has been around ever since calc_overhead was introduced. If I'm not mistaken the same issue occurs with TCP as well. I'll see if there is an easy fix.

Link to comment
Share on other sites

As to the experiment with not rate limiting uTP by default, here's some of our reasoning. I'm very interested if anyone has a good (or better) solution to this problem. Obviously excluding uTP from the rate limiting didn't work as well as we expected.

The problem is that a very significant portion of uTorrent users set their upload rate limit so low that their download speed suffers from it. In 2.0.1, we enabled calc_overhead by default, which should give people a faster download rate if the upload rate limit is set correctly, instead people were seeing slower download rates.

The reason for this is that their upload rate limits are set so low that not even the ACK traffic caused by their download would fit within it. The purpose of calc overhead is to let people set the upload rate limit much closer to their actual capacity, without having the ACK traffic make them exceed it. It seems that people's upload rate limits are already set low enough to compensate for this, so changing the default for calc_overhead would only make sense by also increase people's upload rate limits. The latter is obviously quite intrusive.

The reasoning for lifting the rate limit on uTP by default was to take a step back and looking at why people set upload rate limits in the first place. The main purpose of upload rate limits is to make your modem not be flooded, and your internet becoming painfully slow. Other reasons are, if you have a metered connection, to not eat it all up too quickly. We already added the "Transfer cap" for this latter case (maybe we haven't done a very good job advertising it). Since uTP isn't supposed to have the issue of filling up your router's or modem's send buffer, we figured that rate limiting it isn't very important. (there's a lot of evidence that it works, even though it might still have some problems in certain cases, please let us know if it doesn't work as intended for you!).

Other reasons to rate limit might be to ease the load on your hard drive and other more power-user sort of things. We figured that a checkbox would be easy enough to find if your computer savvy.

So, currently we're in the situation where we rate limit uTP (and TCP) way lower than necessary, and the overall performance of bittorrent swarms are lower than what it could be. lifting the rate limit on uTP was supposed to help, but it didn't seem to. Maybe we can make the settings pane easier to use and explain some of these issues?

Link to comment
Share on other sites

@Rafi: Regarding the TCP graphs. The idea was that whenever uTP traffic was excluded from the rate limiter, the graph would not necessarily align with the limit anymore. I added the TCP graphs so that you could tell that at least the TCP traffic was limited by it. It seems to work fine for me, I just have to make sure I have some active TCP peers (by disabling uTP for instance)

Link to comment
Share on other sites

arvid: @Rafi: ... If I'm not mistaken the same issue occurs with TCP as well. I'll see if there is an easy fix.

It does. I wrote it in my post.

...It seems to work fine for me, I just have to make sure I have some active TCP peers (by disabling uTP for instance)

Fine, just that it doesn't work at all for me... simply - no plots at all. If someone (except you...) can post a screen-shot (on XP) - it will be nice. and I have sent you my settings file, you can try and see for yourself which setting prevents it (I have no time to check them one by one... and they are not all defaults).

edit: found the bug: setting bt.tcp_rate_control = flase hide the graphs and show the legened. It shouldn't hide the graphs

Link to comment
Share on other sites

Benefit is enhanced security. And sorry, but such obsession with exe size is just stupid. Shouldn't we revert to 1.5.0 because it's half the size of 2.0.3? exe grows bigger with each release and uT already has alot of features that only few people use, but somehow it's worth those few k that accumulates with each build.

Oh, and how about stripping those 5k of digital sign in the end of file? There is definitely no benefit for uT work from them.

Link to comment
Share on other sites

When it comes to size, it's _really_ hard to justify adding something as useless as "apps" in uT 2.2 (the responses to the thread says it all) and not justify a few extra kB for proper ASLR.

Especially in today's world that torrenters are under fire more and more from these agencies, you could find yourself down the line with a secretly shared exploit that ASLR could have prevented, then the new headline in Germany/France will read dump uTorrent at all costs.

My 2c.

Link to comment
Share on other sites

I believe there is a new bug introduced in the 2.0.3 beta which wasn't there in the last stable build:

I have (and always had) a Windows 7 task scheduled for around 2AM to run the following:

1) Kill uTorrent process if up

2) Download some ipfilters etc.

3) Relaunch uTorrent minimized

I have the scheduled task set to "Run with highest privileges", as I don't want the Windows UAC to pop-up and stop the steps.

Since the new betas, although the above steps work fine, and uTorrent is relaunch, if I click on the uTorrent button in the Windows launch bar, the following error is popped:

"It seems uTorrent is already running, but not responding"

I AM however able to right click in the *tray* icon (note, not launch bar), and select "Hide/Show uTorrent", and that will result in uTorrent to correctly be brought up to front.

In the previous (stable) builds, clicking on the uTorrent icon in the launch bar had the same result if the application was already running.

Also note, that I made note of the "Run with highest privileges" above, because that may be the item of importance.

If I start uTorrent manually, minimize it, then click on the uTorrent icon in the launch bar, it does come to view!

Something has changed in the beta that broke the above for the scheduled task with "highest privileges" setting.

Link to comment
Share on other sites

If you run the second instance of µTorrent elevated ("Run as Administrator"), it should trigger the first one correctly.

This may or may not be by design (although I don't see it in the changelog), but you probably shouldn't be running µTorrent elevated to begin with - is there some specific reason you are doing so?

Link to comment
Share on other sites


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

  • Create New...