[µTorrent 3.2.1 stable (build 28086)]

Bypassing the bug is irrelevant. It's still there until they fix it, and I always set a specific location for all my torrents.

Regardless of all that, it is still a bug that needs to be fixed irrespective of settings.

[µTorrent 3.2.1 stable (build 28086)]

What's the point in enabling it, when I'm going to be changing the directory anyway?

[µTorrent 3.2.1 stable (build 28086)]

Also, I am getting the garbled characters issue for the "Save In" input as well. Note that this only affects the initial value of the input; manually selecting a directory still works as normal.

It does not happen to me. I figured it is because I have a none default (=empty) download path set. Do you ?

"Put new downloads in:" has a directory assigned, but the feature is not enabled.

[µTorrent 3.2.1 stable (build 28086)]

I don't even know if what you're talking about is possible. I think the file selection is fine as it is.

Also, While checking that 1TB+ torrent, I've run into the issue of using up all memory twice now. I have 8GB system RAM, auto-managed virtual memory. Can anyone confirm this?

Edit: And oddly enough... third time worked. This really vexes me when I can't pin down causes and issues.

Also, I am getting the garbled characters issue for the "Save In" input as well. Note that this only affects the initial value of the input; manually selecting a directory still works as normal.

[µTorrent 3.2.1 stable (build 28086)]

Finally checking out the infamous 1TB+ torrent that people have been wanting to use with uTorrent (and it looks like that now "works" with this version), but since my HDD/ISP can only handle me downloading it in sections at a time, when I try to check portions of it, uTorrent goes completely nonresponsive while building the partfile.

[µTorrent 3.2.1 stable (build 28086)]

Hmm... point. Perhaps the contents view would be best as a separate window?

[µTorrent 3.2.1 stable (build 28086)]

I also like blstr's design. My only concern with it is how the "hiding" of the Torrent Options and Torrent Contents groups would work, as they were originally both between the top section and the action buttons and the new concept would require expanding the window horizontally and vertically.l

[µTorrent 3.2.1 stable (build 28086)]

I've been thinking over the whole multiple/single file issue and now I'm wondering why this is even an issue.

The "Contents" of a torrent functions the same way any other directory tree does. Would it not be simpler to have the user select the directory where the contained file(s) and/or directory(ies) will go and not muck about with having to decide when to make subdirectories or what to name them? We are allowed to make the assumption that a properly-created torrent will have a valid internal directory structure*; it is the user's prerogative to decide where he wants the contents to ultimately go.

I suppose my question here is, what was so wrong about the design (not the implementation) from 3.1 and earlier that necessitated this change?

* Proper implementation of the protocol/format is a precondition to this entire application. It is further reasonable to assume that a person who creates a torrent will have created subdirectories in the contents if they are necessary or not created them when they are unnecessary. In either event, since uTorrent provides the ability to view the directory tree of the files to be downloaded, need to guess at intentions is moot.

Edit: Thinking on this again in the context of my previous statment... Meddio's idea makes a lot of sense. Putting a checkbox for "Place torrent contents in a subfolder with this name" would be an easy solution.

[µTorrent 3.2.1 stable (build 28086)]

Screenshots showing exactly what you see would be helpful in cases like that.

[µTorrent 3.2 stable (27568)]

Registered: How does uTorrent know you moved them/it manually? uTorrent cannot simply go by the name of the file, nor its size or file type. Any file can have any name. uTorrent cannot know if you have downloaded multiple torrents that include the same subject file, same size, but perhaps with a different codec or frame rate, etc. And if you now point to a different location - to what uTorrent thinks is a new file - uTorrent must do a re-check. If you want to move files - move them within uTorrent then you do not need to do a re-check.

Simply put, BitTorrent depends heavily on hashing as part of its verification mechanism. If you bypass hash checking when a file is moved, added, or deleted, you remove the reliability of the protocol.

[µTorrent 3.2 stable (27568)]

RC7,Win 8 RP 32bit.

Please keep in mind that uTorrent is currently not officially compatible (nor developed to be) with Windows 8, and likely will not be until Windows 8 is officially released. You may experience issues related to changes in the OS itself, rather than specifically uTorrent.

(I'm not saying that is the case here, but something you should be aware of.)

[µTorrent 3.2 stable (27568)]

Before we release this next RC, I want to point something out:

We currently have no mechanism to set information on a magnet link (e.g. the torrent name / file name), and have that apply later, when the magnet information comes in.

What that means for the Add Torrent dialog:

As some have pointed out, the "Name" field does not apply to the torrent properties when you click OK in the Add Torrent dialog. If we fix that, this problem will still occur for torrents whose metadata has not arrived before you click "OK". (They will use the original name)

Would it be feasible to simply have the Name field disabled from editing in this case, but still populated with the metadata if the user chooses to wait for it?

[µTorrent 3.2 stable (27568)]

I have to be perfectly honest, I absolutely hate the vertical-tree folder selection dialog. The conventional directory browsing dialog is much better.

[µTorrent 3.2 stable (27568)]

@AdamK: You're right. It does load the metadata on its own. It did, however, take three minutes to do so, which is likely why I jumped the gun and started going through the location dialogs. By the time I finished that, my prior tests had already downloaded it on their own. Correlation, not causation.

[µTorrent 3.2 stable (27568)]

There's no reason to assume that old, unsupported operating systems will continue to be supported by third-party software developers.

@rafi: http://user.utorrent.com/help/faq First entry.

[µTorrent 3.2 stable (27568)]

Also, when I add a torrent, WHY does it keep prompting me to add an RSS feed? I don't want RSS at *all* - even in the left-side list, but I cannot find a way to remove it or the prompts.

Where are you seeing this? I don't recall uTorrent ever asking me to add an RSS feed; all of mine were added manually.

Additionally, RC5 seems to have made me completely unconnectable, even when the port show open (and I have tried different ports - and yes, I sync'd them with the router)

Have you tested to see if your port is open outside of the uTorrent application?

[µTorrent 3.2 stable (27568)]

Based on my test, it appears to not load the data until the directory selection window is opened, and even then it attempts to name the file (from a single-file torrent magnet link) as the directory chosen for the download.

[µTorrent 3.2 stable (27568)]

It looks like the single-file torrents issue has been resolved -- at least at first glance.

Haven't had a chance to look at the other issue I reported yet, but I'll report back when I do.

[µTorrent 3.3 beta]

Why can not I see a stable version changelog? (Forum closed) Why the title of this topic is old?

3.1.3 is the "final" version of the 3.1 branch; development on that branch has stopped.

The current release candidate is 3.2, which will become the next stable version.

[µTorrent 3.2 stable (27568)]

Hah, good point.

Verdict: The bug still occurs.

It is possible to circumvent this behavior when adding the torrent by clearing the "Name" input box on the Add Torrent dialog -- and the torrent name still appears properly in the torrent list afterward -- so it looks like it's still creating a subdirectory with the torrent name.

When using Set Download Location from the torrent list or Relocate from the files tab, the bug I originally reported still occurs.

If this is intended behavior, the Add Torrent dialog should indicate that the "Name" will be used for a subdirectory of the path specified above it.

Additionally, the following issue occurs with single-file torrents:

(Directory contents and Windows username have been munged for privacy.)

As you can see on the image, instead of the actual filename, the dialog is trying to save the file as "Downloads.*", taken from the directory itself. I observed this behavior with default download directories turned on and turned off (though I am unsure if this affects the issue at all).

[µTorrent 3.2 stable (27568)]

-- 2012-06-18: Version 3.2 Release Candidate 4 (build 27434)

...

- Fix: "Add Torrent" dialog was wrongly adding a folder single-file-torrent download paths

when user changed file location via "save-as" dialog

Just wanted to clarify that the bug I reported also occurs in multiple-file torrents. My use case was that I wanted to point the torrent at a directory I had set up with a portion of the contained files already present, but uTorrent set the "Save As" location as a subdirectory of the path I specified, inside a folder with the same name as the torrent name. My intention was not to have such a subdirectory, but to have the files be checked in/downloaded to the directory I specified. The wording of the fix here is kind of confusing, so I'm not sure if that behavior is included.

[µTorrent 3.2 stable (27568)]

As of RC3, using Set Download Location or Relocate will still put the contents of the torrent in a folder with the torrent name, even if no such folder is desired. If this is not a bug, this behavior should be made apparent in the relevant dialogs.

[µTorrent 3.2 stable (27568)]

Do you guys do any testing? or do you rely on us to do it for you?

Of course they do testing. That's kind of an insulting question to ask. However, there's only so much that they can test in a development environment. The majority of the issues we are finding would only emerge during use in the "real world".

[µTorrent 3.1.3 stable (27327)]

Comments like those in the previous post are what make people paranoid and suspicious.

[µTorrent 3.2 stable (27568)]

Okay, this (probably) isn't my own stupidity this time:

When setting the download destination for torrents containing only a single file, the filename of the file is used as a directory name by default when choosing the target directory, resulting in "<path>/filename.ext/filename.ext"

This can be quite confusing if the user doesn't expect this behavior.