newuzer

Could be related to high speed downloading (>10MB/s) and (cache) writes as that's when I spotted this behavior.

+1 (build 29719)

RC8 build 27547 I'm struggling with the current behavior of the "Add New Torrent" dialog. I hope my explanation makes sense. 1) When adding a torrent with "Add torrent..." or double clicking on a .torrent file and selecting an already existing directory with existing/matching content with the "..." button in the "Save In" section, you need to clear the name field on order to let it hash-check and join/seed the already available content. If you do this, it uses that directory but the torrent appears nameless in the torrent list. 2) When choosing "Add Torrent (choose save dir)..." and pointing at an already existing directory with existing/matching content, it creates a new sub-directory with the .torrent name and re-downloads all the content instead of hash-checking the existing content. In both examples, this behavior would be fine *if* the name of the directory containing the content is always the same as the name of the .torrent file and you then point at the parent directory. However, it's a problem if for some reason you have chosen to to use a different directory name to store the content. In the past it was simply using the root of the chosen directory, which makes more sense to me. NU.

This problem ONLY happens because of the unbuffered I/O. We removed that functionality in the most recent 3.2 builds. Therefore' date=' it should be fixed now. [b']This problem should no longer happen. I'm sorry to say Firon, but it still happens. I just did a test with the latest 3.2 build (27343) with out-of-the-box settings and files are still shown wrong. As you know this can simply be reproduced by using the MAME 0.145 Titles torrent and the Torrencheck tool (or CMP if you wish), which both can be found on the PD site. This torrent is also an excelent "Disk overloaded 100%" test due to the large amount of small files NU.

I asked it earlier in this thread: (http://forum.utorrent.com/viewtopic.php?pid=471532#p471532) Firon's answer was: (http://forum.utorrent.com/viewtopic.php?pid=471536#p471536) NU.

Seeding only. NU.

Scratch all that. I'm testing the 2.0.1 testversion now and memory usage is still going to the roof. In about an hour it steadily climbed to near 100% of 4GB total memory usage and the system becomes less responsive. The svchost.exe process is not to blame, which was my mistake (sorry for that). There is no visible process that uses the amount of memory. There was a sudden drop of memory to 2.6GB total usage after about an hour and a half or so, but it steadily climbed back up again. For comparison: I Tested an old version (v1.8.1) yesterday, which kept memory usage to 1.6GB total at much higher upload speeds. NU.

Firon: Now, why was it so hard to tell this now, after all the explanations (ranting) about different behavior between releases? IIRC I've seen SuperFetch in the svchost.exe memory eating process. It definitely could explain this behavior. Disabling SuperFetch will affect overall system performance. NU.

The good thing about uTorrent in the past was that Ludde always aimed at making a small efficient program that uses as little resources as possible with the most features. People loved that concept, hence the popularity of the program. Well, the micro can now be removed, same as the word "efficient" on the web page. If you, for example, compare v1.8.1 to v2.0 and v2.0.1, uTorrent has become a resource hogging torrent client in that short period. Totally inefficient. Too bad. NU.

It doesn't with 2.0. Too bad to hear these kind of dumb comments from you, Firon. Anyway, I stop wasting my time here. This software is b0rked and gets worse with every release. NU.

No, the svchost.exe process is using all the memory. I decided to connect to IRC to try to get things sorted. After disabling the read cache and restarting uTorrent, the memory usage is brought down to normal but IMO it also brought down the upload speed. Firon@page#2: Although changing settings seems to help make this version usable, I also think this is not the solution to the problem. There is a difference between earlier releases and this release which causes it to use an intolerable amount of system resources, making it unusable for some of us. NU.

Believe me, I did all that before I decided to post this possible problem. If I wasn't 100% sure it wasn't me causing it in any way, I wouldn't have bothered bugging uT development with it. BTW, I'm dead calm NU.

Why don't you stop answering, if you don't know a proper solution. You didn't even read what I just wrote (and before) and it starts to piss me off. IT'S NOT THE WINDOWS CACHING SYSTEM THAT'S TO BLAME HERE! Disabling the cache does not help. I try to point uTorrent "developers" at a problem with THIS version compared to earlier releases that do not have this problem in the same circumstances. You however are not one of them. NU.

This stable version is also unusable for me as it's also causing my system to use all available memory. This happens at (for me) low/normal upload speeds (1MByte/s). After just a short time, the system is running out of memory and becomes unusable. You can persist in blaming M$'s caching system, but with v2.0 and earlier I don't have this problem, even at much higher upload speeds (>15MByte/s). NU.

You don't get the point, us. This version is considered to become the final release in a few days, barring any problems. Where the current stable version works fine, this one doesn't, unless I change all sorts of settings. I would say it's a show stopper, without blaming us. If Windows' disk caching it is such a problem, why not disable it by default if it sorts the problem? NU.

I'm aware this version is useless, yes NU.

FYI. My curiosity made me decide to try this RC version (build 18833) over the latest v2.0 this morning. However, after a bit of time, this version is somehow eating all my memory (4GB), making my system impossible to work with. Stopping uTorrent instantly dropped the memory usage to normal, around 1GB in use. Never had any problems with any version in the past, that I'm aware of. So, back to v2.0 again and it seems to be doing fine. OS: Windows 7 x64 NU. P.S. I'm aware of the date