CphD

Established Members
  • Content Count

    84
  • Joined

  • Last visited

Community Reputation

1 Neutral

About CphD

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I revisited this version after growing weary of confusing, multi-daily updates to current builds based on different development branches, all with glaring bugs that never seem to be addressed as developers relentlessly insert and then fine-tune superfluous "social-centric" features. Other than the mysterious, uncontrollable growth of DHT nodes from 400-700 (normal) to 1900+ and missing read cache data in disk statistic graphs that I recall at the time, I'd never globally limited d/l rates when it was a current release. Since reinstalling last week I needed to restrict a d/l that was choking my 300 kBs service to an Android TV media box and discovered that resetting the d/l limit two or three times corrected the problem of it killing all traffic. Check it out. Considering bugs and workarounds in the current stable and beta, I consider this a minor inconvenience. I continue to test new releases hoping for core improvement that has been mostly illusory, but this build was definitely a sweet spot; far fewer advanced offer.* settings needed to restrict / disable to avoid introduction of more annoyances and potential privacy issues, with several GUI benefits that don't seem to have degraded performance compared to what I consider the all-time bulletproof 2.2.1 or earlier standards. Thanks for bringing it to our attention.
  2. Same as RC build posted on 2/15. http://forum.utorrent.com/topic/82045-%C2%B5torrent-34-rc/page-61#entry480195 Apparently stable for weeks per (revised) updated changelog.
  3. No extended support, huh? OK, thanks for the heads up. At least in my experience 3.3.2 remains 99.9% IO error-free compared to current beta buggies.
  4. I assume you've checked Bandwidth Prefs to see if any settings were inadvertently (mysteriously) changed; in particular that Alternate upload rate when not downloading is unchecked. Every build of 3.3.2 has deselected Confirm when deleting trackers whenever updating / reinstalling over a previous build. Possibly someone (Rafi) knows of a stealth (Shift+F2 > Preferences) advanced setting state that may be responsible.
  5. Cannot confirm. 30586 seems well behaved relative to 3.3.2 history. Still questioning 2,000+ DHT nodes vs. 3-400 pre-3.3.1. (on XP3)
  6. ...which has been clearly presented and convincingly argued, IMO, Accept a candid character admission to avoid argumentative static and, as you've stated, focus on what may impact a design modification, despite contrary, foregone conclusions. Distinction in equanimous disdain doesn't equate to a superior opinion - only self-absorption.
  7. +1 Makes many program annoyances tolerable by comparison (;= opinionated static), apparently the price of admission to glean useful information amid the noise.
  8. Careful :|. If we gloat they'll remove relevant advanced settings as revenge - http://forum.utorrent.com/viewtopic.php?pid=694166#p694166
  9. It's corporate-think - promotional ad copy real estate (assuming it hasn't been disabled).
  10. +1 :: exactly! An optical delusion, Ciao. Nothing to do with the status bar panel and 3.3.0-29544 wasn't at issue. Comparing 2.2.1-25302, 3.3.1-29719 and 3.3.1-29756. When in doubt (or asserting a claim to the contrary), measure.
  11. Here are a couple "noteworthy" changes for 29756: The .exe inflated 24% (226 KB), hefty by even BitTorrent bloat standards for an incremental release, the equivalent of v 1.7.7. Maybe it's optionally accessible as the slimmed down client via secret F-key combination? The min. category list pane width expanded another 20 px. Soon we can concentrate on full-size advertisements and ignore trifling torrent job details altogether as they're displaced off screen.
  12. It's always uTorrent.exe that locks the path preventing deletion. In this case one of three torrents are frozen when checking with Unlocker, all of which are active and past seeding goals. As reported, it frequently happens (20-25% of the time) even when attempting to delete inactive, completed torrents before restarting the client.
  13. The default was changed to 128 on 29569 (Advanced > Disk Cache) except it never accurately reflected in Speed > Disk Statistics until 29704. Wasn't it caching 128 MB at that point? If not, technically you're correct (but picking nits) .
  14. If you check the log after each deletion it alerts the errors. Occurs 20-25% on avg, some that were stopped > 24 hrs w/o restarting the client .
  15. Not mentioning it in the changelog is not that nice' date=' tho ... [/quote'] You need to deduce innuendo: