rseiler

I could have sworn I read up the thread that gui.show_welcome_node was supposed to do it, but it doesn't work for me. I'm still sifting through the overwhelming number of responses to this, but for now I'm going to use bt.graceful_shutdown -- assuming it works, of course.

I started using 3.0 at the RC stage, but only saw this happening at the end, possibly with the first final build, and through the subsequent final builds: after actively using it for torrenting (not just running it and closing it), the utorrent.exe process sticks in memory indefinitely after closing the app. I remember this subject coming up now and again over the years, but I haven't found an active thread on it, so I thought I'd mention it here in case anyone has seen it recently. This is not a new install but rather a continuation of all the RC installs, the first of which was installed over 2.x, etc. Win7 x86.

How sure are you about that (are you maybe thinking of 3.0 alpha/beta)? How do you reproduce it in 2.2.1? There's no way it was about deselecting files then, at least on Windows, since I do that all the time and never saw it before 3.0.

Thanks for pointing that out, since I'm not sure that I would have realized the pattern. This is a major bug that will have to get fixed. It definitely wasn't in 2.x releases for me though.

rafi, bear with me, I'm still struggling with this. For my percentages, I was talking about the % of my overall UL, whereas you were more properly talking about % overhead relative to DL. That aside, I can only increase UL so far so can only test this so much, but how do you explain my overhead raising commensurately with raising my UL limit? In the above example, I doubled UL to 100, my DL wasn't much affected, yet my overhead doubled as well. If I could raise it to 200, would it double again? If so, this is more than simple ACKs. In v2.00, didn't the "Up Speed" column for each torrent show a real UL value (assuming net.calc_overhead was set appropriately)? Just as v2.01 does? I realize v2.00 didn't have an overall overhead figure.

I don't get it then. Since when is there more (or at least equal) overhead as compared to actual upload? I've done more testing now, and when dl'g is at its most active, around 1MB/s, overhead actually dwarfs ul (out of 50KB/s, overhead hangs at around 80-90%, leaving almost nothing for actual ul). If I increase to 100KB/s, overhead doesn't drop below about 80%. Remember that I don't even have uTP enabled. Rafi, above, expressed surprise that he saw a mere 35% overhead *with* it. It used to be that overhead was in the minority. In past threads, I've read of "5% ACK" back when we were discussing the effects of enabling/disabling net.calc_overhead. Now it's so much higher that DLs are obviously affected.

Yes, I do. I was only dl'g at about .5 MB/s though. I know from past versions of uT and other dl'g, however, that overhead is nowhere near this high. .5MB/s wouldn't even equate to 10KB/s UL overhead before v2.01.

With uTP disabled (Enable Bandwidth Management unchecked), I'm seeing 40-50% overhead, as reported on the status bar. That is, for example U [50kB] 25kB/s O: 22kB/s. How can this be? Overhead should be more on the order of 10%. Win7.

Since bandwidth management is on by default, I'm assuming it's generally a good thing, but I'm still unsure when and why it should be disabled. As it's probably not appropriate for everyone, was this debated back in the beta thread somewhere?

What if this isn't an issue? Is disabling uTP (setting bt.transp.disposition on 5) advisable if you want to ensure that you're always downloading as fast as possible?

It's a little unclear what you mean, but are you saying that you never want it to use the tray at all? Otherwise, you can get pretty close by unchecking "Minimize to tray" and hiding the tray icon. I for one want to continue using the tray for uTorrent in Win7, so like it as is. The taskbar 100% of the time is overkill for uTorrent and I wouldn't use a "Close to taskbar" type option. On another subject, I have to say that looking at the new toolbar with fresh eyes, I thought the Preferences icon was grayed out and unavailable to me. I don't see why it's not pronounced like it used to be. Same for "Create New Torrent."

"UAC must be completed to install in Vista or higher" might not be the best phrasing. I, for one, don't quite understand it. Do you mean UAC must be enabled?

For anyone not from the beta wondering what uTP actually is: http://en.wikipedia.org/wiki/Micro_Transport_Protocol

Nice job. A lot of people predicted the worst for uTorrent when it changed hands back a year ago or whenever it was, but I never held those rather cynical beliefs and look how things turned out.

Yes, but since, I don't know, about 95% of the updates are betas and not fed through that mechanism, it's quite easy to forget about it. Someday, I hope for an advanced option (which defaults to off) that allows betas to come down this way, too.

Could someone tell me where I can uncheck "resolve IPs," as an earlier post suggests is possible? I've looked all over 466 and somehow it's eluding me. Thanks. I too found that it overwhelmed my router, and I don't even have an older/slower one.

"- Change: Resolve IPs is on by default, but only if the Peers tab is active." Please don't forget about the Logger tab. The IP's listed there (from ipfilter.dat) need to be resolved as well, but it's even easier in this case since the definitions of every address already exist within the ipfilter.dat itself, just not in a form easily or conveniently read by a human.

What kind of a ridiculous response is that? Tooltips would be a great help, but that's obvious. If these options are so verboten, they wouldn't be there and we'd have to modify an .INI. And next to NO ONE knows off the top of their head what these mean; that hardly means they therefore shouldn't be used. There's a little thing called knowledge. And going off to the Web and burrowing down through an endless FAQ to eventually find a blur of poorly-formatted advanced options and then reconciling those with what you see in the program (and no, they don't always match up) is an unnecessary eye test. I'm surprised you didn't use the "We don't need more bloat" argument, which would have been even more laughable. You missed a real opportunity.

- Feature: Added tooltip help to each item in Advanced Options Oh, sorry, that was just a dream.

A "lot"? Relative to the tens of millions of normal broadband users out there? Really? No way. I wouldn't think even more than 1%. But let's say there are millions upon billions of them. They need better caching even MORE. And on how much activity uTorrent is not causing, try looking at Filemon sometime, if the red light every second isn't enough for you. My point above, which was of course missed, is that we have tons of memory sitting around unused. uTorrent does not need to be hitting the disk like it does.

After reading the last few messages, the caching situation is back to being clear as mud for me. Firon has always pop-poo'd caching. He's not a fan. His recommendation, unless you have a "multi-megaBYTE/s" connection (something almost no one here is going to have) is to not even bother configuring the cache, leave it at defaults. Only problem is at defaults, uTorrent is still a busy little beaver when it comes to disk activity on a multi-megaBIT connection. Whether that matters or not is beside the point. I believe it does. Others don't. So what can be done about this activity? The mind, naturally, turns to the DISK CACHE. But we're told, somewhat dismissively, to keep our uneducated mitts off it, lest we make things worse. On systems which sometimes have multi-gigaBYTES of memory, does this make sense? Surely it can be put to use. There's no way uTorrent needs to access the disk constantly on a typical home broadband connection. I'll never believe it has to be that way. I remember about 15 years ago running a clever staged-writes disk cache called HyperCache. Before implementing the cache, the disk was tsk-tsk-tsk downloading at 14.4 with Zmodem; after implementing the cache, there were only bursts of activity when necessary (or when you configured Hypercache for, I don't recall). I realize that was a one-way transfer at tremendously slower speeds, but relatively speaking it's analogous. I mention it to illustrate that disk caches have been making a difference for a long time. Until now, anyway. Shouldn't we pool our meager brains to see if indeed there's something better than defaults?

I see what you mean, but I wouldn't have noticed it if you hadn't mentioned it. I did notice that it takes longer to appear than your normal tooltip, but that's probably intentional, since that particular item is one you don't want popping up every time you swing the mouse by. As you said, perhaps they're not using the standard routine for some reason.

Standard tooltip' date=' yes. But it doesn't look standard. Take a look on any other windows utility which uses tooltips (shouldn't be hard to find one;) and compare them.[/quote'] But how? It's black text on a little yellow window, just like the one you see when you float over the uTorrent icon on the sys tray, right? Just like the one with every other program on my tray as well.

Answering my own question here, according to Disk Statistics, the manual cache size override size pertains to the write cache, effectively setting its upper limit. The read cache is totally dynamic and separate from that figure. As far as I've seen in moderate usage (several hundred KB/s down, 10-30KB/s up), the read cache tends to stay low at around 2-5MB while the write cache can vary between 5-12MB. Which reminds me, one cool thing to see in Disk Statistics would be a straight percentage for read and write caching. It's nice to see everything broken down, too, but it requires a bit of mental gymnastics to make sense of.

That's standard tooltip-type balloon help common in many programs. That's what I was talking about just above relative to introducing some explanatory notes into the program in other areas.