Very weird behaviour indeed!...

Greetings people!

I can"t figure out where lies the issue so I'm hoping you wise men in this dedicated forum might come up with the answer... So here is:

As far as I can tell, the problem only applies with torrents containing many files (I have only encontered it with torrents containing hundreds or even thousands).

Symptoms : I would add such a torrent, and then no matter how many files I am _actually_ downloading out of the list of files inside the torrent (I've tried downloading only 1 while skipping all the others) the result invariably is that no downlading is actually done. It _seems_ to start, µTorrent reports that bytes are being downloaded but it never ends ("flushing to disk" continuously -- left it for 5 hours to supposedly "flush" a 30 Mb file reportedly completely downloaded!) and the destination folder is left empty except a 0 byte "~uTorrentPartFile.dat" and without any temporary downloaded ".!ut" file (even though I have "Allocate file space" checked in my preferences).

Also when I aim the download destination at my 2.5" USB external HD, as soon as starting the torrent the HD would then continuously work (led twinkling) without end (I've left it do this for hours at once when the total size of the torrent would never justifies that -- let alone with only one file in the list active and all the rest skipped!) and µTorrent, while apparently behaving normally for other possible actives torrents, would never stop making the HD work like this, EVEN when I shut the program down, ie. µTorrent apparently exists normally, but in fact remains in the running processes list of Windows and thus continues force the HD to work, so I have to kill the µTorrent process to stop that behaviour. This continuous workload of the Hd means that in a few seconds all other torrents being downloaded to the same HD dry up and stall because of a "Disc overloaded 100%", ie. the HD is monopolized by µTorrent exclusively for the problematic torrent even though not actually writing anything to it!!

When the download destination is my internal HD however, it doesn't look like the HD is working like mad this way and I don't recall having any disc overload, but µTorrent process won't accept exiting either until I kill it with the Windows process manager.

Downloading a torrent containing few files (can't say where is the line though... Maybe under a hundred or several hundreds) concludes normally.

I'm using last version (3.1) under Windows Vista (Home Premium). I never had that articular issue with previous versions so far.

Please help me, I truly hope someone among you can find how to fix this... I'm of course at your disposal for any additional infos concerning anything relevant about my computer hardware and software config as well as my particular µTorrent parameters.

Thank you all in advance for your help!!

-- Angar

140+ people checked my message and still 0 answer... Alright, maybe I didn't give enough infos/details, that must surely be it!

I have a fresh reinstall of Vista Home Premium, with no real Anti-Virus (only Microsoft Security Essentials) nor Firewall installed yet (only Windows internal firewall). I obviously checked that none of these 2 were interfering or meddling in any way with my µTorrent...

Someone kind and smart enough around here to help me with this?

I'd hate to fall back to reinstalling µTorrent 2.1.1 if I can't get the new version to work properly.

Turn off diskio.use_partfile and upgrade to 3.1.2.

Hi Firon!

Your advice seems to do the trick...

I'd thank you (and indeed I do for being the first and only so far to try and help), except that I really need the partfile option (downoading only specific files out of a torrent containing thousands would be a nightmare without it!), plus having to turn off features in order to make a client work doesn't feel neither fair nor logical. How come turning the partfile off allows me to download? Or to put it better in the opposite way: how come the partfile is an issue (and how come it is only for me?).

It's not like my hardware nor softwares (all very commonplace AFAIK) make a peculiar case of my config or anything I assume, and it seems to me that there should be an actual solution fix for this particular issue apart from merely disabling functionalities (let alone important ones!)?

So, would you have another idea (I'm not afraid of more complex ones by the way if that can help)?

Thank you and any other who would take the time to help me

(PS. I did upgrade to 3.1.2 as well as you told )

Same problem and with same app version even when I've selected only one or two items in the file list.

Wazzup widdat? And what does this msg mean anyway?

Also - where does one find diskio.use_partfile - to try 'turning it off'?

Same problem and with same app version even when I've selected only one or two items in the file list.

Wazzup widdat? And what does this msg mean anyway?

Also - where does one find diskio.use_partfile - to try 'turning it off'?

Elowan, that settings is in Preferences->Advanced. There you have a box looking like a text field, with a lot of obscure settings in the form of a list of text strings. They're ordered alphabetically, so just scroll down to 'D':s and click on diskio.use_partfile, then choose true (ON) or false (OFF) from the radio buttons under the list box.

And I'm not entirely sure, but I guess "flushing to disk" means that uTorrent is writing what it has in its cache memory to the hard disk.

According to the uTorrent help file, even though you tell the program not to download certain files in a torrent, data belonging to those files can still be mixed in the same piece with data belonging to other files, so diskio.use_partfile is used to hold this data until it can be deleted. So it's obvious that a problem arising only when not all files in a torrent are selected would be very directly associated with this option.

@Firon: The help file also says that the partfile is removed only when the torrent job is. Now, not everyone deletes their torrent jobs in a timely fashion, or ever; someone on another thread said that they kept all their inactive torrents in uTorrent against future seeding needs, and I'm rather of the same persuasion myself, so my question is, how much does the partfile bloat the torrent's diskspace, typically. I trust uTorrent doesn't download/store pieces containing only excluded data, but how much of the total would that be, on average? I guess what I'm asking is how hard does uTorrent, and other clients, try to keep data from the same file in the same pieces?

And I'm not entirely sure, but I guess "flushing to disk" means that uTorrent is writing what it has in its cache memory to the hard disk.

Yeah, as for me I AM entirely sure that's precisely what it means man!

Quoting my own entry on top of this thread: "flushing to disk" continuously -- left it for 5 hours to supposedly "flush" a 30 Mb file reportedly completely downloaded!

You can see I specifically adressed that flushing thing and explained that the need to let the flushing process complete was irrelevant to my issue (unless 30 Mb ask for MORE than 5 hours to be written to disk from cache? )

Any uTorrent technician here could come and help with this please?

Are you skipping files?

Do you have the partfile enabled?

Hey there DreadWingKnight!

Why, I CAN'T skip files! That's all the problem... :|

WHEN partfile is enabled, if I try not to D/L the full torrent from the start, then NOTHING is actually written to disk. µTorrent then reports it's downloading (at very good rates too), but the partfile remains at 0 bytes and even after Mbytes or even Gbytes are reported supposedly downloaded, all files in the list in µTorrent remain at 0 in the "Done" column + not one file is written on disk (not even temporary ".!ut" pre-allocated files). When this happen I also get Disk overload troubles at rates that shouldn't pose any problem (1 Mb/s or less) and indeed such rates are perfectly fine with µTorrent, my HD and Windows if I don't skip files when launching the torrent.

This is a real annoying situation for me, as there are many occasions when I just HAVE to skip many files in a torrent that's sometimes as big as hundreds of gigs (rush videos from friends mostly -- I'm working as a sound designer to produce video soundtracks and stuff).

If anybody can help, I'd be more than grateful. At disposal for any complementary infos about my config of course. Thanks!

-- Angar

And I'm not entirely sure' date=' but I guess "flushing to disk" means that uTorrent is writing what it has in its cache memory to the hard disk.[/quote']

Yeah, as for me I AM entirely sure that's precisely what it means man!

Quoting my own entry on top of this thread: "flushing to disk" continuously -- left it for 5 hours to supposedly "flush" a 30 Mb file reportedly completely downloaded!

Sorry Angar, that comment was directed at the post I was replying to, which especifically asked what that message meant. I did read your post, and my answer to Elewan was in fact in part based on what you said.

The part of my post that - initially - was directed at you was the one about the .use_partfile thing. At first I believed that answered your question in your second post, about why the diskio option affected your downloads, but on rereading the message before posting I thought you probably already knew at least as much, and were probably after more specific information, so I edited to keep it addressed at everyone instead.

HMM... You also said that you got disk overload errors... that makes me think... You do know, don't you, that uTorrent ALWAYS pre-allocates diskspace for the files it downloads? The way I understand it, the "Pre-allocate all files" entry in Preferences just makes the reservation of space more strict, somehow. I think that would mean that even if you're downloading a 1 Mb file out of a 2 Gb torrent, with partfile in use uTorrent would reserve all or most of the 2 Gb, causing the torrents to fill the disk with their partfiles (which aren't discarded until you actually remove their torrent jobs, and you probably won't remove the jobs until they're finsihed, which they won't be while the problem persists). Then uTorrent is probably constantly "flushing to disk" because it's looking for some space to flush the data TO, and not finding any. That COULD be it.

And I'm not entirely sure' date=' but I guess "flushing to disk" means that uTorrent is writing what it has in its cache memory to the hard disk.[/quote']

Yeah, as for me I AM entirely sure that's precisely what it means man!

Quoting my own entry on top of this thread: "flushing to disk" continuously -- left it for 5 hours to supposedly "flush" a 30 Mb file reportedly completely downloaded!

You can see I specifically adressed that flushing thing and explained that the need to let the flushing process complete was irrelevant to my issue (unless 30 Mb ask for MORE than 5 hours to be written to disk from cache? )

Any uTorrent technician here could come and help with this please?

Check this thread http://forum.utorrent.com/viewtopic.php?id=113600&p=2 ... (primarily last 6 or 7 posts)

It appears that skipping files in 3.1.2 xxxxx may be causing these overload/flushing errors... sometimes the torrent write cache will continue to build until it reaches it's capacity (auto or user set level) at this point everything will stop dead... and you will see "disk overload 100%" or "flushing to disk" (if the download has completed)... both basically mean the same thing (the cache is holding all the files and writing nothing to drive)

I've had as little as 5MB stuck in cache and as much as 100MB... (doesn't seem to matter) the cache will usually write files to disk eventually... but I've had some sit there overnight and do nothing, had to close application and start from scratch.

Try what I just did and leave ALL torrent files ticked in dialog window. I was getting errors on every download when skipping... last 2 downloads with no skipping got zero overload/flushing to disk errors... cache queue was normal through entire download. It's a pain in the ass and eats bandwidth not to mention the extra time, but until a new version comes out this may be as good as it gets.

Rush....

Thank you for your valuable inputs Northstar and Rush (named after a fantastic band I assume? )

To reply collectively on a number of points (in no specific order):

You do know, don't you, that uTorrent ALWAYS pre-allocates diskspace for the files it downloads? The way I understand it, the "Pre-allocate all files" entry in Preferences just makes the reservation of space more strict, somehow. I think that would mean that even if you're downloading a 1 Mb file out of a 2 Gb torrent, with partfile in use uTorrent would reserve all or most of the 2 Gb

Someone more knowledgeable about this, feel free to correct me, but in my experience what you're stating here is wrong: I have on countless occasions downladed a few Mbytes out of huge torrents (at times reaching 100, 200 Gb or even more...), and what I think happened (in these days when µTorrent versions were handling the job just fine ) was that only the files I selected out of the thousands present in the torrent were actually written to disk PLUS parts of skipped files adjacent to those I had selected, but that's it! I'm at least positive that, when downloading specific files from a hundred or more Gb, under no circumstances was the total size (or not even "most of it" as you said ) preallocated on my HD!! Only the size of my selected files + partfile size growing as it collected parts from skipped files adjacent to my selection. Hope this explanation is clear enough...

causing the torrents to fill the disk with their partfiles (which aren't discarded until you actually remove their torrent jobs, and you probably won't remove the jobs until they're finsihed, which they won't be while the problem persists). Then uTorrent is probably constantly "flushing to disk" because it's looking for some space to flush the data TO, and not finding any. That COULD be it.

if I got that correctly, and provided your above theory was right (though as I said I'm sure it ain't he he) that would still not explain what happens to me with most recent versions since I am downloading onto an (almost empty) 2 TeraBytes external HD, thus in your terms, µTorrent _would_ find the space it's looking for to flush data!

Try what I just did and leave ALL torrent files ticked in dialog window. I was getting errors on every download when skipping... last 2 downloads with no skipping got zero overload/flushing to disk errors... cache queue was normal through entire download. It's a pain in the ass and eats bandwidth not to mention the extra time, but until a new version comes out this may be as good as it gets.

Well, there's an alternative man: roll back to an earlier version, for instance v3.0 build25460 (as seen in one of the top entries from the thread indicated in your post above).

As I've mentioned before, disabling the partfile is just not an option, well not for me anyway (don't reckon I'd be the only one though). Not mentioning that would really bug me (once again no pun intended!) to drop features that make my life easier just because the development team comes with faulty upgrades. Nowadays competition in software production means you have the choice, and (even though I like and am used to µTorrent), I'd rather turn to another client (there are plenty others) that are just working fine and don't demand that your turn some valuable features off to in order to function. In any case, the way I use torrents -- in particular the private torrents I use with friends in order to exchange huge and numeros video sequences for an ongoing project of ours --means that disabling the cache OR not skipping any file (I confirm that I've tried and both ways seem to work alright around the issue) would have me download at times at least dozens of Gb where I'm actually needing only a few dozens of Mb of video rushes (no puns intended )!!!! That would mean as you write, waiting times (at least) x10, and I'm not talking about uselessly straining my hard-drive surface with useless content I'd have to delete right away at the end anyway, and I'm always very careful about that seeing HDs' lifetime are always rather limited and I've learned that the hard way several times.

So, between all these drawbacks and merely reversing back to a 3.0 version that works 100% fine until the dev team actually come with a new version that is usable, the maths are quite easy -- + it's not even like rolling back means missing some new features!!!

New versions recently introduced nothing except bugs (I may be wrong about that I admit: if so, thanks for listing me the new features), then I'm kinda wondering... What's the point in upgrading?

One thing I've learned from all this is :

NEVER accept the install when a new upgrade is detected!!! Always wait at least a month and check on the forum here until the upgrade has proven to be stable!

µTorrent releases used to be reliable... But everything changes it seems. :/:P

-- Angar

(PS. Firon mentionned 3 days ago that they would see to it and fix this issue for the next release, well the next release is here (build 26773) and still just as faulty as before... Therefore that's rolling back to 3.0 for me with no regrets)

Try what I just did and leave ALL torrent files ticked in dialog window. I was getting errors on every download when skipping... last 2 downloads with no skipping got zero overload/flushing to disk errors... cache queue was normal through entire download. It's a pain in the ass and eats bandwidth not to mention the extra time, but until a new version comes out this may be as good as it gets.

Well' date=' there's an alternative man: roll back to an earlier version, for instance v3.0 build25460 (as seen in one of the top entries from the thread indicated in your post above).[/quote']

We all feel your pain bro... read my 25+ posts on this bullshit in about 7 threads.... if you look at this from the uTorrent authors and admin point of view this is horrible P.R. ...there are dozens of negative threads are all over Google and can't look good to uTorrent users and any potential new users... I give them a pass as long as the problem is acknowledged and they are actively working on it (which I'm am satisfied Firon did in another thread) and we are not just asked to tick this and tweak that.... OR somehow act like the problem is users improper settings. If there is one thing I've learned from this problem is THERE ARE NO "REAL" FIXES TO THIS VER. JUST BANDAIDS. One would have to believe that they (the author/author's) are scrambling to release a new ver. which will put this to rest for good... like to hear that from the staff though and not have to just speculate.

So, between all these drawbacks and merely reversing back to a 3.0 version that works 100% fine until the dev team actually come with a new version that is usable, the maths are quite easy -- + it's not even like rolling back means missing some new features!!!

New versions recently introduced nothing except bugs (I may be wrong about that I admit: if so, thanks for listing me the new features), then I'm kinda wondering... What's the point in upgrading?

One thing I've learned from all this is :

NEVER accept the install when a new upgrade is detected!!! Always wait at least a month and check on the forum here until the upgrade has proven to be stable!

µTorrent releases used to be reliable... But everything changes it seems. :/:P

Already been doing that... quit updating about 4 builds ago.... but apparently there are many users thinking they somehow have to update or that these newest builds fix this problem (nothing can be further from the truth) if the updates don't indicate otherwise there is no reason to update to every new flavor of the latest build. Just tick no unless your particular problem is indicated in the fixes.

-- Angar

(PS. Firon mentionned 3 days ago that they would see to it and fix this issue for the next release, well the next release is here (build 26773) and still just as faulty as before... Therefore that's rolling back to 3.0 for me with no regrets)

I don't want to speculate on his statement and he (Firon) can correct this if it's wrong. I understood from previous back and forth posts in other threads that this is a complex problem and will be solved in a whole new version and NOT a build fix ie. extension 3.1.2xxxxx

Sounds like in you particular case that rollback IS the only answer... I still may do the same but I really don't download more than 1 or 2 torrents at a time so NOT skipping files isn't nearly as critical as your situation. The last couple went extremely smooth and fast... just had to waste a few hundred kB... no biggie yet.

Rush...

"Living on a lighted stage approaches the unreal

For those who think and feel

In touch with some reality beyond the gilded cage....."