[µTorrent 3.1.3 stable (27327)]

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.

[µTorrent 3.1.2 stable (26821)]

Firon, how can i block the creation of the following folders: Cache, apps, ie, dlimagecache ?

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

[µTorrent 3.1.2 stable (26821)]

I would wait till they sync "3.1.1" with 3.2 fixes, and start beta testing with it.

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.

[µTorrent 3.1.2 stable (26821)]

What makes you say that ?

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

[µTorrent 3.1.2 stable (26821)]

Whaaaaaaaaaa???????

I don't like talking negative about free programs but goddamnit, this cache bug you keep fixing/reintroducing is ridiculous.

Either fix bugs or bloat the program...

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.

[µTorrent 3.1.2 stable (26821)]

We will re-release 3.1.1 later with a higher version number.

[µTorrent 3.1.2 stable (26821)]

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

[µTorrent 3.1.2 stable (26821)]

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

[µTorrent 3.1 stable (build 26671)]

what is the meaning of bt.enable_pulse in advanced options

It's the guts of the rating system.

[µTorrent 3.1 stable (build 26671)]

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.

[µTorrent 3.0 64-bit experimental 25570]

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

[µTorrent 3.0 64-bit experimental 25570]

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.

[µTorrent 3.0 64-bit experimental 25570]

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

[µTorrent 3.1 stable (build 26671)]

Where did the send file icon option disappear to in 3.1?

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

[µTorrent 3.1 stable (build 26671)]

Don't know if this is right place to post this but latest version does not work on Demonoid ie cannot create torrent.

How can you not create one? It works fine on Demonoid for me.

uTorrent opens them fine, but you can't use them outside uTorrent by uploading to a tracker.

Worked for me. 3 torrents, 3 trackers.

[µTorrent 3.1 stable (build 26671)]

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!

[µTorrent 3.1 stable (build 26671)]

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.

[µTorrent 3.1 stable (build 26671)]

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.

[µTorrent 3.1 stable (build 26671)]

No idea. I have it checked all the time, and have no download speed limit. I'll try it. Did it effect the cache even when you don't set any speed limit?

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.

[µTorrent 3.1 stable (build 26671)]

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.

[µTorrent 3.1 stable (build 26671)]

OK, guys, try this "Guide":

0. Close uTorrent

1. Run BEendode-editor http://forum.utorrent.com/viewtopic.php?id=31306 on your active settings.dat file

2. Search inside for "stitle" (no quotes)

3. Edit it (double click) and replace it with "Take out product survey"

a. Search for "s_url"

b. Edit in your own URL, like this one to this on-line TIPs/guide: http://forum.utorrent.com/viewtopic.php?id=74820

c. Per the above 'guide' enter as stitle: "Rafi's tips-guide..."

Now, rerun uTorrent see if that did the trick ...

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"

[µTorrent 3.1 stable (build 26671)]

Hmm I have this odd compulsion to watch boxing now for some reason..

Just updated to 3.1. Why do I have this weird foreign text in the toolbar?

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.

[µTorrent 3.1 stable (build 26671)]

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.

[µTorrent 3.1 stable (build 26671)]

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

[µTorrent 3.1 stable (build 26671)]

are you sure you are using this "stable" 3.1 ? try with annew/empty settings.dat . I did reproduce the overthecahcelimit issue, but usually it is for a few seconds, and go back to the cache level.

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