[µTorrent 3.1 stable (build 26671)]

Now it's downloading directly into the cache and never writing to disk. Had a torrent ramp up and exceed the write cache by 300/32 (26000 writes To Cache) with still 0 writes To File... really weird stuff going on.

(Also I just upgraded my laptop from 2.2.1 and the columns reset issue is still very much a huge pain in the ass..)

[µTorrent 3.1 stable (build 26671)]

Set your disk cache settings back to the default. Also, existing downloaded files are all sparse and are probably fragmented to hell, so you may wanna defrag before you test more.

I have never once changed any disk cache settings from the defaults (with the possible exception of diskio.low_disk_prio which I just experimented with to see if it would help the hashfail, cache, and now hang issues). diskio.low_disk_prio = *false does appear to help mitigate the hangs so that is the only difference here, because I prefer to have it working somewhat while I test as opposed to not-at-all.

I have downloaded very little with uTorrent since you enabled Sparse in the RCs so this is most likely also not the issue at hand. Also, had the write cache go up to 970/32 trying to let my test torrent complete so I could verify the hashfail issue was gone - fantastic :/ ... and still not sure since it crashed after that.

osmosis, thanks for your bug reports. I don't think that #5 is a bug, however.

How so? With gui.tall_category_list = true I can resize the torrent list all the way down to 2.5 torrents. But with gui.tall_category_list = *false the minimum is 7.5, clearly due to the whitespace it's making in the category list, hidden or not, for the Plus upsell (and this is when gui.show_plus_upsell = *false). Before the upsell was added resizing was not affected in this way.

[µTorrent 3.1 stable (build 26671)]

Yup working on it, hence [updating..], just wanted to wedge my spot in near the top

Noting lots of hangs/mini-hangs in the "stable" build once it ramps up and exceeds cache... so it's kind of hard to test actually as it's taking a long time to get anywhere with it (758/32 cache when I finally managed to get the UI responsive long enough to Stop the slackware torrent).

diskio.low_prio_disk = *false seems to mitigate both problems somewhat and make this version usable. A few random crashes like rafi's are making an appearance though...

Edit: Happy to cede the top spot to you rafi.

[µTorrent 3.1 stable (build 26671)]

Current buglist (in no way exhaustive...)

Updated for 26616

Here are things which I've noticed in my own use of µTorrent. Don't expect to see Apps/Devices/"Other New Random Feature"-related bugs here, just ones that come up during regular every-day *torrenting* (you know, what the program was originally intended for).

I would like for this list to follow release-to-release so we all know where we stand.

Bugs introduced in 3.1:

1) Using the slackware (x86 complete) test torrent the write cache limit is massively exceeded during ramp up (420/32) when "Apply rate limit to transport overhead" is checked. Unchecked it seems worked around but there is still a write cache spike during ramp up where no actual disk writes occur. Once cache limit is reached the connection is throttled down to nothing, then after some time (anywhere from 1 to 5 minutes) the disk writes finally start, ramp up with the cache writes as they should and the throttling is decreased/stops. The throttling seems to stop File writes as well when I've seen it occur later on in a download so perhaps it is part of the problem.

2) Deleting torrent (+ data) can cause "Error: <torrent name> - The I/O operation has been aborted because of either a thread exit or an application request." and a stuck cache. It looks like it's getting rid of the queued cached writes, but even after Queued hits 0, the cache still appears exceeded/stuck and only clears with program exit. This is not an exceeded cache only issue anymore, as I have seen it stick at 296/32 and 15/32 in the "stable." Dump for stuck cache is here: uTorrentDMP.zip.

3) "ReadFile error: <filename>:1488701569:2954:1823755:19" after adding a torrent where this was a file I set to skip. Reproduction: Add a 2 file torrent where 1 file already exists fully downloaded but with a different filename. Uncheck the second (undownloaded) file in the dialog and uncheck Start torrent. Go to the Files tab and Relocate the first file to the renamed local copy. Start torrent makes it check the files. Once it gets past checking the first file, the second brings up a ReadFile error even though it is set to skip. "We will not have time to fix [this] for 3.1" - AdamK

4) Same 2 file torrent scenario but this time with the first filename matching that in the torrent. Second file still unchecked, and Start torrent is checked this time. Adding starts the torrent and causes the files to be checked. Once it gets past checking the first file, it actually goes ahead and creates the second file even though I set it to skip. "We will not have time to fix [this] for 3.1" - AdamK

5) gui.tall_category_list = *false breaks the sizing of the torrent list vs. the details pane. This is due to uTorrent acting like gui.show_plus_upsell = *true (and allocating the category list space for it) even though I have it set to false. The program must be restarted for the issue to present. Screenshot.

6) "Show a window that displays the files inside the torrent in advanced mode" should apply to Simple View since otherwise there's not much point in having the option.

Bugs introduced in 2.2/3.0 (or before):

a) Columns reset when new version has added/removed/reordered columns (one of the oldest usability bugs). "Columns [reset] on upgrade [...] We will fix this for 3.1" - AdamK

The stream/playback button lags when the horizontal scroll bars are moved. Not the flat version, the "Windows-ized" version once you click it/it becomes available.

c) CPU usage and response times are way up in general for scrolling in the torrent list.

d) Window width and torrent list height are forgotten on improper program close (eg. due to OS crash).

e) Tab reordering. You rearranged them, let us. "We are definitely going to do something about the tabs. Expect it. Don't expect it in 3.0" - AdamK

f) If ratings/comments are disabled, the dialog when removing a torrent shouldn't show up full of ratings/comments related stuff. I don't want to hide the dialog completely because I like having the failsafe of it asking me if I'm sure, but it shouldn't be asking me to rate something after I spent the time to go through all the options to disable ratings everywhere else. Basically it should just look like the multiple-torrent remove dialog when ratings have been disabled.

g) The search engine toolbar icon/box area still shows when the search engine list is empty in the Advanced options UI Extras (this is a reversion from old pre-3.x behavior). The box and icon used to disappear.

h) Icon still pops up in the Notification Area (System Tray) on program start until hovered over; this is even though all System Tray UI Settings are disabled. Other settings: Set to start minimized and start with Windows.

i) gui.color_progress_bars should apply to the Info tab and Pieces tab as well. It doesn't make sense to revert to the basic blue/etc. in one area but not these others. "That makes sense. I will run this by the non-programmers" - AdamK

As an addendum to (i): I would have no problem with the default green, etc. progress bars if they were easier to read... The gray text on downloading files needs to be black. The background colours are almost too pastel for the white text to be easily read as it is; could they also be darkened a bit?

[µTorrent 3.1 Release Candidate 11]

Autoupdated to 26586... RC10?

[µTorrent 3.1 Release Candidate 11]

I think they simply have a bug in the new hash implementation and should re-fix it . No sense checking it any more..

The hash failures turned out to be specific for the ted torrents. Probably what happened was that ted.com changed their videos (maybe new encodes)' date=' and our torrent generator did not re-generate the torrent files.[/quote']

I didn't write that , it was rafi, but I believe he was talking about the more general infinite hashfail pieces issue (#4 in my buglist post), not the TED one which FredSam43 had reported.

[µTorrent 3.1 Release Candidate 11]

Can I hide this thing anyhow?

F4 is your only option there. :/

I've been living happily without the toolbar for years.

On a separate note: RC8 still isn't up on the download servers it seems.

[µTorrent 3.1 Release Candidate 11]

Alright. A few things.. updated for RC7

1) gui.tall_category_list = *false breaks the sizing of the torrent list vs. the details pane. This is due to uTorrent acting like gui.show_plus_upsell = *true (and allocating the category list space for it) even though I have it set to false.

I set gui.tall_category_list = *false and gui.show_plus_upsell = false' date=' and this shows correctly for me on RC7. Can you check this one again, and screenshot it if it's still broken?[/quote']

It works until you close and reopen the program, then it's borked.

Thank you for finally responding to my bug reports Adam, would you also be able to acknowledge the statuses of any of my "leftover bugs" and comment? A slight tweak to the default colours (most importantly: changing the gray text to black for downloads in progress bars) is something that would really improve usability/visability.

[µTorrent 3.1 Release Candidate 11]

could you set diskio.low_prio_disk back to true?

Also' date=' can you link us to the -exact- torrent?[/quote']

I'll do my tests with RC7 tomorrow, but the -exact- torrent is slackware x86 everything ISO (my test torrent of choice): http://www.slackware.com/torrents/slackware-13.37-install-dvd.torrent

With defaults in RC7 I was still able to reproduce #3 in my buglist post (massively exceeded cache - 400/32). Deleting torrent (+ data) during this state still caused "Error: slackware-13.37-iso - The I/O operation has been aborted because of either a thread exit or an application request." and the cache remains exceeded even though the torrent has been deleted. It only clears with a program exit.

I was also able to reproduce #4 (repeated hash fails). I completely (99.9%) downloaded the slackware torrent (though the cache was exceeded to 576/32 at one point) using the default settings and got infinite hashfails on piece 240. It's worth noting that the hashfails began well before the cache was exceeded. Stop and Force Re-Check caused the torrent to become Finished at this point.

Naturally there was a bit of a performance hit to my system as µTorrent downloaded 0.5GB of this torrent into my system's limited memory ... #3 is a serious problem on any system, let alone one with only 1GB of physical memory.

And that this has been my test torrent for all cases is something that you would have gathered if you'd read my main buglist post at any point. Please go at least read and possibly respond to it, as there are dumps provided for each of these issues; instead you seem to have been actively ignoring it.

[µTorrent 3.1 Release Candidate 11]

could you set diskio.low_prio_disk back to true?

Also, can you link us to the -exact- torrent?

I'll do my tests with RC7 tomorrow, but the -exact- torrent is slackware x86 everything ISO (my test torrent of choice): http://www.slackware.com/torrents/slackware-13.37-install-dvd.torrent

[µTorrent 3.1 Release Candidate 11]

Try use these exact settings: [..] what used to make the difference was (is?): diskio.smart_sparse_hash = *false

I went ahead and changed only these in RC5: diskio.smart_sparse_hash = *false, diskio.smart_hash = *false AND diskio.low_prio_disk = *false and...

It got a LOT farther that way without a single hashfail! Up to 75% or more on the slackware x86 everything ISO (my test torrent of choice), whereas usually it would start repeat failing around 25% or less. I let it go all the way to 99.9% this time, and only 2 pieces were failing: 1224 and 2043.

The weirdest thing though is that it didn't seem to exceed the write cache with those settings, and I was downloading at 4MB/s - higher than I was previously when it would exceed!

Edit: Hold the phone! I just got autoupdated to what I presume is RC6 (26554)!

The first two of my reported RC5 regressions seem to be fixed in this new build, however, the ReadFile error checking for skipped files (after a relocation) is back, and skipped file creation is still occuring so I've added them to my main buglist post, now updated.

Please respond to the remaining items on that list. Thank you.

[µTorrent 3.1 Release Candidate 11]

Could you both try disabling diskio.smart_hash to see if your problem goes away?

Pieces 2166, 2147, 2088 of that same slackware torrent all repeatedly hashfail, even with diskio.smart_hash = *false, and again it happens more readily when diskio.low_prio_disk = *false.

[µTorrent 3.1 Release Candidate 11]

A few regressions I'm seeing using RC5:

- Nothing in the Detailed Info pane (in any tab but Logger) refreshes while I'm looking at it anymore. Status Bar also fails to update.

- It doesn't do a recheck after I used Relocate to select an existing completed file - forced me to download again.

- Adding a torrent where a file existed with the same name did do a recheck, but it created an extra file, even though I had set it to skip this file in the Add dialog.

And of course:

- Still able to reproduce the massively exceeded write cache as described in #3 of my main buglist post (dump included).

- Also still able to get it to hashfail pieces repeatedly as described in #4, so perhaps the hash issue isn't entirely fixed yet. I took a uTorrent dump while this was happening too in case it's useful. It has also been added to the post.

Please respond to the other items in that post as well. Thank you.

[µTorrent 3.1 Release Candidate 11]

Probably has to do with the generally still-lagging (broken...) nature of the whole GUI in the 3.1 "line" ...

Make that 3.x, things have never been quite as snappy since we left 2.x. Playback/streaming buttons, general scrolling, speed graphs... the list goes on.

[µTorrent 3.1 Release Candidate 11]

Make sure: Options | Streaming -> Uncheck "Use default player" and MPC is set up in the pulldown.

[µTorrent 3.1 Release Candidate 11]

Here is a work-around to get back your torrents [...] Everyone else: please do not use resume.dir_only.

No worries, I just readded them from %AppData%\uTorrent. What's the big issue with resume.dir_only? Seems to have been working pretty well.

P.S.: Cleaned up my other buglist post. That dump goes with #3 on that list now.

[µTorrent 3.1 Release Candidate 11]

Lost all my torrents on upgrade to RC4... I'm guessing due to the resume dir stuff you changed since I was using resume.dir_only = *true and got "File not found during integrity check: <%AppData%>\uTorrent\resume.dat" in the logger.. Were the hashing issues due to the resume dir or something?

Also, please respond to the remaining items in my main post.

Thank you.

[µTorrent 3.1 Release Candidate 11]

I just had a torrent get stuck in RC3 (diskio.low_prio_disk = *false, if it matters) with two 1MB pieces (64 blocks each) left in cache. Status says "Flushing to disk (128)" but then they never get flushed, even though there is no other disk activity and it is the only active torrent.

Stuck Dump: http://www.mediafire.com/?drwz5e8q1jraa87

After I created the dump I restarted my other torrent, stopping the stuck torrent, and did a Force Recheck, which caused the program to hang. Let it go for awhile to see if it would be temporary but 3 hours later, still frozen.

Hang Dump: http://www.mediafire.com/?iuns6fghrl6vs5t

Also, please respond to the remaining items in my main post: http://forum.utorrent.com/viewtopic.php?pid=620310#p620310

Thank you.

[µTorrent 3.1 Release Candidate 11]

Right, no idea what's going on. It happens at low speeds here as well, and both ways over the LAN. Maybe some other related setting. I'm on Win7/32bits, Windows write cache - unchecked (enabled/default). You?

Same. Pretty sure these are the defaults now - Basic cache settings: Reduce. Advanced: Top 6 checked, then bottom 1 checked.

[µTorrent 3.1 Release Candidate 11]

I also notice that it seems harder to exceed the write cache limits at high speeds with diskio.low_prio_disk = *false' date=' it only gets close and then mass flushes.[/quote']

Yeah, I've notice this too. I run @ 40-50+MBps... (1G LAN, close to my HD max write speed) so that might make the difference as well.

Still managed to though. 160/32. And still gets stuck with them in the cache when I delete torrent (+ data).

30Mbit/2Mbit connection, 100Mbit LAN, that shouldn't really make a difference when I'm only getting like 3.1MB/s tops (and usually more like 1.5-2.5MB/s).

[µTorrent 3.1 Release Candidate 11]

Yes I believe I did, and I just tried it again to be sure.

~2.0MB/s, ~500MB downloaded so far, 0 hashfails.

I also notice that it seems harder to exceed the write cache limits at high speeds with diskio.low_prio_disk = *false, it only gets close and then mass flushes.

Edit: You may be right! 1.5GB downloaded now, and piece 2161 (of 2167 in the slackware x86 complete torrent) is repeatedly hashfailing.

[µTorrent 3.1 Release Candidate 11]

with diskio.low_prio_disk = false ?

I have massive hash fails with adv->diskio.low_prio_disk = false at high speeds over LAN

Tried it both ways, seems to work now for me. Set to false I just tried slackware again to max out my connection (also over LAN): My system gets super laggy (old machine) but no hashfail issues. The cache sometimes remaining full of unwritten pieces after I delete a torrent (+ data) is the big issue I'm seeing now.

[µTorrent 3.1 Release Candidate 11]

Post updated for RC3, http://forum.utorrent.com/viewtopic.php?pid=620310#p620310

Couple things got fixed! Keep it up, and please respond to the remaining items in my post. Thank you.

[µTorrent 3.1 Release Candidate 11]

Post updated for RC2, please respond :|: http://forum.utorrent.com/viewtopic.php?pid=620310#p620310

Edit: Anyone but rafi

[µTorrent 3.1 Release Candidate 11]

Alright. A few things.. updated for RC9

1) gui.tall_category_list = *false breaks the sizing of the torrent list vs. the details pane. This is due to uTorrent acting like gui.show_plus_upsell = *true (and allocating the category list space for it) even though I have it set to false. The program must be restarted for the issue to present. Screenshot.

2) The category list can't be resized smaller than a certain width. Likely also due to acting like gui.show_plus_upsell = *true. "This is intentional" - AdamK

3) Using the slackware (x86 complete) test torrent I still observed it exceed the write cache limit massively (420/32). After deleting torrent (+ data) while exceeded I get "Error: <torrent name> - The I/O operation has been aborted because of either a thread exit or an application request." Then it looks like it's slowly getting rid of the queued cached writes, but even after Queued hits 0, the cache still appears exceeded (296/32) and only clears with program exit. Dump for stuck cache is here: uTorrentDMP.zip.

4) Still seeing a few pieces getting stuck hashfailing repeatedly in RC7 using the above slackware torrent; this time piece 240. Dump for repeated hashfails (7 had occured so far) is here for RC4: uTorrentDMP2.zip.

5) "ReadFile error: <filename>:1488701569:2954:1823755:19" after adding a torrent where this was a file I set to skip. Reproduction: Add a 2 file torrent where 1 file already exists fully downloaded but with a different filename. Uncheck the second (undownloaded) file in the dialog and uncheck Start torrent. Go to the Files tab and Relocate the first file to the renamed local copy. Start torrent makes it check the files. Once it gets past checking the first file, the second brings up a ReadFile error even though it is set to skip. "We will not have time to fix [this] for 3.1" - AdamK

6) Same 2 file torrent scenario but this time with the first filename matching that in the torrent. Second file still unchecked, and Start torrent is checked this time. Adding starts the torrent and causes the files to be checked. Once it gets past checking the first file, it actually goes ahead and creates the second file even though I set it to skip. "We will not have time to fix [this] for 3.1" - AdamK

Also what are the statuses of these leftover items from 3.0?:

a) "Columns [reset] on upgrade [...] We will fix this for 3.1" - AdamK

The stream/playback button lags when the horizontal scroll bars are moved. Not the flat version, the "Windows-ized" version once you click it/it becomes available.

c) Tab reordering. Is this still happening? "We are definitely going to do something about the tabs. Expect it. Don't expect it in 3.0" - AdamK

d) If ratings/comments are disabled, the dialog when removing a torrent shouldn't show up full of ratings/comments related stuff. I don't want to hide the dialog completely because I like having the failsafe of it asking me if I'm sure, but it shouldn't be asking me to rate something after I spent the time to go through all the options to disable ratings everywhere else. Basically it should just look like the multiple-torrent remove dialog when ratings have been disabled.

e) The search engine toolbar icon/box area still shows when the search engine list is empty in the Advanced options UI Extras (this is a reversion from old pre-3.x behavior).

f) Icon still pops up in the Notification Area (System Tray) on program start until hovered over; this is even though all System Tray UI Settings are disabled. Other settings: Set to start minimized and start with Windows.

g) Could gui.color_progress_bars please apply to the Info tab and maybe Pieces as well? It doesn't make sense to revert to the basic blue/etc. in one area but not these others. "That makes sense. I will run this by the non-programmers" - AdamK

As an addendum to (g): I would have no problem with the default green, etc. progress bars if they were easier to read... The gray text on downloading files needs to be black. The background colours are almost too pastel for the white text to be easily read as it is; could they also be darkened a bit?