osm0sis

I get the following on each program start (note I added the [%AppData%] myself to shorten the lines): [2012-03-10 10:27:41] File not found during integrity check: [%AppData%]\uTorrent\resume.dat [2012-03-10 10:27:41] File not found during integrity check: [%AppData%]\uTorrent\resume.dat.new [2012-03-10 10:27:41] File not found during integrity check: [%AppData%]\uTorrent\resume.dat.old This happens even though resume.enable_resume_dir = *true, and more importantly resume.dir_only = *true.

Create empty dummy files with the same names and they can't be created. That's what I do.

Fair enough, but it's the same bug as in 3.1, so it still applies. We shall see if they've done anything to improve matters down the line though, of course.

Just my observations of the way µTorrent behaves: http://forum.utorrent.com/viewtopic.php?pid=631944#p631944

Do you have "Apply rate limit to overhead" enabled? That seems to be be what allows the cache to exceed its limits massively like what you're showing. With it disabled it doesn't exceed but the download slows down... I think they wrote some throttling in to compensate for the inefficiencies in the new disk cache code but for some reason the apply to overhead setting circumvents it.

Updating still causes µTorrent to forget window width and torrent list height.

Autoupdating failed to delete the .TMP file in %ProgramFiles%\uTorrent and program didn't reopen.

It's the guts of the rating system.

Should µTorrent really be having so many PEX message related bans with itself? Generally 3.0/3.1 are the majority of ones banned; you'd think the newer versions since the addition of the "5 message limit" ban code would be smart enough to avoid this so as to remain a viable peer.

Fair enough, but don't expect anything on something pre-beta. Beta maybe; RC for sure you can start asking.

I agree. Also, why should µTorrent work on prerelease operating systems? There is honestly no reason for it even to support 64-bit architecture since (I pray) µTorrent won't ever need to use over 4gb of ram on its own. This is becoming almost as bad as people demanding Firefox 64-bit stables without understanding it's unnecessary.

They've mentioned a few times that there won't be a new 64-bit version until at least Q1 2012.

Will be replaced by Share in a later version I imagine; check 3.0.1 if you want to check out Share.

How can you not create one? It works fine on Demonoid for me. Worked for me. 3 torrents, 3 trackers.

Fantastic news! Yeah it's coming along nicely. Now that I've turned off that transport overhead setting it's quite usable again. Thanks so much, and please consider some of the "leftover" issues/bugs from previous versions in my buglist post as well!

I already tried that, remember? Ahh and now I understand the reason it didn't exceed there; the default "Apply rate limit to transport overhead" setting of disabled! Still clearly had the disk write lag though. Edit: Haha and yes, I might end up using your settings, but default behavior like this is likely a bug, so report it I shall.

Wasn't at the time, Adam, but I can definitely still reproduce on 26595. Anything I can do to help track it down? There are two issues at play there in case it got a little convoluted in my string of posts: the disk writes take forever to start during ramp up, and also the exceeded cache. There seems to be a correlation to exceeding the cache and having "Apply rate limit to transport overhead" enabled, though I'm not sure how those two things could be connected. With it disabled I get a throttling effect when the write cache gets maxed on a fast torrent even though I have Download Limit at "Unlimited" (Is this the normal, expected behavior to avoid exceeding cache?). Enabling it, for some reason, allows it to massively exceed the cache since I guess there's nothing to stop it (no throttling?) and there aren't any disk writes occurring so it just blows up. Fresh torrent Delete and re-Add of the slackware x86 "everything" torrent to test it with each setting change, no program restart required. The disk write lag occurs regardless of "transport overhead" setting.

I don't actually have a speed limit set... "Unlimited" for Download and 90kB/s for Upload - I'm just getting this odd throttling effect when the write cache gets maxed on a fast torrent and "Apply rate limit to transport overhead" is disabled. Enabling it, for some reason, allows it to massively exceed the cache since I guess there's nothing to stop it (no throttling). Edit: When it exceeds the write cache I'm usually downloading at around 1-3MB/s. My actual connection is 30Mbps/2Mbps.

rafi: Does "Apply rate limit to transport overhead" checked allow the write cache to exceed during the ramp up with a fast torrent on your end? Unchecked I get that throttling, checked I can still go massively over... I feel like I found a correlation here. #1 in my Buglist post has been updated.

Blanking s_url and stitle effectively removes the link too - much more my style. Good find!I'd also like to suggest making empty "apps" "cache" "ie" and "dlimagecache" files in %AppData%\uTorrent for inclusion in your guide, as that REALLY makes sure they're disabled I've had plenty of fun trying to disable all the new features. I've even got btapps.app_store and btapps.apps_channel set to "about:blank"

Hmm I have this odd compulsion to watch boxing now for some reason.. Poorly handled settings.dat corruption. They were supposed to have fixed that though, I thought. If you can bear to, deleting your settings.dat should fix it; of course you'll have to redo all your settings and sizing.

Don't know about everyone else, but with 26595 my testing finally seems to verify the hashfail issue is resolved (slackware had 1 hashfail but no repetition). Also not seeing any mini-hangs/hangs or crashes now. Great job! Now we just need fixes for the stuck cache, disk write lag and other issues.

Did I mention it downloads at 1.5MB/s until cache limit is reached and THEN it downloads at slow speed? Not sure why it's doing it on my end but it is definitely related. Edit: @rafi: Defragged overnight on Firon's suggestion... according to PerfectDisk it should be at 99.7% performance again with negligible fragmentation across the board. Edit 2: Tried again and after 5min of throttled wait the disk writes finally kick in and it actually performed well for awhile (until it crashed...)

Tried that just now.. doesn't exceed, but a lot of weird stuff is going on. It throttles the speed when it gets near the cache limit, but then it still never writes to disk. Screenshot: You can see the amount it accomplished in 5 minutes... very little. Edit: Just noticed it says "Moving..." in that screenshot, but that's just the Simple View being stuck, and just in case, I reproduced again without moving using the old Torrent List View now. On a side note: "Show a window that displays the files inside the torrent" doesn't apply to Simple View? That's annoying...