TraderJones

So, do we have a true "release" build of 2.0.3? If so, what is the build number? I see 20664, 20683 and 21777 out in the wild. Is 21777 not an official release?

As Rafi mentioned above it would be nice to have either a popup or a message for items that require restart after changing... I've apparently wasted quite a bit of time testing to try to figure out my disk io problem....

he could also read both my posts and realize I tried turning off the bypass. It didn't seem to change things. Firon, do I need to restart uT when I make changes to the cache settings before they take effect? I've tried changing the settings but didn't restart the program after each change....

As Rafi stated, is there a solution? I've tried various combinations on the disk cache preferences page with little effect. If I can't use the computer while 2.0.2 is running then I'll have to downgrade. I understand that you say this is a "stupid windows caching" issue, but why did it not occur prior to ver 2 of uTorrent? Something must have been changed in uT that affected the way it interacts with the caching, can't that be reversed? As an aside, do I need to restart uT when I change these prefs before they are applied?

Another tip, check your router settings and be sure that your port forwarding for uTorrent includes UTP!!!! Most of us configured our routers using portforward.com instructions which typically include opening the uTorrent port for TCP only. I had no incoming UTP connections and few outgoing until I was checking my router tables for another issue and noticed that the uT rule was TCP only.

I've noticed that now that I've upgraded to 2.0.2 for all torrents that when I do other disk operations, such as copy a file, my data rates drop by 50 to 75% while the disk io is occurring. This did not occur with 1.8.2 or 1.8.5. I've played with the settings on the caching page but it still happens. As soon as I do anything that reads or writes to any of the drives, internal or external the upload/download rates drop.

The number one tip that's not here that should be is.... reboot the computer after upgrading, before you run the new version. I don't know how many times I've upgraded and uT has hosed networking, but works fine after a reboot. After moving from 1.8.x to 2.0.2 I did have to change the windows caching settings as recommended above. I already have hard limits on my upload and download rates so no changes have been necessary (so far).

I agree with Rafi 110%. There are definitely two major contributors as stated in 1 & 2 above. The first requires education, both by uT (in the form of better upgrade instructions) and the second, coming up with a better UTP implementation to reduce that ridiculous overhead. Most users don't want to know or care to know how to set the caps correctly, you have to rub their faces in it. repeatedly. There are no easy fixes here, but I do think uT could be doing more on the side of education. Much of the behaviors around bad cap settings can be detected and some sort of visual warning could appear. Continue to fix the UTP implementation and shove some information down people's throats, not a lot else that can be done.

With all the memory leak issues, should the current beta be offered during the daily automatic update cycle?

wiii, are you running 1.8 or the *latest* 1.8.1 beta (build 12495). There's an issue that was recently fixed that caused 1.8 and some of the 1.8.1 betas to have issues connecting to peers. The last few betas connect just as well as 1.7.7 to most peers. Obviously there will be some issues with people running 1.8 that have enough torrents loaded to experience the same problem you are describing. Until those users update to the latest beta or the 1.8.1 release they will continue to be unavailable. The primary site I use has already decided to ban the 1.8 version once 1.8.1 goes into full release. BTW if you are having problems with 1.8, this is the wrong thread to be asking, as it's for issues with the 1.8.1 betas.

Yeaaaa!!! Latest build solved the connection to peers issue.... Was immediately able to connect to seeders and leechers on several torrents. Thanks!!!

Alus, I'll test with just 1 torrent active and see what happens. As for sending a torrent, I certainly can, the only issue may be that I don't use any public trackers at all. I'm not sure what you can do with a torrent from a private tracker.

@alus, Alus, I tested this on multiple (larger) torrents on a private tracker. I even went so far as to reboot the computer between installations of 1.7.7 and 1.8.1B to make sure there was no local caching on the machine for peer addresses. It's a private tracker and all torrents have the private flag set and DHT, PEX, etc are disabled in my settings. Regardless of the torrent, I see more peers with 1.7.7 than with 1.8 or 1.8.1B. Roughly 2/3s of the seeders and leechers do not connect or appear in the peer tab. Doesn't seem to matter what client they have, I did try to watch to see if it was more common with one client/version or another, but no real trending there. I'm not sure what I can supply that would help, please let me know if you think of anything.

Did a quick scan through the first couple o hundred torrents this AM and all are working properly. Connection counts on all trackers look good, so I'm not having the updating issue yet. Checked the stats and it's finally showing less than 25 connecting on the half open count which makes me feel a little better. @LittleMember, yes I'm sure about the peer connection issue, I've had several other users on the main tracker I use test this as well as myself. With 1.7.7 uploads and downloads on popular torrents connect to 3x as many seeders and leechers as with 1.8 and 1.8.1. Even on less popular torrents we rarely see more than 1 or 2 peers out of 5-10 with 1.8x, but with 1.7.7 we get all but the non-connectible peers. It's very obvious and easy to check.

Well, the latest update has stayed connected with all torrents for over a day so I would say that problem is solved. I set max_halfopen back to 8 and I'm still seeing x/8 connecting most of the time. Rarely drops off the 8 value. Bumped it to 25 just to see (I have tcpip.sys patched to 50) and within a minute it was at x/25 connecting and has stayed there for over an hour now. Not sure if that's a concern or not. So thanks for fixing this one. Now, can we look at why under 1.7.7 I can connect to 2x to 3x more peers than under 1.8 and 1.8.1? 8) Again, thanks for all your efforts.

Morning update. By late last evening I had all torrents back in seeding mode. The statistics for half open stay pretty much 1 or 2 with almost always 3 connecting. The tracker still sees me as seeding all torrents. It appears that the problem may only occur when I start uTorrent and it's trying to update all the torrents at once? Not sure how much this helps but if I start 100-200 torrents at a time over a few hours the "lockup" during updating did not happen. After lunch I checked on this and the torrents had begun hanging in "updating" mode. The stats for half open were showing 0/3 connecting and the number of torrents the tracker was seeing as seeded began dropping steadily. Stopped all torrents for about 20 minutes, half open returned to 1/1 - 1/2 and I was able to begin starting torrents again. It definately seems to be tied to the number of torrents trying to update.

Did some additional experimenting after I saw the other persons response above mine. Stopped all torrents for about 30 mins, statistics finally dropped from 3/3 to 1/1 half open. still bounced around a bit. settings, 25 max active torrents. Started 50 torrents, checked the half open over the next half hour ranged from 1/1-3/3. After 30 mins was still not 0/0. The tracker showed me seeding/connecting on 48 torrents, stopping and starting the two torrents then showed 50 seeds. None of these torrents became active during the testing, all were showing as Seeding in uTorrent and the updating appeared to work (ie no hang with "Updating" message). Started about 100 more torrents, after all were in seeding mode the tracker showed that I was not connectible on 5 of them. Stopping and restarting these 5 resulted in being shown as seeding/connectible. Periodically checked the half/open over the next 2 hours, ranged from 1/0 to 3/3, at the end of 2 hours was still recognized as seeding by the tracker. Started 200 more torrents, after all showed seeding in uTorrent, tracker showed 3 as not connecting, restarting these three resulted in tracker showing as seeding. Same result as above over the next hour. I will continue to start about 100 torrents every 2 or 3 hours until uTorrent "hangs" during the update process and let you know the results. (Any torrent that became "active" during the testing was stopped to try to minimize variables).

Tried this, within 2 hours the torrents started hanging on the updating process. Stopping all torrents and waiting 10 minutes made no difference the Statistics for half-open show half open: 0 (3 connecting) This was checked when the torrents starting hanging, again 10 minutes after stopping all torrents and then again after starting all torrents. When the torrents were restarted they still eventually reach "seeding" status even though the "Update In" column on the tracker tab never changes from updating. Checking on the tracker side I'm not listed as a seeder for any of my torrents after the 10 minute restart. Closing uTorrent and restarting works for a while. Moving back to 1.7.7 until this behavior is resolved. Hope this helps. PS. I updated to the latest beta before testing.

I've already rolled back to 1.7.7. I'll reboot the system this evening and try again and let you know the results of what you asked.

Correction, 1.8.1B hangs with the 'updating in' column saying "updating" and never coming back. Restart fixes problem for a couple hours.

Updated to 1.8.1 build 12132 after a few hours trackers show 0 seeds, but uT says all are seeding. I tried to update tracker and it says "updating" for a long time and then goes back to "working" I have net.max_halfopen set to 3. If I restart uTorrent the trackers start showing that I'm seeding again.