µTorrent 3.2 stable (27568)

"- Fix: Fix uTP delay graph"

Still don't see some peer's delay graph (graph shows 0 ms). Usually I upload to them at speeds <1kB/s.

"- Fix: Fix uTP delay graph"

Still don't see some peer's delay graph (graph shows 0 ms). Usually I upload to them at speeds <1kB/s.

Probably because it is not yet fixed properly ...

http://forum.utorrent.com/viewtopic.php?pid=667080#p667080

Any screenshot of your whole graph?

Delay is a straight line at 0 ms even though I'm uploading (very slow). Not in the negative territory like your post and never saw something like this.

Any screenshot of your whole graph?

^ I like to see things.. Is it that hard for you ?

Don't see any reason to post an obvious image. Stop all your torrents, view the uTP graph. This is what I see when uploading very slowly to some peers.

Don't see any reason

I do...

what it the # at the top of your delay (Y) axis ?

98. Believe me that I check max Y values. Good question!!!

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.

Not sure if this problem has been raised, but I've been having issues on the latest builds with the Force Re-check function not working on Torrent files I have created.

For example, If I download a File and then create a Torrent from it and upload it to a private tracker torrent site, when they give me the download link for the uploaded torrent and I try to re-check it against my original file, the re-check fails and shows that none of the file has been downloaded.

I'm not sure exactly in what build this problem started, but I wasn't having it a couple of weeks ago. I'm currently running 3.2 Build 27430 (latest). I've been using Vuze to get around the issue in the mean time.

There definitely appears to be a problem though!

the re-check fails

I rechecked right after creating a torrent against the original files, and it passes fine. Is it a special-large file(s)? I suggest you do the same. Plus make sure the torrent you got from them is the exact same as you created.

the re-check fails

I rechecked right after creating a torrent against the original files' date=' and it passes fine. Is it a special-large file(s)? I suggest you do the same. Plus make sure the torrent you got from them is the exact same as you created.[/quote']

It's not especially large ~800MB file. The torrent file I get from the tracker site is identical. All it does is create its own unique tracker list and identifiers (as private tracker sites usually do). This has occurred on two occasions now and I've been able to resolve it in both cases by opening the torrent file with Vuze instead (so the torrent file definitely DOES match the original).

I should reiterate that this always worked fine on previous builds, so it is definitely a relatively new issue! I may end up rolling back to 3.1 if this issue keeps up, as I remember it working fine with those builds.

the re-check fails

I rechecked right after creating a torrent against the original files' date=' and it passes fine. Is it a special-large file(s)? I suggest you do the same. Plus make sure the torrent you got from them is the exact same as you created.[/quote']

It's not especially large ~800MB file. The torrent file I get from the tracker site is identical. All it does is create its own unique tracker list and identifiers (as private tracker sites usually do). This has occurred on two occasions now and I've been able to resolve it in both cases by opening the torrent file with Vuze instead (so the torrent file definitely DOES match the original).

I should reiterate that this always worked fine on previous builds, so it is definitely a relatively new issue! I may end up rolling back to 3.1 if this issue keeps up, as I remember it working fine with those builds.

Interesting. Does this happen only with single file torrents? Right click the torrent, and choose "Open containing folder". Let us know if it matches the folder your file is stored in.

I rechecked right after creating a torrent against the original files' date=' and it passes fine. Is it a special-large file(s)? I suggest you do the same. Plus make sure the torrent you got from them is the exact same as you created.[/quote']

It's not especially large ~800MB file. The torrent file I get from the tracker site is identical. All it does is create its own unique tracker list and identifiers (as private tracker sites usually do). This has occurred on two occasions now and I've been able to resolve it in both cases by opening the torrent file with Vuze instead (so the torrent file definitely DOES match the original).

I should reiterate that this always worked fine on previous builds, so it is definitely a relatively new issue! I may end up rolling back to 3.1 if this issue keeps up, as I remember it working fine with those builds.

Interesting. Does this happen only with single file torrents? Right click the torrent, and choose "Open containing folder". Let us know if it matches the folder your file is stored in.

I'm not quite sure what you're asking me to do? I don't create a lot of Torrent files, but I have only ever done single torrent ones. If I open the torrent file with uTorrent after I've created it and perform a re-check, it seems to pass. The issue I face is that I have to upload the torrent file to the private site (TVTorrents) and then download it again with their tracker information embedded into it. Performing a re-check indicates that the file does not yet exist (despite me telling it to save in the same folder). One would think that the torrent file and my file don't match based on this, however it works perfectly in Vuze and has worked fine in earlier releases of uTorrent. I just performed another test and tried to download the torrent (with uTorrent) after successfully seeding it to completion on the site (with Vuze). This time round the re-check passed. That just has me totally confused! Seems to only fail when there are no other connectable seeders or leachers? I don't know enough about torrent files and tracker sites to speculate on what could cause this, but hopefully one of the devs can figure this out based on the behaviors I have described?

Unfortunately the show I've been creating torrents for just aired its final episode for the season, so I won't be testing it again any time soon. Hopefully there will be others that experience similiar problems and can provide more feedback, which will help you get to the bottom of the issue.

Performing a re-check indicates that the file does not yet exist

Look at the info tab, and make sure the path is the correct. You might be pointing it to the wrong location (or utorrent is mistaken in pointing to it... there was issues with location of single files torrents)

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.

This one will be fixed in the next Rc. Thanks for reporting it.

RC4 is up.

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

so I'm not sure if that behavior is included

So, why not just backup your settings files, and check it up ? My bet is that what's not in the changelog is not in the code...

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

Previous RC1 issues : http://forum.utorrent.com/viewtopic.php?pid=665456#p665456

RC4 issues:

Fixed:

-2 Fixed: crash when using Authenticated Sock4 proxy [119]

-3 Fixed: crash when click-download a magnet from the RSS list-view (for example - The Pirate Bay's...) [111]

-5 Fixed: "Add Torrent" dialog is wrongly assigning the torrent name as part of the "Save-as" folder name field in case of a single-file-torrent ( this is only when you select-change to a different folder, cause using the 'save-as' sub-dialog instead of 'select folder' one ) [125]

(-7 To Be Fixed Later: The Upload limiter breaks down when set to *include* overhead, and the download-induced-overhead exceeds the set limit [116, will be fixed in the next stable release] )

--8a Partly Fixed: Swapping torrent name with file name for a single file torrent http://forum.utorrent.com/viewtopic.php?pid=666154#p666154 [132] (see # 12 below)

Not fixed:

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

-1 Not Fixed: crash when running twice "setup-guide"->speed-test [96]

-4 Not Fixed: auto-downloading tracker-less magnets from RSS will not auto-enable DHT, and will never download [114]

-8 Not Fixed: Issues with "Add magnet" dialog:

--b"Add to top of queue" checkbox - not working [131/133]

--c "Run program" when download complete - is wrongly being executed after meta-data is loaded [129]

-9 Not Fixed: A status of a seeding torrent - is not being updated when "Initial seeding" is being checked/unchecked during seeding time[124]

-10 Not Fixed: Magnets downloaded from RSS feeds are w/o auto-enabled DHT, and may never download the meta-data [114]

-11 Not Fixed: When using magnets with multiple files, and changing the destination folder *after* meta-data is loaded, a partfile is being created and left over with the original folder [106]

-12 Not Fixed: The RC4 modified "Add torrent" in dialog is using illegal path name for a single file torrents as default "x:/.../dir.*". It also does not open the "save as" in the default download path location

-13(ref 8b) Not Fixed: "Add magnet" Sometimes a queue # is not being assigned to a new download

-14 Not Fixed: In "Add magnet" when setting a new folder for multi-files - torrent, it does not use the listed "name" (sub-folder) under it

Edit:

-6 Not Fixed: uTP delay graph is broken (in the negative territory... ) [92]

-15 Not Fixed: Labels entered via the RSS downloader dialog - are being lost in the system and are not visible in the main view->labels column

Edit2:

-16 Poor PartFile processing causes performance issues (Disk IO, Speed) at high speeds. [xxx]

Lets (still...) hope that most of those will be resolved in the next RC ...

Feel free to confirm/reject any of the above points

I fail to understand why it is so difficult for the developers to solve the Add Torrent dialog box issue.

It seems now (in RC4) the name field is ignored on a single file torrent. It seems to be back to the old way You need to use the "Save In" (I have yet to add a second torrent to be sure).

It would seem to me the easiest and simplest method would be the "Save In" to be a folder selection - and thats it.

In Single file torrents - the "Name" field is the name of the (to be) stored file and the "Name" displayed in utorrent.

In Multi-file torrents - the "Name" field is the name of the Sub-Directory/Folder where the files in the torrent are stored and ALSO the "Name" displayed in utorrent. (The user would select the parent directory in the "Save In" field.)

If you are going to ignore the "Name" field on single file torrents - at least hide the field.

Well - single file torrents via the "Save In" is still messed up. When you open the "Save As" dialog box. the path located in the Save In box is moved to the Filename box. For example "TorrentsDownloaded.*" It completely ignores the name field or the file name specified in the Torrent Contents. The file type is *.* rather than the filetype in the Name field. So you are forced to modify the filename in the Save As dialogbox. (I would anyway since I do not like the format, but now I need to replace the entire name rather than editing it to conform to my standard.)

Don't you guys have peer review?

Don't you guys have peer review?

You're looking at it.

Add dialog box eradicate the torrent name, when choosing another path, replacing filename with "Download.*" ; very frustrating RC4...

It would seem to me the easiest and simplest method would be the "Save In" to be a folder selection - and thats it.

In Single file torrents - the "Name" field is the name of the (to be) stored file and the "Name" displayed in utorrent.

In Multi-file torrents - the "Name" field is the name of the Sub-Directory/Folder where the files in the torrent are stored and ALSO the "Name" displayed in utorrent. (The user would select the parent directory in the "Save In" field.)

Yeah, the current Add Torrent dialog is very confusing and inconvenient (meant to report long ago..)

I loved it most when there was just a single input field for "location".

- It was simple and straightforward

With the new dialog one has to check the contents of the torrent first to decide where the final folder name goes (either to "Save In" for single-file torrents or to "Name" for multi-file torrents). And it gets utterly confusing when a torrent contains a folder with a single file inside.

And with, say, TV shows releases it's either just an .mp4 file or a bunch of other crap I usually deselect ("downloaded from..", etc.) - so one has to be always careful to get location right.

- There was convenient history to choose from

Say I download a TV show once a week. With a single input field it was easy to just pick the output path from history and you are done. But with the new "Name" field history does not work anymore.

So please re-consider bringing these two back together again.

I've also got a complaint regarding magnet links support.

Whenever the "Torrent Contents" is resolved in Add Torrent dialog I've got the corresponding files created in my Downloads folder. I don't know if that is intended that way. But it is very inconvenient to clean all the "leftovers" in Downloads after uTorrent.

Here are some more details.

I have never touched "Directories" in Preferences (thus all the fields are empty).

The default location (the one that appears in "Save In") is like D:\Video\...

But whenever I click a magnet link (say, this one for Ubuntu - magnet:?xt=urn:btih:8ac3731ad4b039c05393b5404afa6e7397810b41) and wait for the "Torrent Contents" to be resolved the files (ubuntu-11.10-desktop-i386.iso) are created in C:\Users\...\Downloads

Could you please fix uTorrent to omit creating those files? Or if they are needed somehow for fetching the list of files uTorrent could at least delete them automatically after the torrent is added with a _different_ download location.