Aranjedeath

I think you can if it is not tracker-less... And it will not enable DHT if there is a tracker defined. I bet this is what's happening, if true.

Does 3.2.1 just set DHT up long enough to grab the .torrent and then turns it back off again? edit: Assuming (because it is, in my case) that dht is globally turned off.

How will you "pursue making offers that are targeted and interesting to our users"? Behavior based advertising? Because that sounds all sorts of not-good.

So can one of the mods/admins explain the changes to dht regarding magnet links? It seems like now (vs 3.1.3) uTorrent will force dht on (and on for new torrents) if you add a magnet-linked torrent. Am I understanding that correctly? That's a global settings change, correct? I ask because I've used magnet links sometimes, but having dht turned on destroys my router (It's one from the ISP, does router/modem and sucks pretty hard. Supports ipv6 though. Go figure.)

Is there then a setting we can change so that deleted torrents are not sent to the recycle bin but are actually deleted by utorrent? Or is that also an unworkable solution?

The reason it takes forever is because utorrent sends the delete command for every single individual file inside a torrent. I experienced this when I tried to delete a torrent with >40k files, it took almost an hour to actually get it all into the recycle bin. It's something that utorrent developers should consider seeing if it's viable to fix. I'd think you could just delete an entire file tree, but I've never tried directory handling in C, so I have no idea if it's easy or possible. [edit] : edited for concision and clarity

I wonder why it is that it takes several orders of magnitude more cpu to deal with public tracker torrents (many trackers, dht, pex, local peer discovery) vs private tracker(single tracker, no dht) torrents. I had a large number of torrents seeding (not actively, only <5 at a time active) and I removed a majority of the public tracker based torrent files (Which again, weren't even active), and the cpu usage went from ~30% down to ~5%. This is a difference of ~60 torrents out of 1.5k total. Would it be possible for there to be optimization done in this area? I feel like a majority of utorrent's userbase probably uses public tracker torrents and would benefit from optimization in this area.

I'll do some testing and see how low it needs to be to not wipe out network connectivity. I'm not really concerned about shutdown speed as long as it does it correctly.

I've been having issues with utorrent wiping out my networking capability on exit. It's not specific to any version, and I assume it's because I've got >1k torrents loaded and seeding at any one time. I assume it is just messing things up trying to announce to 1k trackers at the same time. Is there any tuning I can do to help this? Anything you can do for utorrent so it handles edge cases like mine more gracefully?

Nope' date=' 2.2.1 isn't allowed on any of the sites I'm on due to being beta.[/quote'] It /seems/ to work on my laptop, but that's not the computer it's crashing on. I'll report the bugs if they're still present when 2.2.1 comes out.

Nope, 2.2.1 isn't allowed on any of the sites I'm on due to being beta.

Hey Firon, what can I do to help you figure why and then fix an issue I've been having? Basically whenever I do anything related to apps (excluding uninstalling them, hilariously enough) utorrent crashes. If I `add` a torrent inside one, if I add an app to utorrent, etc. build: 2.2 - 24683 OS: win7x64 ...Actually I just found all the crash dumps. This most recent crash doesn't seem to have produced a dump though. These are all from previous crashes when I was attempting to get utorrent to add the sick of sarah app and then download the promo torrent. So: What to do? Want them all?

This. None of the private trackers I'm on white list by build number. It's all `Yes, 2.2 is cool but not 2.2.1` etc. I would petition your site admins to be a little more flexible and fix their shit.

You might also consider recognizing that bittorrent inc is trying to make a living, and that people who use private bittorrent trackers are a slim minority of those who use microtorrent. You should also note that the version number hasn't changed for the 2.2 branch, only the build number.

So I've had utorrent crash maybe 4 or 5 times now, it happens every time I click a download button inside an `App`. Sucessful in reproducing it in several pages within the Ted app and the new Sick of Sarah app as well. I hit upload on all of the crash notification boxes. Useful details: 2.2 Build 23703 OS: win7 64bit ultimate

@alus Tehehe, I just checked windows update, and they had a new Microsoft signed driver for my NIC. That might be why...

Hmm, I have a hunch a bluescreen I just got may be linked to Utorrent. It was a "IRQL_NOT_LESS_THAN_OR_EQUAL" bluescreen, but the driver causing it was tcpip6.sys, and utorrent is currently the only thing I know of(unless Microsofts IPV6 driver just sucks and crashed on its own) that is even ipv6 capable on my computer. Tell me if there is anything I can get you, I'm not sure how to proceed.

@Firon Qos is disabled on my computer(In windows network dialog) and on my router. There is none on my network.

@alus It's DSL.

@Firon Again, 1 minute startup time, no caps, nobody home other than me to generate traffic on the network. ping google.com -n 15 I'll stick the logs in a textfile to mediafire http://www.mediafire.com/?sharekey=f5c39b45f46327e9d2db6fb9a8902bda It's the text file.

Sure, re test with 1 minute startup time, I'll time it this time. Also, all caps have been removed(IE Unlimited). (I am, other than my Mother, the only one on the network, and she only browses internet/email, doesn't download) Without utorrent 32ms Reply from 209.85.171.100: bytes=32 time=33ms TTL=242 Reply from 209.85.171.100: bytes=32 time=32ms TTL=242 Reply from 209.85.171.100: bytes=32 time=32ms TTL=242 Reply from 209.85.171.100: bytes=32 time=33ms TTL=242 With utorrent uTP only 81ms Reply from 209.85.171.100: bytes=32 time=134ms TTL=242 Reply from 209.85.171.100: bytes=32 time=33ms TTL=242 Reply from 209.85.171.100: bytes=32 time=76ms TTL=242 Reply from 209.85.171.100: bytes=32 time=84ms TTL=242 With TCP only 133ms Reply from 209.85.171.100: bytes=32 time=33ms TTL=242 Reply from 209.85.171.100: bytes=32 time=34ms TTL=242 Reply from 209.85.171.100: bytes=32 time=291ms TTL=242 Reply from 209.85.171.100: bytes=32 time=177ms TTL=242 With BOTH 69ms Reply from 209.85.171.100: bytes=32 time=95ms TTL=242 Reply from 209.85.171.100: bytes=32 time=109ms TTL=242 Reply from 209.85.171.100: bytes=32 time=36ms TTL=242 Reply from 209.85.171.100: bytes=32 time=39ms TTL=242 Note: the first time I tried to do it on both, it crashed(for this run.) EDIT: the Crash was not a full crash, it froze up and thus left no dump or logs :/

What kind of internet connection do you have? What is the ping time to google.com when uTorrent is not running? What about when it is running with uTP+TCP, and also when it is running with TCP only? 1.25mbits/s down, 312kbits/s up, 32ms without utorrent Reply from 209.85.171.100: bytes=32 time=33ms TTL=242 Reply from 209.85.171.100: bytes=32 time=32ms TTL=242 Reply from 209.85.171.100: bytes=32 time=32ms TTL=242 Reply from 209.85.171.100: bytes=32 time=32ms TTL=242 52ms with uTP only Reply from 209.85.171.100: bytes=32 time=36ms TTL=242 Reply from 209.85.171.100: bytes=32 time=60ms TTL=242 Reply from 209.85.171.100: bytes=32 time=32ms TTL=242 Reply from 209.85.171.100: bytes=32 time=81ms TTL=242 134ms with BOTH Reply from 209.85.171.100: bytes=32 time=163ms TTL=242 Reply from 209.85.171.100: bytes=32 time=118ms TTL=242 Reply from 209.85.171.100: bytes=32 time=122ms TTL=242 Reply from 209.85.171.100: bytes=32 time=136ms TTL=242 52ms with TCP only Reply from 209.85.171.100: bytes=32 time=47ms TTL=242 Reply from 209.85.171.100: bytes=32 time=35ms TTL=242 Reply from 209.85.171.100: bytes=32 time=93ms TTL=242 Reply from 209.85.171.100: bytes=32 time=34ms TTL=242 These times taken(Where it applies) roughly 1 minute after the client had started, I have 4 torrents that are running.

I actually tried the non-logging one first(59) before I realised (60) was also available, I saw no significant difference between the two, cpu wise. I did notice the non-logging one sorta spiked the speeds when it first started up, then cut them back down to silly-slow speeds, that did not happen with the logging one. It just started up and was slow. Could be random network awesomeness, or something else, I'm not sure.

Ok, same logs with the 13560 build, instead of the previously posted 135(50?) build. Speed issues persist. http://www.mediafire.com/?sharekey=f5c39b45f46327e9d2db6fb9a8902bda (Same link, file name of uploaded file reflects build)

You wanted my Logs, here they are. Also reporting mundanely slow download speeds, upload speeds unaffected. Posted on Mediafire http://www.mediafire.com/?sharekey=f5c39b45f46327e9d2db6fb9a8902bda