Jump to content

µTorrent 3.3 Stable


cmeisel

Recommended Posts

You recommended me your settings.dat and never mentioned any guideline.

Sorry about that. Maybe you canot read... I thought that all is being explained in tip #0 in my guide, as you can see in my sig...v There is no one-settings for all connections thing. Thus I have 3 sample files...

Link to comment
Share on other sites

  • Replies 619
  • Created
  • Last Reply

Top Posters In This Topic

You see ? It wasn't too difficult, right ?...

LOL!...You are assuming I haven't compaired them before!

No, I only assumed that most users do not care less about the details, but just for a quick fix to slow downloads...

Link to comment
Share on other sites

I'm aware that this is triggered by something on my system. My temporary and finished downloads are stored on a Truecrypt encrypted HDD. While straight throughput is acceptable, I doubt with many I/O requests this drive performing adequately, although my high I/O test didn't raise the CPU load caused by the truecrypt.sys threads to exceed 1%, maybe that it isn't very high, should be cause for concern? Although random seek performance of HDDs is so bad, that Truecrypt probably is able to cope.

So here's the thing I do know: until the disk I/O code rewrite of 3.3, this was never a problem for µTorrent. Having said that I also remain sceptical whether Truecrypt is one factor, I doubt it for the observations stated above but I just don't know, it could be locking up disk writes in some rare cases, but I don't know, it's all assumptions without much substance to back them up, so it's not suitable for dismissing or proving anything.

What I do have seen is that µTorrent wrote incoming blocks into memory but not flushing them to disk until it either ran out of memory and crashed. Or when the torrent was was small enough, it fully downloaded not crashing µTorrent, but only to freeze up, not getting flushed, with µTorrent hogging that extra physical memory indefinitely. Very nicely observable with Process Explorer, a linear increase in physical memory allocation by the µTorrent 3.3 process right up to the moment the download finished. The overall increase being the delta of the size of the completed torrent and the size of the parts that actually have been written to disk until the cache fuckup initiated, which usually occured around the ~400-500MB mark. So I assume it's µTorrent's fault, but I cannot say that for certain. Why could it be that µTorrent 3.3 is the only application on my system that is being denied cache flushing by a supposed bug in a system driver? Or could it be the disk cache code of µTorrent itself? Which happens to undergone a major rewrite with just the version I seem to have so much trouble with...

Hrm.......I think maybe we're getting closer to the problem aswell.....I use TrueCrypt too and only the new 3.3x versions after the disk I/O rewrite crash for me.......

Link to comment
Share on other sites

That's interesting. If I may speculate some, if the problem really is Truecrypt related and this isn't just a coincidence between us two, I'd guess that the new caching system in 3.3 is bypassing some Windows routines which are essential for the truecrypt.sys driver to flush to disk.

Having said that, I have tried in version 3.3 setting "Disable Windows caching of disk reads/writes" to off, of course, with no effect. The bug still occurs. Also I'm currently running 2.2.1 with this setting enabled (=windows caching disabled) without problems, btw.

Link to comment
Share on other sites

Went back to 3.2.3 to test the WebUI lagging I was having in 3.3, have upgraded to 3.3 again and have just had it fail to connect to the WebUI. I selected files to not download and it wasn't updating and then timed out. I've had zero issues with 3.2.3. This is running on a atom N455 on 7 starter with 1GB RAM. I do have the low CPU option enabled if that matters any.. Anyone else use the WebUI and having any similar issues? I'll disable the low CPU setting and see what happens..

Link to comment
Share on other sites

have upgraded to 3.3 again and have just had it fail to connect to the WebUI

Does it happen with 3.3.1 too?

Mine just say Connecting... 3.3.1 RC.

Not sure when it last worked.

Edit: Some logs:

[2013-05-18 20:08:31] Error contacting WebUI proxy service: connection closed by peer

[2013-05-18 20:08:31] Disconnected from WebUI proxy service

[2013-05-18 20:13:30] Error contacting WebUI proxy service: connection closed by peer

[2013-05-18 20:13:30] Disconnected from WebUI proxy service

[2013-05-18 20:18:39] Error contacting WebUI proxy service: connection closed by peer

[2013-05-18 20:18:39] Disconnected from WebUI proxy service

Link to comment
Share on other sites

have upgraded to 3.3 again and have just had it fail to connect to the WebUI

Does it happen with 3.3.1 too?

Will know once it's released and my trackers have approved it.

Haven't had any issues yet with 3.3 having disabled low CPU, but we'll see..

I'm fairly certain I didn't have low CPU set when I first tried 3.3 and had connecting issues.

Link to comment
Share on other sites

They've hit RC, so they'll probably rush to release a final without fixing a whole lot of stuff..

Ask yourself: if the rest of the "stuff" is an improvement over 3.3 "stable". If the answer is 'yes', why not release it ASAP and deal with "your" stuff at a later version?

Oh, and it seems like "my" 3-points-'stuff' is still being attended to... http://forum.utorrent.com/viewtopic.php?pid=730000#p730000 :)

Link to comment
Share on other sites

  • 2 weeks later...

I don't think so rafi

I just downloaded 3.3.1 and the bug is still there, With only seeding to 1 peer at interwalls

then tried 3.4 alpha and there i had no peer info/list showing up in GUI (downward) even if several was Connected.

So i'm back on 3.2.3 (build 28705) wich Works (you can find it on <site not allowed>.com)

I'm not alone as i found others who have similar trouble

http://kuiken.co/torrent/8411038/Software----Utorrent_3.2.3__use_until_v3.3_bugs_are_fixed_please

If you have 'upgraded' to Utorrent 3.3 you are not seeding as well as you should. There is a bug which means you will only connect to one seeder/peer at a time instead of several.

This is causing problems for our seeding (and for other uploaders too I would assume) as each torrent takes alot longer to get a life on its own, and thus we have to wait longer betweeen uploads.

So please download this or any of the other Utorrent 3.2.3 builds until V3.3 is fixed.

Can the cause for this bug be that i don't uninstall old Utorrent before. And i just replace/overwrite With New EXE file

If i do sow, will i lose my old torrents (file data list) ?

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...