TraderJones
-
Posts
85 -
Joined
-
Last visited
Content Type
Profiles
Forums
Gallery
Downloads
Events
Blogs
Store
Posts posted by TraderJones
-
-
look up, the RC was changed to stable for a few hours yesterday and now is back to RC
-
the version was rolled back to RC again?
-
Devs aren't fully aware... many users.
You think? Maybe we are not fully aware hiw 'many" there really are? Maybe those users here represent only 0.1% of the overall total? They do have better stats then we have' date=' don't they?
Ever since the dev team "updated" the disk i/o subsystem there have been problemsI guess that's the price you pay for "progress" ... ;p No one is forcing you to upgrade...
But how is it "progress" when if I "move" a 20Mb torrent within uTorrent 3x it takes 5 minutes. If I simply copy the folder using explorer it takes 5 seconds (+time to re-point uTorrent). It's very apparent they have something incorrectly implemented in the "new" disk i/o. I've used and written a lot of software that included the copying/moving of files and nothing I've ever done is as slow as the current disk i/o in utorrent....
-
bt.save_resume_rate
Clean up your "act"... having more then 10-20 active torrent is really not advised...
But, resume file should be written to also per all user/state related events
This is an annoying behavior that started with version 3.3. It's been mentioned a couple times but I don't remember anyone determining that it's likely tied to the Save_Resume_Rate. It shouldn't freeze the client for 30 seconds to save the resume.dat file when it's not that large (~5Mb). Ever since the dev team "updated" the disk i/o subsystem there have been problems when writing to disk, both torrent data and now it appears resume.dat. The devs need to wrap their heads around the fact that many of the users frequently have > 20 torrents in the client.
-
*sigh* 3.3.1.29638 crashes too, I'll restate specs again: W7 x64, 16GB RAM, i5-3570k, Avast 8.0.1489 antivirus (crashes happened with v7 and other v8's), Comodo Firewall 5.10. 3.2.3.28705 is the last version that doesn't crash for me, seems anything in the 3.3 and 3.3.1 branch crashes. 3.2.3 I can leave running for days, 3.3 and 3.3.1 crash after an hour or two. I tried your settings a few versions ago, crash. Haven't run as admin, but I don't see how admin will fix it. ATM I'm not going to do admin and 3.3 or 3.3.1 b/c I'm going to leave this unattended so I'll be running 3.2.3. Let me know if you need any other specs/software.
I never had good luck with Comodo and torrenting. I don't know if the newer versions are better, but I found they couldn't handle the load. Try disabling the firewall for a few hours.
-
6881 is fine. It is recommended to use higher port #s since many ports under 10000 are pre-allocated by other apps.
If you connect to just about any site running TBdev derivative code you'll find that 6881 (and most of the ports below 10000) are blocked by default. Most of the coders on those sites aren't even aware that the default config blocks these ports.
I can't speak to other codebases but for TBdev the "standard" port blacklist includes 411, 413, 1214, 4662, 6881-6889, 6346, 6347 and 6699. Most sites recommend using ports over 10000.
-
A blacklist is a much saner way to operate, imo. At least a blacklist for specific versions, even if there is a whitelist for specific clients.
Hey we actually agree on something....
It takes a bit more work, but the sites that do this are much easier to deal with.
-
yeah, right..... another example of "customer service"
-
Unfortunately the QA process for uTorrent sucks. From an external viewpoint it simply doesn't exist, forcing private trackers to whitelist or blacklist by build number. The sites would prefer not to have to do this, but until they can depend on releases being adequately tested before release I don't see much change. I agree with Rafi that a better use of version numbers would be far preferable to the current practice.
Calling the private trackers "stupid", "backward" and so forth is completely non-productive. Fixing the QA process and addressing the concerns will go a lot further.
-
You can say whatever you like on those sites. Regardless, the fact remains that publishing latest build numbers in the history/log (to be in sync with what the user see in the help->about, is done in all professional applications/sites. I'm sure the devs here do not want BT Inc to be looked as a bunch of amatures... An this is one of those small things that makes the difference!
My 2 cents....
As a professional developer and a holder of certifications in software development I wholeheartedly agree with Rafi on this. It may seem like a minor issue, but not supplying complete and timely changelogs is part of projecting a professional appearance [and one that I'm sadly just as guilty of at times]. This point has been raised multiple times. Sites that restrict based on the versions and builds need this to be done, how else are they to keep their configurations up to date?
-
will build 22450 be put in the auto update anytime soon?
-
And before I forget, a big thank you for backporting the patch....
-
Another case. My 2.0.4 connected to 2 peers using 2.0.4 on the same ISP (them) and transfering TCP. When I enable uTP, the transfer continues to one of them. To the other, the transfer drops to 0. In my opinion uTP needs more testing.
It could be that one has the firewall/router configured correctly and the other doesn't, or that one's router can't handle uTP well. There's a number of reasons other than bad ISPs that need to be addressed by the end user. I'm not saying the uTP implementation is perfect, just that there's more possible issues out there.
-
about half of the 2.0.x clients that I've seen over the last 48 hours now exhibit the behavior of this bug now.... so much for a "small number" of users affected.
(and I've restarted my system and the router to make sure it's not something on my side).
-
Since it only actually affects a very small number of users, we aren't going to backport it. Furthermore, 2.2 is on track to going RC soon, so it's not worth releasing a new 2.0.4.
2.0.4 represents 80% of the clients on several sites I follow, both public and private. Many members leave their computers on for days, even weeks, so how can you brush this off as affecting a small number of users?
As Rafi pointed out, it's not a huge fix.
-
Keep running. Let us know what happens in day 22+ in respect to your uTP transfers' performance.
After 21 days the problems start. I restarted my uTorrent and that helped some. I happened to have contact with a couple seeders that I was connected to at the time the problem started and they had to restart 2.0.4 as well.
Just to summarize the issue, my uT would connect via UTP download a bit, stall, disconnect, reconnect via TCP download a bit, stall, disconnect, connect UTP, and repeat.
Since 2.0.4 is the only current "stable" release I would think that the devs really need to reconsider the decision to back port such a serious bugfix. If 2.2 was not still in beta I wouldn't put this out there, but a large number of sites still will not allow betas and having such a performance bug in production code will further degrade the standing of uT in the user community.
-
lol, we'll see if xp can last that long....
-
Is anyone experiencing memory leaks with this release.. since 204 Im having to reboot XP daily but 202 could run without a issue. Im not hundred percent sure its utorrent or another app or nod or nortons doing it, but maybe others have the same problem.
general issues is pulldowns wont work and sometimes out of resources happens despite i have tried forcing a increase in the reg tweak
I've had 2.0.4 running for 18 days, no noticiable memory leaks or transfer slowdowns. 50Mb memory with 77Mb VM usage.
-
One of the devs has reported a uTP issue with 2.04 after about 3 weeks - where packets were not acked properly on computers which had been up for a long time.
Maybe it has to do with the same root cause
Any particular build associated with this problem?
-
I just had a thought, when the program is run out of the installer it may not have the same user/system rights as when it's executed from a shortcut. The user space it's running in out of the installer may not have the correct permissions to allow the firewall to update. If that's the case the firewall rules might properly update when it's run via the normal menu or desktop links with the correct user associations.
-
Rafi, I've only had to renew the firewall entry once out of multiple upgrades. I'm not sure what the defining issue is, but the firewall rules failing to update and blocking a new version seems to be the exception rather than the rule.
Most people who encounter this find it rather frustrating as there's no firm indication what the issue is. They've upgraded before and not had to do anything, so the most direct thought is a problem with the newer version rather than the firewall.
-
They're all official builds.
Thank you.
Based on the earlier thread I had gotten the impression that at least 21777 was not an official build.
-
never mind.
(pointing people back to the vague earlier comments that caused the confusion in the first place doesn't help much).
-
research the changelogs
(A: 20664)Right, I know that, I also know that the changelog doesn't always get updates. We also know (from earlier in this thread) that a later build was released and pulled back (20683?). Are 20683 and 21777 not "official" builds from uTorrent?
(A: 20664)
µTorrent 3.3.1 Stable
in Announcements
Posted
change log for build 29835? Asking too much?