osm0sis

I meant more like streamlining the codebase (making it more like it used to be) and keeping the buggier features isolated in the Plus version where they won't cause us any trouble, not the actual size of the program.

Any chance Share and Devices will be µTorrent+ only? I think most would agree it'd be nice to keep the "lite" version light.

I figured it out, my dummy "apps" blank file (to prevent uTorrent downloading all the garbage in that folder that I don't use) was crashing it. This didn't happen in 26419, and I prefer it that way. Dummy files for "cache" and "dlimagecache" don't seem to cause any problem. The torrent list icons (gui.show_status_icon_in_dl_list = *true) don't show, but will once you disable and reenable that setting. When the program is restarted it goes back to not showing them though.

"Stuck" peices in Disk Cache + Force recheck = Hang.

It also sticks at 99% until the "stuck" completed pieces get written out of the disk cache too, which can take awhile depending how overloaded it got - which is why my money is still on a problem with it not writing out completed pieces immediately; could also be related to hashing since it might be having trouble realizing the pieces are completed if it's checking them wrong.

Doesn't run, period. Lots of dumps sent. The window does pop up before several of the crashes and I can see that the icons in the Name column are gone even though I know I set that in Advanced. Still crashed after I removed my settings.dat ... How did this get rolled out to the Autoupdater? Luckily the old 26419 exe was still under Program Files\uTorrent as a .tmp file so I rolled back.

Mm yeah, I take it all back, just had 3 torrents get stuck at 99%, 512kB piece size. Then when I stopped them and hit Force Recheck for all 3 µTorrent froze with Disk Overloaded 100%. Had to kill it in Task Manager... Reopened and it still has the crash bug of forgetting window width and torrent list height.. So yeah, reopening it started to redownload all 3 again, and of course Disk Overloaded 100% again.. 192/32mb on the Disk Statistics tab... not good, not good. "Stuck" peices in Disk Cache + Force recheck = Hang. Hang + Kill process = Forgotten window width and torrent list height. Disk overload is definitely a µTorrent problem since I have paused all torrents except one and watched the write cache fill up to Disk Overloaded 100%, then I pause that torrent too. The Pieces tab stays full of completed pieces (32/32 blocks completed on many pieces) for ages, then, even though there is 0 other activitiy on this disk, it slowly writes them out, showing as sawteeth (from 0 to 128kB) on the right write graph (currently showing from 0 to 1). Is this a hashing issue? Why aren't these "finished pieces" getting written immediately as the Disk Cache options state? Looks like they're being written out as "untouched blocks" every 2 minutes instead, no?

Cache also doesn't seem to ever empty still and I get Disk overloaded 100% fairly regularly since 3.x, not so the case with 2.x - 3.1 does seem to improve the situation, but 3.0 was terribly broken... Edit: Very pleased with build 26419 (beta now? changelog?). Much better than the alpha build I'd tried a while back. Disk cache seems to behave a lot better (or at least it doesn't reach disk overload), I can still turn off/trick uTorrent into not using all the new features I dislike (advanced options, appstore to about:blank, making dummy files to block creation of apps/cache folders, etc.); overall it's looking great! I even set resume.dir_only = *true and that seems to be working very well. Here's a bug: gui.tall_category_list = *false breaks the sizing of the torrent list vs. the details pane. Also even when gui.tall_category_list = true the category list can't be resized smaller than a certain width. Another possible bug?: When torrent with small peice sizes reach endgame mode I'm getting a lot of hash fails, even though the peers it's receiving from are µTorrent 2.2.1+. This would explain why people are seeing a lot of torrents "stuck" at 99%, no? Might also just be small peice size torrents in general with hash fails. The two I'm on right now have a 128 kB peice size.

Exactly. Pushing releases out of the gate before they're stable, and then moving on to insane new features which introduce more problems before ironing out the old bugs; This just makes it way harder to track which regressions happened when and decreases the likelihood of ever getting back to stable in the long run.

Why does BitTorrent Inc. seem to think it's worth spending developer time on "Device Integration" and "Share" - odds are these will be used by a small minority of people - and not on some truly great ideas that will help the majority of users, like Arvid's "Tracker Exchange" / BEP 28? qBitTorrent has already implemented a version of TEX. ...Also these 3.1 promises and ongoing issues. Should they not also be carried forward from release to release? They are no less relevant now than they were for 3.0.

Maybe once 3.0 is stable

Hmm what about all of these: http://forum.utorrent.com/viewtopic.php?pid=588848#p588848 ? :/ If that columns upgrade fix is coming down the pipes I'll be happy to test it on a couple of machines I haven't updated from 2.2.x yet..

My guess is it'll be a prominent link to µTorrent Plus..

On a 28gb torrent where I've only not skipped downloading a 4mb file, it shouldn't take 3 hours to recheck the whole thing. Perhaps a file-exists check to save some time first?

Hmm surprised! I guess it's an IE9 issue with favicons behind auth as I believe the last time I saw it work with the WebUI was with IE8.. I think the standard is favicons sitting at the root of the server which posses a problem with the rest of the UI being behind /gui/ so that might explain the location issue at least..

Any further thought on my idea for WebUI Windows 7 taskbar integration? With a nice hi-res icon you could pin it to the Windows 7 taskbar and then have the following available: Media player-like controls could be used to play/pause/stop torrents, status notification overlays could be used to show active # of torrents, jumplists to access tabs/options!

Indeed. The current 3.0 download links have been replaced by a new 2.21 build.. :/

What happened to the changes that made the promo not affect the build number? I remember those from way back in the 3.0 alphas: -- 2011-02-23: Version 3.0 (build 24823) - Feature: make the content offer in the installer dynamic (no more re-builds for updating content offer)

Bug: If Windows is shut off abruptly (I just had a power outtage, but have observed this behavior from utorrent on several other occasions) while uTorrent is running, the horizontal width gets reset.

It seems the favicon.ico has gone missing in the latest version of the webui. Any chance of getting a nice hi-res one for IE9's newtab page/taskbar pinning? ALSO .. JUST had this thought as I was typing: Would Windows 7 taskbar integration be possible? I know media player-like controls, status notification overlays, jumplists and other neat tricks are all possible now!

Yes. Note the future tense of my sentence in "looking forward" and "3.1"

All these specific ones are resolved in the latest builds, except mine, sort of.. With "Start µTorrent when Windows Starts", "Start Minimized" under General, and only "Always show tray icon" under UI Settings µTorrent now shows up in the taskbar correctly, but the tray icon is missing until one unchecks/rechecks Always show.. Thanks for the ongoing work! I look forward to more fixes in 3.1 (I kept 2 installs at 2.2.1 to test the column resetting fixes appropriately ).

Known issue (under "WILL attempt"). For now, set net.low_cpu = true.

Removing all the search engines in the preferences should make it go away. I know that used to work but not anymore. Yup' date=' this was in my original list of bugs (#8).