thanks for all the feedback on 3.1 so far. These are the theories we're working on right now. Feel free to comment on this if you have some relevant evidence that may contradict this. The disk subsystem appears to be slow, which causes a number of symptoms: 1. Stuck at 99.9% (which is a special case to mean "we're done downloading, now we're just waiting for all the pieces in the write cache to be flushed to disk"). This mode has been changed to be an explicit torrent status. It will even tell you the number of disk jobs left to be flushed (this is in the next release, as soon as firon gets around to putting it up). 2. stuck at checking 0%, similarly, if the disk subsystem is slow, the read jobs won't return very soon and may get stalled for quite a while. There was also a GUI bug causing checking torrent specifically to be a bit messed up (also fixed in the coming RC2). Also, keep in mind that we only check one torrent at a time, if you force recheck all your torrents, it's only expected that one of them actually are moving. I think it would make sense to make this torrent state more explicit as well, by making the idle ones say "queued checking" or something. Now, why would the disk io subsystem be slow (or even lock up?). I'm not entirely sure. If anyone get a legitimate hang, where there's no disk activity and uT is still not able to flush, please dump the process, record its build number and post it here so I can figure out what it's doing. There are however a few factors that we've seen that may contribute to the disk io being slow: 1. sparse_files are not used by default. This means, whenever you start downloading a 5 Gig file, the first flush to disk will block, and windows will write 2.5 Gigs of zeroes to the filesystem on average. This can take quite a while on a normal laptop hard drive, several minutes actually. When windows is doing this, it's holding up uT's disk thread, causing disk overload to reach 100% (as soon as the write cache fills up). There's no clear communication in the UI that this is going on, and it may appear to be a bug. I think the first thing to do is to improve user messaging of what's going on. We've also turned on sparse files by default on win7+, this will eliminate the up-front cost of downloading a large file. 2. with vista, uTorrent will set its disk I/O priority level to below normal. This is to not interfere with interactive applications that may need more urgent access to the disk. If another application is doing a lot of consistent disk I/O, on vista and win7, uTorrent is likely to get much lower rate of disk operation completion. Especially when shutting down this might be annoying, since persistent disk I/O from other applications may stall the utorrent process from terminating indefinitely. One we we're mitigating this is to bump our I/O priority back to normal once we start the shutdown sequence, and flushing the cache. 3. files used to be opened in unbuffered mode when being written to, by default (this change was introduced somewhere in 2.2 or 3.0 iirc). Benchmarks on a win7 laptop suggests that this would impact write speed negatively. We've changed the default for this back to what it was pre 2.2, to not open files for writing in unbuffered mode. We made a few improvements to the disk I/O subsystem before the RC, mostly simplification and deleting logic that wasn't necessary, as well as fixing a bug introduced a few months earlier causing it to flush the whole write cache every second or so. The flushing bug would severely harm the write performance of the 3.1 betas. There was a significant seed performance improvement too. Previously, we would throw away the pieces that we downloaded as they were written to disk, and if a peer would request them, we would read them back in again. Now, we're avoiding that extra read step and just put the buffers straight into the read cache. Another improvement in 3.1 is a GUI refresh overhaul. This is all behind the scenes. We used to update the GUI in a way that did not scale very well with the number of torrents. If anyone ever tried to add 20000 torrents to uT, they probably know what I'm talking about. Our goal with 3.1 is that it should easily handle that many torrents, and now the GUI is. The one remaining issue that we're working on right now is to be able to save resume data for that many torrents, without allocating a gig of ram and stalling the GUI while saving it. This GUI overhaul is what's causing most of the GUI bugs that you've been seeing, where torrents sometimes aren't updated in the download list properly, or aren't removed when they should. The new scheme is a bit more complicated, because all changes are edge-triggered, and we might have missed some of the edges.