Richard Choi

@ rafi: no, it will store .dat files in the user's APPDATA directory by default, but if the .dat files are found in the same directory as the executable, it will use those, so uTorrent can be used without any sort of installation on the machine.

@rafi : IIRC the install location has been selectable since 1.8. It will default to the current install location (if one exists)

Regarding the language selector, it will only appear before the installer (if it needs to appear), and if both a uTorrent language is not set, and the Windows system language is not English. Any feedback is appreciated.

The delay with the deleting a .torrent/data is a result of delays in properly closing existing connections... this behavior has not changed for a while now, and you are most likely seeing a particular case where the connections are being closed slowly. If deletes are in the queue, the client process will wait to close until the deletes are completed.

We have posted a new build that fixes the Vista/Windows 7 crash with the bundle. This build is only available via bundling for now. Here is a quick rundown on bundling: You can bundle either a .torrent, a .btsearch, or a RSS feed using a special bundler on utorrent.com. Upon execution, the bundled executable will install itself if necessary and desired, and then do the appropriate action for the bundled content. It will download a torrent, add the search engine to the client search list, or bring up the RSS feed dialog. This is done by downloading a URL of the form http://utorrent.com/bundle.php?u={URL of .torrent/.btsearch/feed} Unfortunately, the action to do with the bundle is determined by the URL that is attached. URLs ending with *.torrent will be treated as a torrent, those ending with *.btsearch will be treated as a search definition, and all others will be treated as feeds. We are planning on determining type more intelligently in the future. If the bundled .exe is run while uTorrent is already running, the bundled .exe will send a message with the bundled information to the running client, and then terminate itself. If the bundled .exe is installed, the bundle will be used on first run, but should not be used in future instances of the installed client. However, if the bundled client is run in place and not installed, the bundle will be run on each client start. Please feel free to add any bugs/feedback/suggestions about this feature and build

@gianipower: The correct build is now posted on the download page. A reinstall should do the trick. You do not need to clear your settings. Please post if that does not work.

@thai it means the .btsearch file, which you can load by double clicking in explorer after it is associated.

.btsearch is a specification file to add torrent search engines to the box within the client. http://bittorrent.org/beps/bep_0018.html @emc : the bundling system is actually to allow people (most likely torrent search engine operators) to link to copies of uTorrent with their search engine preloaded in the search box. This will be done via a web side script at utorrent.com, but is not publicly available yet. If you already have a .btsearch file for a search engine you'd like to add with an existing utorrent.exe, you should be able to load it by simply associating utorrent with .btsearch and loading it in Windows.

We think we've found the bug, and are testing a fix. Sorry for the hassle and thanks for your patience. Edit: The bug in reference is the download reporting for the tracker.

Do you remember the first build in which you encountered this issue?

@ Lucifer: we'd still like to track down this problem, as the forum user base is just a small subset of the overall user base, and this problem could easily be occurring for many others out there. If you could give us the latest build that works properly with that .torrent for you, as well as the oldest build that fails, we can look at changes one-by-one to try and find possible culprits.

@ Lucifer: I don't think that tracker is blocking 1.7, since I have been able to successfully announce with the provided torrent. It seems like there could be general problems with HTTP requests that occur in certain states with your configuration (that I haven't been able to reproduce).

@ Lucifer - So for the tracker issue, does that always occur with that file, or only sometimes? Do you have automatic upload rate limiting on? Do any of the issues mentioned coincide with getting a new dynamic IP? Sorry, for the interrogation... just trying hard to track down the issues for you.

@ Lucifer - I am using your .dat files, and haven't encountered the RSS update problem or tracker problem. Do you by chance remember the last build of version that worked for you?

@ Lucifer - I'm assuming you're still having problems with your feed updating... I have not been able to reproduce it. Could you send me (rchoi @t bittorrent dot com) your rss.dat and settings.dat file along with any applicable information about your connection, network setup, etc. Thanks!

@ Lucifer: when it fails to download the feed, are you getting any messages in your log?

@ Lucifer - if a feed fails to download, uT should still try to download it again after the next RSS update interval (which is a user setting). You can also force a manual RSS feed update from the Releases tab.

The completed on time issue is already fixed for the next build.

@ Lucifer: thanks for the file. Did the problem occur all the time with all matches? I got a couple filter matches, and I didn't reproduce the bug after (torrents did not download again). I made a couple changes to the system since 2151, so hopefully it's fixed. edit: I ran 2151 with your rss.dat, and did not get the issue either... so either this only occurs on certain matches, or something in your settings.dat could be a factor.

I haven't been able to duplicate the issue with repeated RSS downloads, even with the provided feed. If anyone still has the issue, and is willing to send me their rss.dat file for testing, please send me a message... thanks!

@ lucifer: I haven't been able to duplicate your RSS issue with downloading every update. After you download the torrents in one update, if you go to the filter and press "?", do the same torrents show up as matches? If you enable the feed column in the RSS history, are all the downloads coming from the same feed(s)? Although not a recent change, the RSS history was changed a few builds ago to check the URL to the .torrent file. If the URL to the .torrent file changes periodically, this could break the filter.

@ rafi - I could not duplicate... are you sure the episode in question was not already in your history? It will not attempt to re-download entries already present in the RSS history (or if the smart ep filter has already matched that episode)

@ wyrmchild: regarding the crash on HTTP 302 response, we have identified and fixed a problem in the HTTP code that caused a crash. It will be in the next release.

@ Lucifer - thanks for the feed... we discovered a couple cases we did not handle properly, and updated the code accordingly. @ rafi - I think auto-adding trackers may be undesirable for some, as I have heard there are quirks when doing that with private ratio sites. If anything, it should be an option.

@ rafi - the "identical" ones in these cases would not have different trackers, as they would be pointing to the exact same .torrent file (not just a matching infohash, but the exact same file). Identical entries should not get checked unless they have both the same name and .torrent. If this is not what you're seeing in the latest build, please let us know.