AdamK

Thank you! We'll have that one fixed soon.

The devpair.dat files are support for a super-secret new feature that we are adding to utorrent soon.

This is great. Now we're getting somewhere with this problem.

Hey Virtual_ManPL & Rafi, Virtual_ManPL, Your magnet link loaded for me after 1 minute, Rafi, yours after 2 minutes. I agree that it's taking longer than it should, though. For Rafi's magnet link, I was connected to about 20 peers for most of the time that I was waiting for the metadata. A coworker pointed out that all the peers I was connected to had 0% of the torrent - presumably other people waiting to get the metadata, too. Perhaps what we should do is churn our peer list until we get the metadata.

Have you tried un-checking this box? Magnet links depend on you connecting to someone who has the torrent file, and maintaining that connection until you have downloaded all the metadata from them. It is one of the most finicky parts of the torrenting infrastructure. So, when you are testing this feature, make sure you are are in a swarm that is large enough to get you the metadata in a reasonable amount of time; check the peers tab for that torrent.

Is this when you load a magent link through the "Add Torrent" dialog? After magnets became suddenly more popular, we wanted to implement the feature of loading torrent meta-information during the Add Torrent dialog, so the user could have a similar experience as when they load a regular torrent file. The way we do this at the moment is to start the torrent until we get the metadata, then stop it. Unfortunately, in the utorrent codebase, this may cause some side-effects. I believe some other posters mentioned files appearing in the wrong place. So that needs to be fixed. Do you actually see data packets being exchanged, or just the files created on disk?

Good ideas. Any way you slice it, there are going to be at least four cases. And unfortunately, the Add Torrent dialog throws in way more than just those options, as well. Note that RC5 already implements your suggestion of always using the directory selector, never the file selector.

Okay - I finally got the problem where ut would try to use the directory name as the file name. Here were the conditions: - Single file torrent - Not a magnet link - Choose a directory that does not yet exist. Then, utorrent would attempt to use the directory you chose as the filename. Cause: The old code had special cases that treated the path differently based on a number of factors. We are moving toward treaing the directory and filenames separately, but as you know there are, sadly a lot of cases (single file, multifile, "multifile" with one file, etc)

Yeah, testing that type of problem is tricky.

Yeah' date=' 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.[/quote'] Thank you for the very descriptive problem report. You can be sure to see some of these improvements in 3.2.1

Zarggg, Rafi are you sure? Using the directory as the filename is definitely a bug, but I think that loading metadata in the Add Torrent dialog works just as it did before. Try with a bigger swarm. Do you have the DHT enabled? Do you have any peers on the torrent while it is being added? (Check the "hidden" label on the left-hand side).

As far as I know XP is also not supported. I wonder: were is this list of supported OSes ?... Is Win8 there ? Here is the list of supported OSes for current utorrent versions: - Win98: Not supported - WinME: NOT supported - Win2k: not supported - WinXP: Supported. If you find an issue here, we'll fix it - Vista, 7: Supported - Win 8: Not supported yet. We plan to support this soon.

RC5 is up.

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

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.

You are welcome to not run our alphas & betas.

Nope, that's us. Thank you for the report!

Thanks - could you post or email us a dump?

Did you intentionally disabled the Windows cache controls? Disk stats graph shows - cache-writes==disk-writes. Is that as designed/intended? http://thumbnails38.imagebam.com/19417/9edf15194165963.jpg Hi - The windows cache controls are turned off in this version because all writes are buffered in this version. Please see this article: http://support.microsoft.com/kb/2549369 Also - utorrent.exe hangs (again) in memory after exit (while downloading ). I guess you still didn't copy the fix from 3.2 ... I assure you - this is a different hang on exit than the one that was in 3.2 - we'll make sure to remove this one, too Not if the counter is just broken and those 300 nodes are being duplicated inside ... That's a nice one

Hi Everyone, We would like to begin the stabilization / Release candidate process for 3.2 soon. We believe that at this point, 3.2 has many advantages over 3.1.3, and is becoming quite stable. I'm currently aware of a few more issues we have to fix before releasing a 3.2 - Rafi and Firon are keeping an eye out for issues. Please let us know if you have a good reproduction for an issue that has not already been addressed. Thanks for using 3.2

This is very likely because the 3.3 versions and the 27297 build have very different disk i/o code than other utorrent versions. The older disk i/o code is very complex, and it interacts with the utorrent cache, which is also very complex, so it is possible that code had some, shall we say undesirable effects. Aside from that, the windows disk subsystem has a feature, FILE_FLAG_RANDOM_ACCESS that interacts badly with opening files in unbuffered mode. Hilariously, we started opening files in unbuffered mode, way back in 1.8, to work around reports of sluggish systems. In the future, we will probably stop using this flag entirely. From MSDN, via Arvid, via one of our users: "The FILE_FLAG_RANDOM_ACCESS flag is a hint to the Cache Manager that the file will be opened for random I/O. Random I/O means there is no predictable pattern to the I/O that will take place. This flag disables intelligent read-aheads and prevents automatic unmapping of views after pages are read to minimize mapping/unmapping when the process revisits that part of the file. This keeps previously read views in the Cache Manager working set. However, if the cumulative size of the accessed files exceeds physical memory, keeping so many views in the Cache Manager working set may be detrimental to overall operating system performance because it can consume a large amount of physical RAM."

Thanks - that looks similar to another bug we are investigating. I'll add your report to that bug.

Do you mean 27297?

Squaresoft, make sure that utorrent is fully shut down before deleting your settings.

Hello All, Regarding Bunndle: This is a new offer platform that we are testing out offering in the utorrent installer. The reasons we are trying out this platform are twofold: 1) It's an important source of revenue, that pays the workers that bring you utorrent 2) Our business team is constantly trying to find offers and products that are more relevant and useful to our users Now, if none of the offers appeal, of course you should uncheck the box. However, I want to explain a bit more about elgee's comments Re: Kaspersky & certificates, for our more technical users. In this case, to show the Bunndle offers we had to change a small amount of code at the beginning of utorrent to load an initialize the Bunndle dlls, whether we were going to show a Bunndle offer, or not. When their dlls start, they set themselves up so they can communicate securely with their offer servers. Part of doing that is adding a certificate, so they can know that the server they are talking to is theirs. You can read more about certificates and SSL connections on windows here at MSDN: http://msdn.microsoft.com/en-us/library/windows/desktop/aa376009(v=vs.85).aspx Thats for the report! If you do see anything weird, please include the affected registry keys, and we'll look into it right away.