µTorrent 2.2.1 released

[AdamK]

I can confirm that uT was doing something' date=' shall we say ... inefficient when deleting files.[/quote']

Hello

Do you know if the code improvement will fix the issue about deleting large/huge files?

http://forum.utorrent.com/viewtopic.php?pid=422649#p422649 (SHFileOperation() in another thread)

Hi moogly,

If I understand the underlying cause of that issue correctly, this will help those cases.

Note that the file operation itself may still take a long time, but the UI will remain responsive. Please let us know what you see once the next 3.0 becomes available.

[iycgtptyarvg]

iycgtptyarvg, Zarggg, tanstaafl, mkk:

I can confirm that uT was doing something, shall we say ... inefficient when deleting files.

This has been addressed in builds after r24182, *in the 3.0 branch only*

The disk code has been improved greatly between the 2.2 and 3.0 series, and backporting this feature won't be trivial.

Adam

You saying it has been fixed is good enough for me. There's no need to back-port it and 'waste' time.

The next beta should hopefully resolve the tray icon problem on Windows startup.

That would really be great. Because it really is bothersome to go to Windows Explorer and find the uTorrent directory and start it again to get the window to pop up.

Thanks.

[Firon]

New build up! Check the first post and please give it a shot.

[Firon]

Since build 23551 gui_graph_overhead don't work. Always ON.

Fixed in 24217.

I've found bug in cache- if I set cache size to 2048 - it thinks that cache size==1

2.2.1 23984

Fixed in 24217 by capping the max cache size to 1500, since using 2GB of memory will cause a crash on a 32-bit app. The 64-bit version will have no such limit.

[Nefarious]

In build 24217 using the "open containing folder" feature by either double click or right click on the torrent goes to the first folder inside the main, but not to the main folder as it should. Doesn't happen in all torrents.

[Eluvatar]

In build 24217 using the "open containing folder" feature by either double click or right click on the torrent goes to the first folder inside the main, but not to the main folder as it should. Doesn't happen in all torrents.

yep I'v noticed that too, also it still seems to do some weird stuff with QtTabbar it opens the containing folder as a tab and then opens a new window in the right spot. weird

[TorrentDaddy]

FYI: Version 2.2.1 (Build 24217) I've only started build 24217 twice, but I have noticed that my DHT Nodes are running about 2/3rds less than the previous version (120 instead of the usual 330). My upload speed is also very sluggish, down by about 1/3rd, from 150kbps to 100kbps.

My line quality, speed and ping rates are all at their normal levels.

[rafi]

...

The disk code has been improved greatly between the 2.2 and 3.0 series, and backporting this feature won't be trivial.

Adam

So, why not make an effort to port it, and make 2.2x better ? After all - the code is there for the taking... and there is no rush with releasing 2.2.1 since 2.2 is out...

FYI: Version 2.2.1 (Build 24217) I've only started build 24217 twice, but I have noticed that my DHT Nodes are running about 2/3rds less than the previous version (120 instead of the usual 330). My upload speed is also very sluggish, down by about 1/3rd, from 150kbps to 100kbps.

My line quality, speed and ping rates are all at their normal levels.

My guess - it has to do with this:

- Change: only apply the port > 1023 for outgoing connection restriction for peers only hear about through the DHT

[TorrentDaddy]

That was my thought too Rafi.

[rafi]

I told them to leave those features to the 3.0 branch... No on e asked for them...

[Ultima]

Last I checked, devs didn't need users' permissions to work around exploits.

As for node counts being low... Are you really suggesting that 60+% of all peers (or just the peers accessible from known bootstrap nodes) are using ports < 1024? Seriously, I doubt it's related. Anecdotally, I just enabled DHT and µTorrent easily connected to 300+ nodes.

[rafi]

s/told/suggested/ ... and last I checked (plus from personal experience), users are using low service ports as a possible way to fight against ISP throttling...

And the last DDOS attack I had caused by BitTorrent net - was ... never ...

[Firon]

Except the possibility of doing it is very real and has been demonstrated to work.

[rafi]

How many attacks did you suffer ? or for that matter any one else you personally know of ? Or, do you have statistics on how many are being attacked each day ?

'Possibility'... meh...

[Zarggg]

By that logic, all "bad things" should be allowed based solely on the condition that they have not yet happened to you.

The devs are making the right decision here.

[rafi]

The principle might be right, but the way they go about it - is wrong.

0. this is like a 'DHT firewall' - designed to protect the user from the outside.

1. There is no proper user control over this specific feature . As I understand it - it is either enabled or everything (including previous service ports list) is disabled. This rule of disabling all low number ports should be controllable (check-box? advanced?) by itself.

2. Like a firewall - it should be enabled ONLY if the user desires , and regardless of the now defined service ports list . Now it's badly combined with it.

3. And the most important thing - it is invisible, and ON BY DEFAULT. The user simple do not know it's on. This is bad - not only because the user does not know of it (no visible indication), but because being the default, the whole network suffers. If I use a low port intentionally, I cannot connect via DHT to ANY uTorrent user now

So like any sane option, it should be:

- clearly visibly

- controlled separately like adding a <xxx into the current service posts list, or just a separate option with this rule in it

- disabled by default , so users CAN use it to protect themselves only if they wish to, and NOT have overall effect on the network

And - this feautre better go into 3.x line since it was in 2.2 in the first place, and 2.2.1 is basically a fixes-release to 2.2, not a base for experimental features... That's what I also told/suggested to the devs...

[Ultima]

I told them to leave those features to the 3.0 branch...

And - this feautre better go into 3.x line

Security isn't a feature.

this is basically a fixes-release to 2.2, not a base for experimental features

Yeah, they're fixing an exploit, so where's the contradiction?

- disabled by default , so users CAN use it to protect themselves only if they wish to, and NOT have overall effect on the network

That defeats the whole purpose. The exact reason why this exploit could be used is because it's possible by default. It was always possible to prevent if the user optionally edited bt.no_connect_to_services_list themselves. You're basically asking for the devs to revert the thing entirely, and to leave it that way.

[TorrentDaddy]

Last I checked, devs didn't need users' permissions to work around exploits.

As for node counts being low... Are you really suggesting that 60+% of all peers (or just the peers accessible from known bootstrap nodes) are using ports < 1024? Seriously, I doubt it's related. Anecdotally, I just enabled DHT and µTorrent easily connected to 300+ nodes.

It is possible that the files I was sharing were not in high demand, because right now I have finally connected to 333 nodes. HOWEVER, my upload speeds are collapsing when DHT goes into update, and what I mean by collapsing is that my upload speeds decrease by OVER 80% during the DHT 'update' process. These symptoms must be connected to this change somehow since these problems were not evidence in the prior Beta build.

Rafi is right, save it for 3.0! You had a perfectly working product in build '908.' Why tamper with perfection? These changes were not necessary IMO.

[rafi]

Did I mention experimental ?... I think I did ... That means the devs just code it, and we test it... Testing was never one of BT inc strong suits

@Ultima

1st-ly - I think it's not your (uT's...) place to decide for the "default" user if they need this "DHT Firewall" or not. Especially - if it might heart others that are on the same network.

Secondly - as I already mentioned, there might be "good" reasons to use low numbered ports, and ironically - those exact users, suffering from throttling are now the ones effected by your new network protection (not being able to use DHT.

And thirdly, to the practical point - what I requested/suggested as minimum was visibility and proper controllability to this feature (beside not being the default behavior). I'm sure you agree that those are qualities we want in such important Firewall-feature/option (as you didn't refer to those in your reply...) .

[Firon]

New 2.2.1 up. The infamous scam warning is finally gone. Also, we fixed a pretty major crash with open containing folder.

[bugmenot2]

utorrent icon not in system tray. this problem still exists.

its working fine when u install utorrent n use it for first time, then after restarting pc and using over time , it never appears in tray..

http://forum.utorrent.com/viewtopic.php?pid=559990#p559990

http://forum.utorrent.com/viewtopic.php?pid=558958#p558958

http://forum.utorrent.com/viewtopic.php?id=90952

http://forum.utorrent.com/viewtopic.php?id=90144 (main thread)

http://forum.utorrent.com/viewtopic.php?id=90136

all these threads report the same problem

[Nefarious]

Open containing folder in build 24266 is now going to the folder that has the torrent folder you're trying to open but not to the main torrent folder (ex. goes to "h:\torrents\" instead of "h:\torrents\torrentfolder" like it did before build24217).

[mike20021969]

utorrent icon not in system tray. this problem still exists.

its working fine when u install utorrent n use it for first time, then after restarting pc and using over time , it never appears in tray..

I can confirm this, too.

I'm running Windows XP Home Edition, Service Pack 3. AVG Free 9 and Zone Alarm Free Firewall running at system start up.

uTorrent version 2.2.1 build 24266.

P.S.: If I'm uploading, the icon in bottom right is almost always an orange triangle exclamation.

Only when I'm downloading does it becomes a green circle tick.

Is that how it should be?

[ChichipioWilson]

Open containing folder in build 24266 is now going to the folder that has the torrent folder you're trying to open but not to the main torrent folder (ex. goes to "h:\torrents\" instead of "h:\torrents\torrentfolder" like it did before build24217).

Hmmm… that doesn't happen to me. If I click on a multi-file torrent directly and choose "open containing folder" then yes, it goes to the parent folder (h:\torrents) in your example with \torrentfolder selected. But, if I'm doing this from one of the files in the "files" tab, then it opens \torrentfolder with the correct file selected. I don't see anything wrong here.

[13xforever]

Sorry if it's a known problems, but I've looked a couple of pages back in this thread and didn't see them.

After installing today's build (2.2.1.24266) I have problems with Apps and WebUI. Apps doesn't work at all and WebUI doesn't get automatically downloaded (on first request when there's no webui.zip)

Every time I click on Apps in sidebar, I have these errors in the log:

[2011-01-22 20:36:06]  Script Error: line=905 char=3 code=0 message=Object doesn't support this action url=btresource://btapp/packages/jquery.js[2011-01-22 20:36:06]  Script Error: line=17 char=1 code=0 message='jQuery' is undefined url=btresource://btapp/packages/jquery.json.js[2011-01-22 20:36:06]  Script Error: line=53 char=1 code=0 message='$' is undefined url=btresource://btapp/packages/jstorage.js[2011-01-22 20:36:06]  Script Error: line=181 char=3 code=0 message=Object expected url=btresource://btapp/packages/apps-sdk/bt.js[2011-01-22 20:36:06]  Script Error: line=1 char=1 code=0 message=Object expected url=btresource://btapp/packages/apps-sdk/debug.js[2011-01-22 20:36:06]  Script Error: line=9 char=1 code=0 message=Object expected url=btresource://btapp/packages/apps-sdk/xhr.js[2011-01-22 20:36:06]  Script Error: line=6 char=1 code=0 message='jQuery' is undefined url=btresource://btapp/packages/slimbox2.js[2011-01-22 20:36:06]  Script Error: line=13 char=1 code=0 message='jQuery' is undefined url=btresource://btapp/packages/jquery.evently.js[2011-01-22 20:36:06]  Script Error: line=8 char=2 code=0 message='jQuery' is undefined url=btresource://btapp/packages/jquery.mustache.js[2011-01-22 20:36:06]  Script Error: line=1 char=1 code=0 message='jQuery' is undefined url=btresource://btapp/packages/jquery.pathbinder.js[2011-01-22 20:36:06]  Script Error: line=1 char=1 code=0 message='$' is undefined url=btresource://btapp/packages/jquery.evently.util.js[2011-01-22 20:36:06]  Script Error: line=33 char=5 code=0 message=Object expected url=btresource://btapp/packages/apps-sdk/gettext.js[2011-01-22 20:36:06]  Script Error: line=38 char=1 code=0 message=Object expected url=btresource://btapp/lib/utils.js[2011-01-22 20:36:06]  Script Error: line=15 char=1 code=0 message=Object expected url=btresource://btapp/lib/index.js

Deleting Apps folder and cache files doesn't help.

For WebUI there's nothing in there; it just doesn't work:

[2011-01-22 20:35:27]  HTTP: IP 192.168.0.2: GET /gui/[2011-01-22 20:35:27]  Unable to read webui.zip[2011-01-22 20:35:32]  HTTP: IP 192.168.0.2: GET /gui/download_webui[2011-01-22 20:35:32]  Unable to read webui.zip[2011-01-22 20:35:32]  HTTP: IP 192.168.0.2: GET /gui/downloading_webui[2011-01-22 20:35:32]  Unable to read webui.zip[2011-01-22 20:35:33]  HTTP: IP 192.168.0.2: GET /gui/downloading_webui[2011-01-22 20:35:33]  Unable to read webui.zip[2011-01-22 20:35:35]  HTTP: IP 192.168.0.2: GET /gui/downloading_webui[2011-01-22 20:35:35]  Unable to read webui.zip[2011-01-22 20:35:35]  HTTP: IP 192.168.0.2: GET /gui/index.html?error=1[2011-01-22 20:35:35]  Unable to read webui.zip

Help is downloading as expected. uTorrent is placed in special folder where it can write to without admin rights and have local settings if this helps.