CphD
-
Posts
84 -
Joined
-
Last visited
Content Type
Profiles
Forums
Gallery
Downloads
Events
Blogs
Store
Posts posted by CphD
-
-
µTorrent Stable (3.4 build 30596)
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.
Changelog:
-- 2014-1-31: Version 3.4 (build 30596) Stable
-- 2014-1-31: Version 3.4 (build 30543) RC5- Fix: Speed improvement for fast downloaders (Cache coalescing)
- Fix: Don't use so much CPU when seeding uTP (BEP40 performance improvement)
- Change: New icons for .torrent document icon
- Fix: uTorrent did not display "Moving" as a torrent status
- Change: torrent document icon is now different than uTorrent executable icon
- Change: CPU reduction during uTP download and seeding.
-
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. -
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.
-
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)
-
I'm attempting to offer coherent feedback here,
...which has been clearly presented and convincingly argued, IMO,
If you think my feedback is dumb, then ignore it. ESPECIALLY since you're not even a dev, and it's not specifically aimed at you.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.
"I treat(ed) everybody with the same disrepect"Distinction in equanimous disdain doesn't equate to a superior opinion - only self-absorption.
-
Since I paid nothing, that means they're perfectly entitled to ignore the hell out of me, but I will not be shouted down by you.
+1 Makes many program annoyances tolerable by comparison (;= opinionated static), apparently the price of admission to glean useful information amid the noise.
-
I guess no one thought of that in marketing...
Careful :|. If we gloat they'll remove relevant advanced settings as revenge - http://forum.utorrent.com/viewtopic.php?pid=694166#p694166
-
I don't understand the point of setting a minimum size, anyway.
It's corporate-think - promotional ad copy real estate (assuming it hasn't been disabled).
-
Certainly. I already have it dragged to its absolute minimum, so why would i want it any bigger?
+1 :: exactly!
Well I don't see any difference in width of the sidebar when it is at minimum width. and comparing a screen shot I have it looks more like it is the left side status bar panel that has moved and is making it appear that the sidebar has reduced in minimum width.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.
-
Maybe there are none, and it was released with no changes at all. (Yeah right I know, not likely to happen, EVER)
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.
-
Andreasvb wrote:
If it's a file lock you can try with Unlocker and see which process that locks the file(s).
I've downloaded that app and I will look at it the next time I have a failure to see if I can come up with any more diagnostic information.
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.
-
Excuse me? ... Was it actually fixed @29569? No. Someone has screwed up. They've fixed his broken "fix" only @29704, so they should log it as: "29704: ... sorry. it's fixed now..
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)
. -
It's a regression due to the file locks which continue long after the the download is removed from uTorrent, interfering with the delete call it's supposed to make at the same time.
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 .
-
Version 3.3.1 RC 1 (build 29704)
The default cache size is now 128MB
Not mentioning it in the changelog is not that nice' date=' tho ...
[/quote']
You need to deduce innuendo:
--2013-04-18: Version 3.3.1 (build 29569)- Fix: Change default utorrent disk cache size to mitigate "Disk overload" condition
-
vze2mp9g wrote:
Seriously now, can you get uTorrent to display multiple detail windows within uTorrent?
He told you how he did it. 90 seconds tops to do once Photoshop is launched
~90 seconds to reduce clutter (PSP 3.12). It could be a useful GUI option, but better devs concentrate on code which seems improved in the past 2-3 weeks. Or am I delusional?
-
Uhm... Lately it's working pretty well, as it seems.
Other than several stealth 5 GB d/ls, I agree. Wonder what went right (for a change)?
-
vze2mp9g wrote:
I like how you have multiple detail windows open in uTorrent
Use Photoshop... lol... But yeah, it is useful smile
Can't kid a kidder.
One for the UID suggestion box. -
Some time ago you could select to enable a test feature before you install the program, it was called Distributed Share and there is an option for it:
distributed_share.enable
Just in case I've disabled it and so far no more strange big files with the hidden label.
Thanks for the suggestion. A fairly nebulous description in the Help file:
distributed_share.enable: This option enables the participation in distributed backups 3.3It hasn't recurred since yesterday but I'll disable it for good measure. It sounds useless.
-
Double check that you've disabled all the "offers" options in advanced. If you do not know what I'm talking about - just use my settings.
They've been disabled continuously and don't seem to have reverted w/ 29678 update so I think its a recent (mistaken undeleted test code) change,
http://forum.utorrent.com/viewtopic.php?pid=694166#p694166 All are disabled except bt.enable_pulse which seems superfluous + I don't want ratings or comments enabled.
bt.enable_pulse: Enabling this option effects ratings, and disables comments too.Or am I reading this wrong?
-
Some noticed it in the Mac client, which is being investigated on here: http://forum.utorrent.com/viewtopic.php?id=135684 [ µTorrent downloading huge files I did not add ]
Thanks for the info. Probably a test file not disabled before release. All clients were 3.3.1 or 3.4.
-
5-6 minutes after any torrent d/l completes a hidden (magnet) 5 GB file (bigbad.txt) begins to force d/load to the uTorrent share folder. Repeated 3 times since 29678 update. I've stopped and deleted at 3% each time. Anyone else seeing this or have an Idea what it is?
http://farm8.staticflickr.com/7294/8734882267_6546a3cdab_o.png
-
As sometimes I'll limit it to 100kB/p but it'll still be hitting 110 which really destroys my ping in game.
Confirmed, but +/- 7-9% over limit is a vast improvement from 100-150%
Baby steps... -
-
So, it should be better, right? Minus all the issues related to uTP... tongue
Affirmative, as long as you don't attempt to (intuitively) uncheck Enable bandwidth management [uTP] which pegs one CPU core and slows UI response by 95%, eventually producing unrestrained u/l rate limits (again)
At least in my experience 3.3.2 remains 99.9% IO error-free compared to current beta buggies.
Do you use a 2.x or older version of uT?
in Announcements
Posted · Edited by CphD
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.