MoJo

Same as those before me. uTorrent just locks out and has to be closed manually through Task Manager. Now I'm not sure if it is a HDD overloaded issue or something else, but I can tell you that a Memory Leak is also in process. uTorrents memory footprint is a whopping 2GB, and this has been happening ever since version: 18429 - 18581, not too sure exactly. I was going to come and post earlier on but usually these sorts of things are fixed before I even consider making a bug report. Any updates as to what it could be, these freezes are a menace. Could it be related to some Windows updates? Last couple of weeks has had a couple of updates from MS.

Doesn't seem to want to install in Win7, keeps stalling in the install wizard I believe the final step.

Hey Kiwi I have observed this phenomenon as well and the way I got through with this is the following. Before I begin, my QOS has been administered from my Linksys Router running Tomato. Now initially I had one rule and it was port based, uTorrent ran with a mind of its' own. Now what I changed to that worked was having two rules both were still port based and now also protocol based, one for UDP and the other for TCP. I gave the TCP transmissions a Higher Priority compared to the UDP. Another way doing this is to have a single TCP and Port based rule set to whatever Priority you like. The reasoning for this is that uTP built into uTorrent is designed to rate limit the UDP part of the connection automatically, it doesn't perform well when outside influence is put in place. What I have observed is that with both TCP and UDP on the same QOS lane, uTP doesn't seem to stay ahead of the QOS curve (a uTP frequency cycle issue?) So again, I have a bad way of explaining things, but what I'm saying is that you should make two lanes for both the UDP and TCP parts of the transmission, preferable with UDP being either lower (hence it can perform better as a way to help TCP by sensing congestions faster) or auto govern itself with no rule put in place for the UDP aspect of the connection on that port. Hey is a next beta coming? This is seemingly more and more becoming like Google Projects as things just won't come out of Beta? Please folks spare me the knee jerk reaction for saying that last sentence an old timer here just can't help but wonder? Edit: On second reading, I seem to have replied in a tangent. But you need to give more details. Simplest thing is to do a step by step approach. First reset all settings back to default, and re change things until you find what is wrong. Change the settings in the Advanced settings page last, as that maybe where the problem is coming from. My hunch is that the problem could be that there may internally (through the Advanced settings) be two IP's uTorrent is trying to bind with ... net.outgoing_ip, and net.bind_ip. I believe the conflict is that there is two IP's trying to use one Port. Or the problem could be that the Advanced setting net.outgoing_port has a port associated to it and you didn't see it. More info would be good in this case, but if you want to give it a crack my settings (which is similar) is the following for those problem settings outline: net.bind_ip is (empty space) [Default] net.outgoing_ip is (empty space) [Default] net.outgoing_port is 0 [Default] [Default] means that it is the default setting, and you can reset it from the Advanced settings page. All other settings are done through the non-Advanced settings page, primarily in your case the Connections settings page is your place to set things right. So then set your port (it encompasses both TCP and UDP), and make sure "Add Windows Firewall exception" setting is checked off. Now remove the Windows Firewall rule you made manually (if you did?), as it could conflict with the Auto rule exception that uTorrent will make on start-up. Hope it helps, and the top part is for the QOS setup later on

I'm with Neronut, uploads seem to have a mind of its own. It is going all over the place, no matter what restriction.

I was wondering if anyone ever checked out the G2 Spec, it dates back from 2003 when this idea of using UDP as transport medium in P2P was first used. http://g2.trillinux.org/index.php?title=UDP_Transceiver Any tech heads willing to compare and contrast, and what is different? I'm from Shareaza btw, just want to share my experience with udp based file transport. The only problem with UDP is that you can't have your cake and eat it too. The Shareaza client oft times never follows the Bandwidth limitations because of the dynamism of Network congestion, and the constantly changing downloaders and uploaders in the queue. So what I'm saying is that the trade-off seems to be control for a proper reflection of network conditions. Definately Shareaza doesn't have flow control ... more of a conditional connection states, briefly the criteria is shown on the spec relating to UDP found above. EDIT: I wanted to say that the losing control for a more reliable connection is reflected in these current uTorrent betas. I also avidly use uTorrent, so I've noticed UDP never seems to fill up my upstream as an all TCP connection used to. Now I seem to average 59KB/s when on TCP I did 65KB/s ... really moot difference but still a 9% change.

So I noticed effectiveness of uTP when used with QOS. Current problem is the TCP side of it doesn't scale that quick enough, so using my Linksys GL router with Tomato firmware installed I setup a QOS rule. Pretty much the QOS rule sets out TCP only connections on my uTorrent port to a Low priority ... UDP is not classified, which automatically gives it the Lowest priority. Now whenever I use uTorrent it seems to scale a lot better, and other applications ie. Newsgroup (AltBinz) becomes more responsive. I think what is happening is that uTP perfectly scales back based on congestion, and TCP stays within the users preset levels, uTP sort of covers the slack as it will pick up more speed when things are uncongested and slows down when the network is saturated ... while TCP remains constant.

Hey anyone noticed these builds don't somehow update the ratios on private trackers? Is this an artefact, I'm I just seeing things or has anyone else noticed this aswell? I seed back at a ratio of 1.25, so meaning I upload fllu back and give a quarter more to nudge my ratios up in the long run as I download more ... my ratio has been going down on the Big E, (empornium) ... and I swear I reseeded 125% all the time ... wierd ehh?

Hey guys, I just checked this beta out and already see a tremendous impact on my bandwidth. I have I am downloading from binary newsgroups at nearly 90% speed with uTorrent 1.9 build 13485 chugging along seeding at about 70% of my upload capacity. Before, on the previous versions it seemed as if the dual between David and Goliath ensued when both apps were running side by side. In the past, a slightly used uplink created a bad download rate, like a simple drip creating a ripple that turned into a wave. I get best of both worlds now, I'm seeding while I'm downloading from another place at nearly full speed ... a fair compromise. I'll do more comparitive analysis later, now I go to watch my pRon.

Yep this feature is worthless without a major portion of the BT userbase using it. BitComet didn't have a public beta of there PHE, it was just released ... and that gave it the effect of working right off the bat. So this feature is tied in with the userbase supporting it, which as of now is a limited amount of beta testers spread over the net.

Can you also list Shaw Cable of Canada as one of those ISP's that packet shape. Can the list also use a standardized format, it'll look cleaner as the list gets bigger. [#] | [iSP Name] | [Type DSL/ Cable] | [Country] | [Type of Limiting Packet Shaping/ Port Throttle] | [Possible Solution] For Example: [1] | [Rogers HighSpeed] | [Cable] | [Canada] | [Packet Shaping & Port Throttle] | [use Port 1720, Reference]