Vchat20

Had a weird bug show up today here, though really limited details on it so dunno if it was my goof or legitimate. Running the Setup Guide it says for the given port number at the bottom that setting it to 0 will make it randomize the port. Ok. Did that. From then on uTorrent seems to think I literally entered port 0 and will not change no matter what I do. The red icon on the status bar shows warning to change the listening port. Changing it in preferences and restarting uT did nothing and reverted back to port 0. Even trying to change it in the Setup Guide afterwards refused to make a permanent change. The only way I found to fix it was wiping all the dat files in the AppData folder and re-running the installer to reset everything.

Looks good on this end for torrent creation. Assuming it was an OS-agnostic bug as it was affecting my XP machine as well as my Win7 laptop. Both are creating fine now though with build 16666.

This newest build seemed to kill torrent creation for me. Not crashing, but when it goes into the file hashing process when you hit the create button once it hits the far end it just sits there and no save dialog. And cancel doesn't do anything. Have to close out uT and bring it back up.

@Switech: Yes, I do have all that stuff enabled. Thing is though, like I said before, this has all worked flawlessly with no lag whatsoever and no abnormal activity for ages using 1.8.1 and older versions with the limits in uT properly configured. Just observing its functioning, uTP doesn't seem to be obeying those limits like it should. Not to mention the whole idea was for uTP to yield to all other traffic and not cause this problem in the first place. It's pretty clear cut. Nothing changes aside from the uTP/uTP+TCP/TCP setting. DHT, resolve ip's, scraping, LPD, etc. All remain set. If I have uTP or uTP+TCP set, eventually ping times spike up to 1s at a minimum and web browsing becomes an absolute bore. Switch it back to TCP only and do a restart of utorrent and things return to normal with 50-100ms ping times under normal operation and strict obedience to set limits. If there's any way I can help debug this, do let me know. I'm willing to help in any way I can. Already got wireshark here and y Smoothwall box is essentially a linux based router with all the usual facilities like iptables access and the like.

@Firon: I'm really confused though. Even if the smoothwall box is not tracking the UDP traffic properly and somehow showing me I'm not maxing my connection even though it might be through uTP, shouldn't utorrent still be keeping this in check with its internal throttling mechanism without even taking upstream QoS into account? Here's the situation: 99.99% of the time utorrent's about the only thing using the connection here. In addition, I have it set to around 80% of the connection usually like 8KB/s upload and 70KB/s download (raw speed of the connection at best times should be 96KB/s=768kbps and 16KB/s=128kbps) and even with those limits in place alongside the fairly conservative connection limits uT puts in place through the speed guide control set at xx/128k, the aforementioned lag problems still crop up. Not to mention the whole idea that's been instilled so far is that uTP is supposed to yield to all other traffic and prevent problems like this?

I actually want to confirm an issue an original poster made and that is that the uTP protocol seems to be introducing some lag issues. And in my case it has been severe on the order of constant 3s+ ping times on a normally ~50ms cable connection. It's a 768/128 connection but not only is uT throttled back properly, but I have a smoothwall box set up with the QoS system properly modified to keep torrent connections at bay even if I have uT set with throttles past what the connection can handle. 1.8.1 has been flawless up to now. And even 1.9 is fine as long as I have it set to TCP only. When uTP only or uTP+TCP are used, the high ping times return. And according to the smoothwall box, I'm not even maxing the connection when this happens.