osm0sis

Established Members
  • Content Count

    808
  • Joined

  • Last visited

Posts posted by osm0sis


  1. 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.

    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.


  2. 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.


  3. 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.


  4. 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?


  5. 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.


  6. Focus on "Devices" feature and a new "resume" system before performance and bug-fixes - completely messes up this release (GUI, cache and much more). This is, in fact, regressing uTorrent instead of improving the 3.0 line as planned :(

    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.


  7. 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.


  8. Not happening. IE is retarded, and I don't care enough to work around its bugs.

    What is it this time? It doesn't seem to request whatever favicon.ico I tell it to pick up because the icon sits behind HTTP authentication. Sniffing the traffic indicates that it tries to retrieve the icon without HTTP authentication (and from the wrong location), fails, and just decides to give up.

    IE is notorious for having problems with favicon (search the Internets if you'd like), so I'm in no way surprised.

    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..


  9. 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!


  10. We generally don't post changelogs for short-lived builds or installer-only builds. Proper releases get changelogs at the same time they're posted though.

    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)


  11. 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 :o .. 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! :D


  12. 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 :D).