Jump to content

µTorrent 2.2.1 released


Firon

Recommended Posts

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

Same here (2.2.1.24266).

With the latest final build I even had to delete the µTorrent settings each time the trayicon disappeared to get µTorrent (re)started again (to see in the tray)!

With the new beta build it seems that you can restart µTorrent with an active trayicon at least.

Link to comment
Share on other sites

  • Replies 608
  • Created
  • Last Reply

Top Posters In This Topic

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' date=' 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.[/quote']

It indeed works like you described there Chichipio, but if it was intentionally changed, I think it's silly.

If a downloaded torrent consists of a folder, I want to see the thing that matters to me: the contents of the folder and not the folder itself.

Link to comment
Share on other sites

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.

It's not really a firewall. It doesn't protect the user from malicious incoming traffic. It makes the user a less attractive victim for being owned and used in a DDoS attack.

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.

The firewall analogy is odd. This is not about protecting the user. It's about making the software less likely to be abused for launching attacks.

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 is the port filter. It's on by default, there's no clear indication of it being there and it's not trivial to turn off. The vast majority of functionality in utorrent works this way.

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

Although I agree that these are reasonable expectations for features the user is likely to want to change, I don't think it's true across the board. Say, uTP target delay, the vast majority of uTorrent users won't even understand what that is, and much less likely to change it. If there was a great need to change it, we should really just change the default instead (which in this case we might at some point). Or things like diskio.smart_hash, definitely something everyone should leave on (unless you're specifically trouble shooting some issue).

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...

I get the impression that you think that running on a low port will significantly reduce the number of peers that will connect to you. Keep in mind that you can still connect to peers via the DHT!

Could you run some simple tests to show this? I would be surprised if this is the case for the most part. In my experience, torrents with no trackers are not very common.

Link to comment
Share on other sites

>Although I agree that these are reasonable expectations

That's the problem. No one will notice that, thus the default will cripple the uT "experience" for people using low ports for 'good' reasons...

>So is the port filter

not sure what you mean, but if it is the service ports' list - it's (at least) visible. Having 2-3 ports, is not like banning the whole range. even if from DHT.

> ...that you think that running on a low port will significantly reduce

> Could you run some simple tests to show this?

Yes, I do (if using DHT). And no, I'm using 2.0.4 and do not intend using 2.2.1 till it's stable, if at all. Test it "in the wild", and you usually do... :P

Leave 2.2x free of this and put it in 3.0. At least we will have one good successor to 2.04 in our hands... ;)

and I'm done dealing with this... for now...

Link to comment
Share on other sites

Instead of endlessly debating this pointlessly, how about we suggest a compromise of sorts?:

Seems like all that needs to be done is detect whether someone's already using a low port and warninng them/give the choice to either change it higher or disable the blocking.

That would avoid 'crippling' them unintentionally/unnecessarily.

Link to comment
Share on other sites

You are missing the point (at least the main point...) . Since this is the default, it's not up to the user at all. Even if he disables the blocking on his own client, everybody else (using DHT) will not initiate a connection to him as a seed/peer . It has a global effect. And I cannot tell you if Arvid is right or not saying it is negligible, since no one (including Arvid) has tested it in a DHT swarm, all using 2.2.1 ... And asking me to test the impossible - is ridiculous :P

But, good thought/try... :) As I said - the endless loop ended (for me), cause I'm done... ;)

Link to comment
Share on other sites

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

Same here (2.2.1.24266).

With the latest final build I even had to delete the µTorrent settings each time the trayicon disappeared to get µTorrent (re)started again (to see in the tray)!

With the new beta build it seems that you can restart µTorrent with an active trayicon at least.

I also experience this problem on my Win 7 64bit with µTorrent 2.2.1.24266 beta

Link to comment
Share on other sites

New beta still freezes with socks5 on ss5 after extended use.

Thanks for working on it though appreciate the prompt work.

I can't reproduce this. Running with ss5 does not freeze uT for me, no matter how long I wait. It does obviously break connections because it doesn't support UDP, but uT doesn't break other than you can't download anything.

Can you describe the symptoms you see in more detail? when you say freeze, does the UI stop refreshing? are buttons no longer clickable?

Link to comment
Share on other sites

For any users with high CPU usage, are you seeing the problem while NOT using a proxy? If so, would you be willing to provide a dump file for uTorrent?

On Windows 7, you can simply open the task manager, right click on utorrent.exe in the processes list and hit Create Dump File. Zip it up, upload it to mediafire.com and send me an email with the link, firon at utorrent.com.

If you can do this, we can solve the CPU usage issues. Thanks!

Link to comment
Share on other sites

I finally discovered the socks5 error handling which would cause an infinite loop (freeze and high CPU usage). This is now fixed and should be in the latest release.

as for the disappearing systray icon, I've reverted the async. code back to always be synchronous, which I believe should fix the issue.

Link to comment
Share on other sites

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...

I am one of the users Rafi is talking about, I modified my port selection as Qwest (west coast isp for dsl-dialup, part of the baby bell's "us west") has been and will continue to block bit torrent.

So after a lot of trial and error I started using microsofts DNS port range or lower for my torrent traffic and my speeds improved (protocol encryption enabled of course) as I see it blocking DNS could lead to a very big lawsuit for Qwest.

and so far it has been working for me for the last 3 years.

my Idea would be to just block port 80 (the webserver port) as its the webservers getting hit with a ddos attack thats the worry.

as I see it the developers are using a huge brush to paint over a tiny hole (and cover over the fact that its the DHT protocol that is the problem and needs to be reworked as pointed to by Ultima in post #186 "work around exploits" http://torrentfreak.com/bottorrent-using-bittorrent-as-a-ddos-tool-101229/ , Quote "Astro says that since it's a design error, the [DHT] protocol has to be redefined eventually"

this will still cause problems for those who need to use port 80 as their isp only wants them to surf the web

Link to comment
Share on other sites

This program is soooo NOT working! .... But laugh at me again "Mr. Developer, Sir!" Just don't ask me for my help after your last response to me.

Build 24266 is now uploading at TWICE the designated speed that I have set it for and it's been uploading at twice the speed on my different files!

But please, don't ask me for my help with log files or screen shots because I just don't appreciate being dismissed! :-(

Link to comment
Share on other sites

I don't know who you're directing your post at, but if you're talking at me (I am the last person you responded to before), then FYI, I'm not a µTorrent developer. Nor did I "laugh" at you (heck, I never even responded to you -- I was responding only to rafi).

But you know, all your reports are giving completely mixed up pictures. First, you tell us DHT isn't connecting to nodes, then you tell us it is, but that it's because of "demand" for the torrents you're sharing (it's not). Now, you're telling us that your upload speeds are going above your limit when you previously said that

upload speed is also very sluggish

So what's it going to be, really? You seem to be grasping at straws here trying to find something to pin the blame on. None of the anecdotal evidence you've provided so far have been conclusively indicative of any bugs, and at least a part of the reason is that you haven't even provided any hard evidence to back it up. If you're completely unwilling to include any such information, then that'll be that for your report.

Link to comment
Share on other sites

Do you actually HAVE any uTP connections? :)

I there was any indication somewhere on that screenshot (or any other global place, not per torrent) for the total # of uTP/TCP peers - it would have helped the user (and us...) to understand that :) (main view bottom line, optional column, status line...)

Link to comment
Share on other sites

Archived

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


×
×
  • Create New...