TraderJones

change log for build 29835? Asking too much?

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?

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

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.

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.

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.

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.

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

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

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.

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

I've had 2.0.4 running for 18 days, no noticiable memory leaks or transfer slowdowns. 50Mb memory with 77Mb VM usage.

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.

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

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?