Archived

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

Firon

µTorrent 2.0.2 released

Recommended Posts

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

Share this post


Link to post
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.

Share this post


Link to post
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.

NU.

Share this post


Link to post
Share on other sites

We're strongly considering bypassing the windows cache all the time anyway, despite my hesitance in that post. It probably won't hurt, considering writing is usually more intensive than seeding...

Share this post


Link to post
Share on other sites

No, it's been reported since forever ago (if memory still serves, that isn't even the earliest thread either). It was always stated that BitComet didn't exhibit the issue, and it was determined that it was because BitComet itself was bypassing the Windows cache. Which is why this was implemented in µTorrent.

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites

is there an issue with the 19248 help file ? or it's server ? ( [2010-04-24 12:30:33] Could not download help file. Error: offline (timed out) )

Share this post


Link to post
Share on other sites

It's fine now. In case you haven't noticed, there was several hours of outages at the datacenter.

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites

The Windows cache has always been bypassed while downloading, so the behavior hasn't really changed. It's only while seeding that it bypasses it by default too.

Share this post


Link to post
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 .

Share this post


Link to post
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?

Share this post


Link to post
Share on other sites

are both your write & read Windows caches disabled (in advanced->disk cache ) ?

Share this post


Link to post
Share on other sites

Just disabled them both and it's ok. But why weren't they disabled (default) when I updated from 2.0.

Does someone has to visit the forum in order to make it work?

Share this post


Link to post
Share on other sites

a good question... they should be forced as default. maybe they screwed up ... :P try again... ;)

Share this post


Link to post
Share on other sites

If you had changed the settings already, it will not alter them for you. It only changes the default setting, which will only change it for users who had not mucked with the setting before.

Share this post


Link to post
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)

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.