Jump to content

µTorrent 2.0.2 released


Recommended Posts

  • Replies 406
  • Created
  • Last Reply

Top Posters In This Topic

Firon, so BOTH uremote for pc AND iphone broke at the SAME time when µtorrent build 18973 was installed ????

Thats some coincidence.

So what about the HIGH CPU and memory usage in the later builds that are missing in the earlier builds ?

Also if UREMOTE is broke how come it works with EARLIER builds of utorrent and the CURRENT build of BITTORRENT ????

Link to comment
Share on other sites

Turn on "Disable Windows caching of disk reads."

Maybe it should be disabled by default in next versions?

Windows caching creates only troubles for uTorrent,

or all its cache quickly gets all filled only by uTorrent data and other applications suffer because of that.

Link to comment
Share on other sites

I asked it earlier in this thread: (http://forum.utorrent.com/viewtopic.php?pid=471532#p471532)

If Windows' disk caching it is such a problem, why not disable it by default if it sorts the problem?

Firon's answer was: (http://forum.utorrent.com/viewtopic.php?pid=471536#p471536)

newuzer: we disable it for writes, but for the vast majority of users, it's not necessary to disable it for reads. And in general, disabling the system caching is not the preferred solution, for various reasons.


Link to comment
Share on other sites

Okay, build is up with the change, along with a (rare) crashfix and a fix for the invalid HTTP headers when passing an expired/invalid token. This is the final 2.0.1 release and is now being autoupdated for everyone, not just beta users.

Link to comment
Share on other sites

Ok! Am I alone on this?

After updating to 19248 i see a HUGE increase in "disk overloaded 100%" time while starting to download new torrents with huge size (for ex. Blu-Rays).

On previous builds disk overloaded times were way shorter.

Right now my 45GB torrend overloaded a disk by 100% and it keeps overloaded for 10 min already.

EDIT: Ok, overloading has ended. So basically after windows cache bypass i see an increased by 2x times data writing process on HDD.

Link to comment
Share on other sites

Firon wrote:

The Windows cache ...

Did I mention the Windows' cache anywhere in the post ...? Though, uT does do seeding too in those examples close to the max speed per the defined UL limit (22K) , I've not correlated this test result to anything. I'm just stating a fact, the main test-conditions/repro-steps (need my settings.dat too?) and I suggest that this huge header overhead should be further explored by the devs (see more in the post I linked to. Maybe for the 2.02 release? ).

And to another issue - 16K size un-paced packets, you are welcome to view the capture file requested by alus - here .

Link to comment
Share on other sites

Still the problem with all the memory over-usage in Win 7 64bit! And the double peers!

Went back to 2.0 where there's no problem.

The truth is that uTorrent is the only app I've seen that seems to become more buggy in every new edition! And there are so many and frequent new ones. Can't you just give out a proper, stable and reliable one?

Link to comment
Share on other sites

in general, this is a good "rule" - to not change anything the user has modified. But I think there are some exceptions:

1. When you discover a bug/issue, and some setting can cause the system - harm.

2. When there is a mismatch/conflict with some new change/feature

For #1 - like in our case here - IF you think that using the Windows write cache might also be causing memory issues - you should disable it regardless of what the user did (and maybe display some message to that fact, or ask the user before you do that)

For #2, an example I can think of is a 1.8.5 user sets bt.transp_disposition from 13 to 15. Now, you invented a new/better header, that requires a new setting - 31. I think it should be force-changed . (in theory... or maybe an 2.0 user would be a better example)

Link to comment
Share on other sites


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

This topic is now closed to further replies.

  • Create New...