Zarggg

Edit: Never mind. Apparently I have reading comprehension issues and was trying to check against a similarly-named directory that contains likewise similarly-named files (but very different in content).

Just changed from 3.1.3 to 3.2RC1 and I'm noticing a lot of "recvfrom: delaying synchronous recv" in the console log. Is this normal? If so, which logging entry would I need to turn off to remove it from the log?

It's actually quite simple: 3.1.x is the current release version. As bugs and other issues are fixed, the third number in the version number is increased. 3.2 is the current beta version. This will become the new release version when the developers feel that it is stable enough to go into wide release. 3.3 is the current alpha version. These builds are not expected to be fully stable and are used to test features that may become part of the software later. When 3.2 becomes the release version, 3.3 will move into beta, and 3.4 will become the next alpha (if I'm remembering how these guys handle that properly). 2.x.x is an unsupported version that may have unresolved bugs and security holes that no one will be able to help you with.

ignore

Can we please have the crowd that are willing to move back to old, unsupported versions banned from the forum (or at least the "announcements" section), since they obviously have no interest in contributing to uTorrent's improvement? </rant> :/

I am experiencing this issue as well. In response to Rafi's reply on the matter, I do not use any "default directory" settings.

I second this suggestion, primarily due to UI consistency.

The point is "switch to an earlier, unsupported version of the program" is not a valid solution. Switching to an older version to "circumvent" issues doesn't actually help solve those issues for other people. On the topic of Magnet links, will it ever be possible to see the file list using them? Or is that a limitation of the format?

DHT connects just fine on my end. It's likely an issue with your internet connection or router/firewall.

I used to have an issue like the one reported here that required me to reboot my router occasionally. However, the root of the problem was the firmware being unable to handle the volume of connections generated by normal BitTorrent traffic. In effect, the router locked up until it was hard-booted.

This is probably not a bug, but as I don't look at the logger often, it struck me as odd. I got the "[iP address] did not pick any blocks. blocking peer temporarily" message thirteen times in a row (same IP, each message timestamped one second apart). Is this normal behavior? Using build 26671.

Has there been any progress on the "unsupported torrent size" bug?

I haven't been really following development lately, so I was wondering if the piece checking (when using "Force Re-check") had any major changes. I have a couple large torrents (>5GB, one is nearly a terabyte) that I only have partially downloaded (for bandwidth and disk storage reasons), and whenever I try to do a recheck on them, they cause uTorrent to become non-responsive and I sometimes have to kill the process. Does anyone know what's going on here? Edit: I should add that the non-responsiveness does not occur in 3.0. OS is Windows 7.

Without any other information, my best guess is that uTorrent is trying to take control of ports that ICQ/Jabber were already using.

Firefox handles this quite nicely. If you use the "Open All in Tabs" function, once you get past a certain threshold it asks you "This action will open X new tabs. Are you sure you want to do this?"

That's a common error that essentially means that uTorrent was not able to complete a connection. I think all the speedtest servers that uTorrent uses are returning this error.

For legitimate (read: non-illegal) use of the program, the peer list can help diagnose setting and network errors. For illegitimate (read: illegal) use of the program... well, those users don't really have the high ground to make this kind of request. For those who simply are concerned with privacy, unfortunately for them, peer-to-peer data transfer requires IP-specific connections.

The 32-bit version of uTorrent installs in \Program Files (x86)\ by default, while the 64-bit version installs in \Program Files\ by default and updates the shortcuts on the Desktop, Programs menu, and Quick Launch. Are you meaning if you run the installer while you have uTorrent running? Why would you do that? Edit: I just noticed that the program does not have a taskbar icon; it uses the default Windows "no defined icon" icon.

I just tried to install over 2.2.1 and had the following two issues: 1) The new version did not load all the completed torrents from AppData. I have 40 torrents there -- all "completed" and seeding -- but the program only loaded 15. I cannot see an apparent pattern to describe the ones it picked. (previously reported) 2) While trying to load the missing torrents back into the program, I was hit by the dreaded graphics corruption bug (dialog windows randomly turn black and the menu bar randomly vanishes). This bug also affects all other applications until I close uTorrent. (previously reported) Until #2 is fixed, there's not going to be much I can do, as it renders Windows nearly unusable while uTorrent is running. Once that has been isolated and fixed, I will be happy to test this beta more. I regret that I can't really contribute much to that bug, as I have no idea what causes this sort of thing.

Will the 64-bit build be included in the beta, or is it just the 32-bit build?

By that logic, all "bad things" should be allowed based solely on the condition that they have not yet happened to you. The devs are making the right decision here.

How else would you expect uTorrent to delete files you told it to delete?

I still can't believe that people are considering the skin and the "convenience" of having THOUSANDS of torrents loaded in the program to be more important than security and protocol issues.

I think he means BT Group, formerly known as British Telecom.

They probably don't have it set up to update to 2.2 from 2.0.4.