µTorrent 1.8.4 released

mossmanfly, we *REALLY NEED* more info to solve that problem!

Even if it's a bug in uTorrent...since it doesn't happen to everyone, your settings + torrent peers/seeds/trackers may be different enough to trigger a problem.

So...Are you getting Teredo/IPv6 peers/seeds? uTP peers/seeds?

Tracker errors?

Speed/Type of your connection...down and up?

Advanced settings you've changed in uTorrent?

...Lastly what regular settings you using as shown by CTRL+G?

Currently im using 1.82

I dont have IPv6/Teredo installed. I dont get tracker errors, I mainly use private trackers. I have my connections set to 200 max global, and have 3 upload slots per torrent. Normally only have 1 or 2 torrents running at once. My connection speed varies, but its normally about 4Mbit Down 768Kbit Up.

The only advanced setting ive changed is the net.max_halfopen ive set to 4 instead of I think 8.

What is uTP peers/seeds?

DreadWingKnight suggested to change bt.transp_disposition to 5 from 0, was that aimed at me?

EDIT: After searching for bt.transp_disposition I can see its for uTP, as I have it set at 0 in 1.82 is that ok? If I try 1.84 again, what should it be set to?

Why hasn't 1.8.3 auto-updated to 1.8.4 yet? It's been out for a few weeks already.

Because 1.8.4 has still bugs and devs are tracking them.

Ah, ok, that would do it.

mossmanfly, if you try v1.8.4 again set bt.transp_disposition to 5 to disable uTP both in and out.

If that seems to solve your problem, then it's probably the auto speed controls that are only enabled when uTP connections are present.

@Switeck --

I noticed the "drop to zero" issue after Windows Auto Update applied the KB971633 hotfix:

http://support.microsoft.com/kb/971633

http://www.microsoft.com/technet/security/bulletin/MS09-028.mspx

This hotfix addresses heap overflow vulnerabilities in DirectShow. It applies to Windows 2000, XP, and 2003. It does not apply to Vista & 2008. Theoretically any application that uses DirectShow could be an attack vector, but the existing exploits use Internet Explorer and Windows Media Player.

I removed the hotfix on my system because I'd already applied the killbits hack that Microsoft published before the flaw was corrected. I also don't use Internet Explorer, which helps. After removing the hotfix, the problem disappeared. When the hotfix automatically re-applied the next night, the problem returned.

I'm ignorant of the uTorrent code, but I suspect perhaps DirectShow / quartz.dll is used to play audio files within the application.

Hope this helps!

Directshow isn't used for anything.

Is there an estimated date for the next build update?

Never!

We don't deal in ETAs.

Hello,

we're trying to run utorrent 1.8.4 (Build 16442) on Linux(ubuntu), under Wine 1.1.29 on different machines and it is impossible, only work utorrent 1.8.3 or previews.

After installing 1.8.4 , we get a message that says:

" It seems like uTorrent is already running, but not responding.

Please close all uTorrent processes and try again. "

When you go to system monitor and kill the process, if you try to open utorrent, you again receive the installation process box.

After the installation proceed, the same thing happens, the "uTorrent is already running" message.

No error logs or similar was generated.

sorry to bring bad news and thanks for the help in advance.

PD: thanks for solve the ask process instalation problem under wine reported by other utorrent user.

jaimpe: see if this fix works - http://forum.utorrent.com/viewtopic.php?id=58864

Thanks user9475, nope, isn't a path problem. The process starts with 1.8.4 , but drops the "uTorrent is already running" message after first run on install. Whith 1.8.3 or previous work ok.

Hi guys, i had an issue with the availability number even before (strange number lots of 9 after decimal). But build 16667 disapointed me ... it made it worse, now it shows only the done field without the % format.

So guys, FmPoV the availability should be more accurate when there are fewer peers.

5.997 it's ok, but 16.997 it's useless (16+ will do). And if there are 5 seeders and 20 peers with (random) pieces, the availability should be shown as 10+, or smth, not (seeders+max peer availabilty).

One more thing ... I have a ADSL connection (6 Mbps down / 512 kbps up), I have to limit the upload to about 20 kB/s in order to download ok, is this normal.

Availability is always number of complete copies (each seed counting as 1, each complete set of pieces among downloaders you're connected to counting as 1)

So your 5 seeds + 20 downloaders may very well have 16 complete copies among themselves.

"I have a ADSL connection (6 Mbps down / 512 kbps up), I have to limit the upload to about 20 kB/s in order to download ok, is this normal."

That is rather low considering your connection should be capable of uploading smoothly at over double that speed.

Maybe uTorrent's other settings are causing overloads? 1st and 2nd links in my signature to fix that.

10x 4 ur quick replies.

@DreadWingKnight: Sry if I didn't make my self understood. I kind of know what availability is, but I don't really need to pinpoint all the decimals all the time, so this was a GUI improvement idea. Everything above a threshold should be shown w/o the decimals.

@Switeck: I'll try ur sugestions. Indeed the teoretical speed should be double on upload.

same problem, plentiful of seeds n peers...avail in decimals below all one.

Version 1.8.4 (build 16667) total fail, back to Version 1.8.4 (build 16150).

1.8.4 (build 16667)

@Nekit1234007: It's a known bug.

http://forum.utorrent.com/viewtopic.php?pid=429674#p429674

How come the server is serving us build 16442? Did 16667 get pulled back?

Yes.

µTorrent v1.8.4 build 16688 is up, which should fix the availability regression. Check the first post.

TO REITERATE:

µTorrent v1.8.4 build 16667 has been withdrawn while the devs look into the Availability regression.

Users experiencing problems with 16667 should redownload µTorrent v1.8.4 from the usual download location, which is currently rolled back to build 16442.