µTorrent 2.0.2 released

[nanodesu]

Here it is: http://www.mediafire.com/file/djt5mmzxdd4/settings.dat. Hope this'll help.

Probably the problem is in 'number of upload slots per torrent'. Now it is set to 5, I tried to change it to 200, but it didn't solve the problem. I don't know, what else could it be

EDIT. BTW, download works just fine without any limits.

[rafi]

I don't know, what else could it be

a bug ?...

[stevvie]

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

[alex14san]

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.

[newuzer]

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.

[Firon]

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

[rafi]

maybe - just do it for Win7 or X64 systems ?

[Firon]

No, it affects XP and up.

[rafi]

never saw this on my XP/SP2. Wasn't it reported maybe only on SP3 and up ?

[Ultima]

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.

[Firon]

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.

[rafi]

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

[Firon]

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

[rafi]

I've noticed. And it doesn't download from here right now... I guess it takes some time to fully recover ... why don't you just put the correct version over here too : http://download.utorrent.com/utorrent-help.zip to be available on the documentation page

That will help bypass a few of such errors/situations

[Delfinok]

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.

[rafi]

uTP overhead is jumpy, and reaches ~40-50% ...

bt_transp_disposition = 26 , on XP.

http://img90.imageshack.us/g/3248.png/

more here: http://forum.utorrent.com/viewtopic.php?pid=478564#p478564

[Firon]

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.

[Domokun]

Is it already known that the duplicate peers bug is still present? In the latest 19248 build as well.

[rafi]

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 .

[SkyHi]

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?

[rafi]

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

[SkyHi]

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?

[rafi]

a good question... they should be forced as default. maybe they screwed up ... try again...

[Firon]

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.

[rafi]

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)