Latest version - Disk overload all the time

[zilexa]

Same issue here with uTorrent 3.1.3 build 27220, tried everything with disk cache settings and enable/disable sparse.

Only seems to happen if I skip a lot of files.

EDIT:

No I was wrong, even happens if I have only a single torrent in the list, with just 1 file.

I fixed disk overload 100% by setting cache size to 1500MB, everything else is default. Now it seems to be fixed for all torrents <1500MB. Still get disk overload for larger torrents but at least most tv show single torrents (via rss) are downloaded fine.

edit2:

Unfortunately I had to completely remove + delete data for existing torrents and download everything again because otherwise they all hang on "Flushing to disk #####" forever.

[n3mes1s]

It is a bug present in the last versions of utorrent (that sadly it isnt solved yet...). I have the same issue, in fact i needed to change my utorrent client due to this. In my case varying the options on the disk cache never worked (and already tried everything). U can solve this going back to old versions of utorrent, that works better, like 1.8.2. Unfortunately they dont give support for older versions...

[rafi]

preallocate files + disable using of partfile might help. + my other settings...

[RocketSpidey]

preallocate files + disable using of partfile might help. + my other settings...

Greetings,

Had this same issue happen today after updating to version 3.2, build 27568 (32 bit build),

1) Disabling use of partfile,

2) Pre-allocate all files checked (enabled),

3) Override automatic cache size and specify the size manually ( 256 MB )

appears to have solved the issue,

I did have to (remove) delete torrent + data on the issue torrent and restart, as previously indicated..

This error appeared in the Logger tab while having the issue:

Error: COMPACT_NOT_FOUND, P=1, T=0

the error is listed multiple times, for the duration of the issue / before adjusting to the settings above.

Thanks Rafi, & all who posted the tips for getting around the issue in 3.2 ..

Hope this info helps.

[KidBugs]

Are people still seeing this issue with the latest 3.2 AND with the partfile turned on?

...

/me raises hand...

I finally got a download of selected small files to complete as a test. It did pre-allocate the big (1.5 gig) file in the same torrent. I am downloading the big file now to see what happens.

It has to be a hidden setting somewhere. It started for me just yesterday on 3.1.3. I updated to 3.2, no joy. I uninstalled and installed fresh, no joy. Three times.

[rafi]

I updated to 3.2

For possible joy - try out the next release of 3.2.1 . They might improve partfile handling.

[kengaru]

The problem persists for a long time now and makes uTorrent COMPLETELY unusable. I've used a lot of 3.x.x versions offered in the chain of automatic upgrades, now using 3.1.3 b27220, either parameters I try, varying cache size, etc. it stucks after random time interval any time I use uTorrent in 100% disk overload with no disk I/O. If at the moment of problem I change the cache size to smaller, in some cases it begin successfully flush it, then, stuck after some more time, sometimes it not flushing cache.

I think the bug is either in cache management code, so cache not flushed when should (I tried write cache sizes upto 2-3Gb, it fills all the cache then stucks in disk overload), or in disk IO code, or in disk overload detection (there is no overload condition at all, but it detected somehow and stops flushing cache to disk completely until overrided by some internal condition like changing cache size to smaller). Or there is an bug in cache management code, which arises around the ending cache space moment. Or "Disable Windows Cache" checkbox is doing nothing then unchecked, so Windows Cache is disabled in any state. Or whatever it could be - I didn't saw the code.

And, I download to network share via Gigabit LAN, if it's significant to track problem. My uplink capability is 100Mbits, so LAN is not limiting.

Migrated to other client (randomly chosen through other clients, fat and clumsy after few days even on Core i7 2600K, but downloads files without any such problem to the same disk) until this bug resolved.

[kengaru]

And, is there any old versions archive at utorrent.com to downgrade until bug will be resolved?

[DreadWingKnight]

No.

And you have not given enough information for us to be able to troubleshoot wether or not your settings or habits are responsible.

[fleinn]

No.

And you have not given enough information for us to be able to troubleshoot wether or not your settings or habits are responsible.

Just wanted to register and say that I liked the comment.

But it's a bit difficult to replicate here as well. I have the disk overload prompt turning up for an usb3 disk (standard external wd), even at very low transfer speeds (as in <100kb/s), while having two torrents active along with one upload. Then while the part-files are allocated too fast, µtorrent randomly gets a write-error at some point - because the drive disconnects. The reason it does that is about 50 identical page-errors at the same time that look like this:

Log Name:      System

Source: Disk

Date: 16.07.2012 14:58:03

Event ID: 51

Task Category: None

Level: Warning

Keywords: Classic

User: N/A

Computer: n56vz

Description:

An error was detected on device \Device\Harddisk1\DR18 during a paging operation.

Event Xml:

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">

<System>

<Provider Name="Disk" />

<EventID Qualifiers="32772">51</EventID>

<Level>3</Level>

<Task>0</Task>

<Keywords>0x80000000000000</Keywords>

<TimeCreated SystemTime="2012-07-16T12:58:03.362797600Z" />

<EventRecordID>404338</EventRecordID>

<Channel>System</Channel>

<Computer>n56vz</Computer>

<Security />

</System>

<EventData>

<Data>\Device\Harddisk1\DR18</Data>

<Binary>040080000100000000000000330004802D0100000E0000C000000000000000000000000000000000C68B2E0100000000FFFFFFFF01000000580000080000000000200A1280012040000000003C0000000000070000000000684EE00680FAFFFF000000000000000010ECFB0680FAFFFF3055B00D80FAFFFF28C6742A000000002A002A74C62800008000000000000000000000000000000000000000000000000000000000000000</Binary>

</EventData>

</Event>

And win7 stops the drive, then restarts it.

When I reduced it to one upload and one download, the errors stop.

So.. this probably happens mostly with large torrents with many files, while the files are allocated as the parts are read the first time. But I'm sure it might happen if the part-files are.. by bad luck.. allocated too quickly for smaller files as well.

I'm not going to go on a holistic debugging-spree, but .. the writer allows you to create cache-references for allocations that might be impossible to create in time for when the first real data arrives..?

[TTLucian]

Multiple downloads cause disk overload and eventually utorrent freezes. I would think this has been fixed by now... Please fix!!!

[Registered]

There is perfmon for xp (same for other newer os ?).

This could give you more information for disk I/O to track the problem

[deleted.account]

Same issue here — http://forum.utorrent.com/viewtopic.php?id=119530

Started having these problems about half a year ago. Every month I try to check for a solution, here on forums and on Google, and every month there are more and more new topics on internet by people who have same problems. STILL NO SOLUTION THOUGH. WHY?!

Can anyone advice me about another lightweight bittorrent client? Please do not suggest old versions of uTorrent, as I never downgrade any software to previous versions.

[DreadWingKnight]

Are you:

1> Skipping files

2> Downloading using the partfile enabled?

[rafi]

http://forum.utorrent.com/viewtopic.php?pid=671732#p671732

http://forum.utorrent.com/viewtopic.php?pid=671758#p671758

another lightweight bittorrent client?

Sure, the next uT 3.2.1 release ...

[fleinn]

Are you:

1> Skipping files

2> Downloading using the partfile enabled?

No skipping, but it's a batch-torrent with about.. 50 files at 250mb.

Download was started with default settings, part-file enabled. "Few"/limited open connections, low transfer speed (80/100kb/s).

Btw, I actually get the disk-overload indicator when placing that torrent on my ssd (with part-file enabled, standard cache size), even if there's no error. It keeps rising for a while (50% or so) right when the torrent begins to transfer. Adding two torrents like that to the external drive always ends in that strange disconnect.

[n3mes1s]

Same issue here — http://forum.utorrent.com/viewtopic.php?id=119530

Started having these problems about half a year ago. Every month I try to check for a solution, here on forums and on Google, and every month there are more and more new topics on internet by people who have same problems. STILL NO SOLUTION THOUGH. WHY?!

Can anyone advice me about another lightweight bittorrent client? Please do not suggest old versions of uTorrent, as I never downgrade any software to previous versions.

Y? thats the question we all wish to know. It seems that the developers are not trying hard to solve this. It is curious that ANY other torrent client works just fine, without any of these annoying bugs. I can only recommend u transmission or deluge, but again, all depends on wat u download, if u download from private trackers, etc. The thing is, if the older versions of utorrnet are more reliable about this bug than the newers, y the developers cant just pick the code of the older versions???? again, no clue. And thats another reason to stop using utorrent.

This is like windows vs linux, windows sux, but it is so extended that for most of the people its too hard to change the so, even if the other ones are far better. This is the same, utorrent is too extended and even if it doesnt work fine, people are very reticent to change it. A shame, but it is a fact.

[rafi]

Y? thats the question we all wish to know.

I can tell you Y: because there is some related issue that is difficult for the devs to trace ... And the info people are posting here is not enough to find it. (To be clear, I am not saying the issue isn't in uTorrent!)

Here is my analysis:

Disk overload occurs, when uT thinks it does not write to the disk as fast as the rate the write cache fills up. At this point it tries to throttle the speed back, and reduce it. It will occur more frequently when you have:

- fast Internet connection (using faster speeds)

- slower hard drives (fragmented?)

- other apps are writing/reading to this drive (AV ?)

- the cache is set to a low value.

It will mostly occur: with multi-files - torrents with smaller piece size and at higher speeds. I'd say @~5-8MB/sec with a 4M piece size and at even less speeds with smaller sizes.

Here are questions I'd recommend for people like you here to provide info on:

0. The OS/HD types, and if it is the system drive

1. What is the download (or seeding) speeds it started to occur at?

2. Did the active torrent - have more than one file in it? and what is the file & piece sizes?

3. If so, were any of the files selectively "skipped" ?

4. when you observe the advanced->cache-stats - what is set cache sizes and the filled sizes (write/read)

And some tips that might reduce the chance for it to occur (or use the settings at my tips-guide below in my sig...):

A* Set the write cache to above 128M

B*. Set the advanced->diskio.coalesce_write_size to 4194304 (4M)

D*. Check Pref.->general "preallocate all files"

C*. optional: Try to not use a 'partfile' (diskio.use_partfile = false)

Good luck and report back here...

[brutally]

Get a program called "Process Hacker" ->install -> run it

http://sourceforge.net/projects/processhacker/

Look for utorrent.exe process in the processes list -> mouse right click -> properties -> Threads -> set all "Idle" priorities to "Normal".

Worked for me at least..

[Alucai]

This is ridiculous.

I just downloaded the latest µTorrent, version 3.2 (build 27568) and immediately, my first download, ironically the promo album the installer suggests you download, triggers the Disk Overload 100%. I've had this problem before on a different computer, so I checked the "pre-allocate files" box and increased the cache from 32MB to 320MB (128 didn't stop the overload).

Then, when that torrent and two other torrents (LibreOffice, in case you're wondering) "finished", they were stuck on "Flushing to Disk" for a good while, perhaps indefinitely, until, per a suggestion on this forum, I set diskio.use_partfile to false. Then they switched to "Seeding".

What has happened to µTorrent? It's still my favourite Bittorrent client, but one more bug and I might just switch to, say, Deluge.

[rafi]

I might just switch to, say, Deluge.

Wouldn't you miss the graphs? speed and all ? .. Just don' use the partfile for now, and you are done...

http://forum.utorrent.com/viewtopic.php?pid=673092#p673092

[Zyph]

I have tried applying all the settings suggested here by rafi and others, in addition to trying most any "solutions" I've found on the web elsewhere and nothing seems to work. Still have this issue.

uTorrent 3.2

Windows 7 Ultimate (64bit)

Tried downloading to following drive types:

WD Greens (5400-7200rpm intellispeeds)

WD Raptor (10000rpm)

External USB2.0 HDD

Have tried downloading torrents of variable sizes etc.

I have the cache value set to 1700mb and it would seem that the problem is that the data doesn't get written to the HDD from the RAM fast enough. I monitored uTorrents memory usage by having task manager open during downloads. I noticed that when the download speeds are <10mb/s the cache can usually keep up and clears significant amounts of itself before reaching the max usage (1700mb). The struggling begins already at speeds of 10-13mb/s at which point the peak of 1700mb will be eventually reached as the data isn't dumped to HDD frequently enough. When uTorrent hits ~1800mb ram usage the "disk overload" text appears at the bottom of the screen and one of two things happens.

1. All downloads drop to 0mb/s speed, the program might freeze (bad idea to click on anything, only results in the screen going white and "not responding" to occur) and after uTorrent has struggled with dumping the cache the downloads continue slowly until the cache is maxed again.

2. uTorrent simply freezes up and doesn't recover at all. Meaning you have to end the process in task manager by force. Next time you launch uTorrent all incomplete torrents will go to "checking" status for a looooong time before the downloads continue only until the cache fills up again.

Maximum download speeds I've been able to reach are ~28mb/s which only serves to fill up the cache even faster.

When you eventually manage to finish a torrent you're stuck in "flushing to disk" phase which can take ages and after which it sometimes reverts back to "downloading" as some of the data has apparently miraculously disappeared.

I tried Deluge and everything seemed to work fine with that software, so it shouldn't be a hardware issue either. Only the thing with Deluge was that it seemed to limit my speeds by a fair amount, as I were generally getting 5-12mb/s as opposed to the ~28mb/s peaks I've been able to reach with uTorrent.

Please fix this asap! uTorrent is an excellent piece of software when it works, and with these problems gone I could see myself happily paying for the Plus version also!

As sad as it is, I might have to stick with another software until this is resolved, as even with the slower speeds on Deluge I think I'll still complete torrents faster as there's no need to reboot the software and run re-checks for packs afterwards...

[rafi]

Still have this issue.

I see similar results. They improve dramatically with single file torrents. Using the maximum cache is a bad idea. 128-256M are enough. They definitely need to improve IO performance for high speeds.

[Zyph]

Using the maximum cache is a bad idea. 128-256M are enough.

Oh?

I just figured somehow that more would be better, but in the end it's just postponing the problem occurring. :/

Ended up using that large cache as it allows me to download <1.7gb files with maximum speed without getting disk overload. Granted I'll still be stuck in "flushing to disk" after that... Frustrating

[Kitsoran]

So apparently it aint enough :