Lord Alderaan

Well the warning is nice. Otherwise people are gonna wonder where the torrent went and might even think it wasn't loaded. And I guess a check if there are actually new trackers isn't made before displaying the notice. Another frivolity

Oh I think they comprehend just fine they probably cba to change such a minor frivolity It wouldn't matter which of the two was actually loaded right?

@rafi: Ah yes smart filter. Well I guess they check all feeds with the same link and name (without adding the torrent again) as a default behavior and didn't disable this when the smart filter is used. @bonesaw: haven't used it myself but heard ktorrent isn't a bad linux client.

Are you using a User-agent changer Addon?

@rafi: The torrent was downloaded directly from that link. So it wasn't downloaded 'off a feed'. There were two feeds that had the same link. That link was downloaded thus both feeds are marked. To me it makes much more sense then only marking one feed. Only thing I can think off is that you want to know which torrent name matched your filter but as rafi said it only checks them both if both the name and the link is the same. Another way to see it: µtorrent adds the same torrent twice and marks both feeds. Upon adding µtorrent notices the second torrent is identical to an already loaded torrent (the first) and tries to add the trackers but since there are no new trackers de facto nothing happens when the second one is added. Because this is known up front µtorrent marks both feeds but downloads the torrent only once. @kokobaroko: Have you tried deleting the settings.dat file yet (to reset all your settings)? Might be something is broken in there. All my µtorrent copies remember their port no-problem. And Firon meant that maybe the problem is that something is blocking/claiming the port you have set in µtorrent and it therefore tries a different port. Although it shouldn't chose a random port but give a Red Warning sign in the port status area of the status bar (bottom bar of µtorrent right of DHT status).

The cases in which you can actually preview a file (sequential media files such as mp3,divx and xvid that aren't packed) is fairly limited, the number of people who are interested in it are fairly limited, the number of people who will know and find this option is fairly limited and the number of people who will actually go to the trouble of using this function regularly are virtually nil I suspect. If piece priority is used as you describe it the consequences might (I didn't think your whole concept through) be small and you might benefit from it but any other scenario someone messes with the piece priority it won't benefit the user and it might damage the health of the torrent. At least thats how I see it. Maybe a specific preview function instead of a general piece priority function might provide a solution to that but still it means coding, testing and I-dunno-what-else a function that will hardly be used. With a couple more pressing matters on the todo list I don't think this function is gonna be implemented soon if at all. But I guess its up to the defs. PS if you seriously want it considered you should post in the Feature Request topic and not here.

BitComet isn't exactly the saint amongst BitTorrent Clients and claiming a function can't be all bad because BitComet has it won't work because they had and have various functions which are bad for the health of torrents. IMHO the rarity of the usefulness of this function can't weight up against the negative impact if mis- and/or abused. Why implement a function that isn't going to be used by 99,9% of the users and could be mis- and/or abused by them all?

I'm not too knowledge about the protocol but as far as I understand it BitTorrent doesn't want the user to have complete control. Prioritizing files is a lot more useful for the average user then prioritizing pieces. An average user shouldn't even care and know about pieces so why would we allow them to prioritize them. The non-average user who does know about pieces knows its best for everyone to let the protocol do its thing. How could pieces priority allow users to get what they want? A piece is a building block of the download chosen by the torrent maker program which has the sole purpose of making certain functionalities in distribution posible and efficient. It is not related to the end product (files) whatsoever. The only reason to influence piece priority is to try and adjust distribution efficiency which should just be left to the protocol. So this 'feature' will have a negative impact, just like file priority. But unlike file priority the user doesn't get anything in return. Or did I miss some advantage in allowing piece priority?

Netlimiter is yet another application between your software and the internet. It uses system wide hooks which could cause problems. A properly setup µtorrent doesn't need netlimiter to keep ur internet browsing smooth so unless you use netlimiter for other reasons (where netlimiter might actually be a recommended solution) netlimiter is not advised. Just run the Speed Guide. It is simple and configures µtorrent for you with settings that are optimal in 99% of the cases.

I don't want to be able to access (being able to make a torrent and upload it would allow download of any file on the PC) the files on my computer through a simple web interface no matter how secure they think they can make it. Besides I fine with a less secure (http-auth is unencrypted after all) webpage that can just add torrents and inspect their status. Afaik developement has been still for a while. Future functions have not been announced.

Ok I presume your router supports UPnP then (I don't think there are any routers that support both) so you can disable the NAT-PMP in the options if you want. The 1.7 Beta has a number of UPnP fixes in all of its builds make sure you are running the latest build (1355 right now).

@trigger: Does your router even support upnp or nat-pmp?

@ICleolion: Because I use a default download directory and no popups. Often I throw in about 20 torrents at once every few days and I don't like to be interrupted when browsing for torrents. Besides if I directly download to where I want the files and I visit that (for example my anime) folder I wouldn't be able to see what is downloading (yeah well maybe from the .ut extension if I go inside the torrents subfolder), what is still seeding and what has been finished and what isn't even listed in µtorrent anymore. I like my current g:\torreting (=downloadeding), g:\torrented (=completed), g:\done (=Finnished but unprocessed/unsorted; I move finished downloads here manually when I remove the corresponding torrent from µtorrent) setup. Its nice and tidy. From the g:\done folder I delete/rename/extract/move files to their final destinations every once in a while.

Try the no-ip.org and public IP address on another computer on the internet not on on the PC running µtorrent or anyone in your network. Most routers can't handle looping-back on their public IP.

Yeah or just a 'Move Finished Torrents to:' option similar to the 'move completed' option would be nice But it has already been requested over and over again without much success With Finnished I mean done seeding

Lol I see that Dark Shikari nick and thought... I know that guy hmm... but he only regged yesterday... Google -=> First Result -=> "I'm Dark Shikari. You may know me from the EVE Online forums where I have over 21,000 posts (!)" Ah yes... him

WebUI hardly uses upload and if you have µtorrent properly configured it reserves enough speed for browsing and the webui so it shouldn't cause any troubles. Scrolling sometimes needs bit of loading time but not more then a few seconds.

When it is done I guess

Yeh pretty much. Its more a not-yet-decently-implemented-function I think it boils down to the same thing. It needs fixing.

Tbh it happened to me too. I pressed Yes. And it moved to program files whilst I didn't really want it to. But it took less effort to fix it then it would have taken to complain about it here Besides. I'm a pro (at least I have the arrogance to think that) and instantly knew what had happened and how to fix it. For a new user this is actually a nice feature, we've had numerous post about what to do with the utorrent.exe after you download it.

Just tried it and the normal way doesn't seem to work. afaik there is no other way then through a torrents properties.

Trying to confuse the new users? If they see a % in a question they'll probably panic (j/k)

Actually. 768 kbps = 92 kb/s 96 kb/s [edit]But indeed the upload limit µtorrent chooses if you set a xx/768 connection is 72kb/s. In this case it leaves 24bk/s room (for browsing and upload required for fast downloading).[/edit] I dunno how exactly it is calculated but if your internet upload is used by other things (computers in your lan / applications on your computer) its posible it will be set to a 'mere' 14,5 kb/s.

This is a build-in anti-leech feature of µtorrent. I assume the download speed is restored as soon as your upload is autoset above 6kb/s again?

jzu. The exe moves itself to %PROGRAMFILES%\utorrent if you chose Yes when it asks to install. Are you 100% sure you didn't get such a question?