elsdon

Hi there, As I've been trying to guess at what you need from the end-user to assist with troubleshooting some issues, I haven't received a response/acknowledgement that you've even read any of my posts. Can one of the active dev team reach out to me? I have been a long time user and appreciate the time you've all invested developing this software. If I can even contribute a little via testing and diagnostics, that would be great. Thanks.

Thanks to the uTorrent team for continuing to push forward on their efforts to improve their product. I wanted to just take a moment to touch upon some of the issues that I've encountered prior, and currently. I've noticed a lot of the staff here chiming in and responding on cosmetic issues, tabs, columns, etc. but I was curious why nobody has responded to any of the issues I've raised on the actual operation of the newer client. I've made two fairly extensive posts in the 3.0 alpha thread: http://forum.utorrent.com/viewtopic.php?pid=573850#p573850 http://forum.utorrent.com/viewtopic.php?pid=573958#p573958 With no response as of yet. I've installed the newest beta again now and have encountered the same issues. Can somebody on the staff take a look and shed some light on the subject for us? I don't think I'm the only one reporting high CPU idle and/or disk overload issues. Before you give me the canned response, please keep in mind that I have searched far and wide, played with all the disk caching options and put forth a solid effort trying to troubleshoot the issue myself. Thanks, elsdon

Hi again, Updated to latest alpha: 25127 EDIT: Seems I spoke to soon.. The CPU usage seems to be directly correlated to the seeding of torrents. It's reproducible, when I stop all torrents, it is ok. When I start seeding them again, CPU usage climbs back up again. EDIT2: Downloading isn't fixed either. I have mirrored a number of different disk caching settings on this forum and all have resulted in the same issues. The first GB downloaded fine, approximately 4MB/s, then 100% disk overloaded issues for like 15 minutes on this 3.0GB file, then back up for 4MB/s again. The RAM cache I've dedicated to this is interesting enough, 1024mb. Did it not write a single thing to disk until it filled up the ram buffer? EDIT3: Haha. At exactly 2GB out of 3GB, it stopped and is at 100% disk overloaded again. I'm not sure what is happening.. Is it seriously not writing while it fills up the buffer? Forgot to mention that in resmon my disk is only writing at 2MB/s-5MB/s so it seems like something kind of major inefficiencies in the way that uTorrent is calling the file copy/chunking. Doing standard tests (http copy, ftp copy, explorer file copy, robocopy, xcopy, and linux dd inside of a vm) my disk is capable of read/writes averaging between 40-70MB/s quite easily. Taking a deeper look at resmon shows uTorrent writing 2kb-3kb/s in each of the directories of each of the torrents that I am seeding. I am seeding roughly 100 torrents so it's the 100x2-3kb/s that is contributing to the 2MB/s-5MB/s usage I see. What is uTorrent doing? Where is the bottleneck that is causing uTorrent to think that my disk is at 100% i/o capacity? Another piece of useful information: every single directory in the set of seeding torrents has been modified today. It seems like uTorrent is going in and either writing a file and deleting it or something? Noticed some change in the way it no longer seems to be constantly updating files. SearchIndexer has calmed down. I also noticed that since updating to 3.0, the start up time seems drastically increased from 2.2. I was wondering if you could give me a high level overview of what's different in the init sequence? It still doesn't seem to exit elegantly though, for whatever reason. I'm typically forced to kill the process tree to get it to stop. One of the possible side effects of not allowing uTorrent to exit elegantly is: a) deleted some of my files that were already complete corrupted the completion status of these files It became evident because I had some torrents that have been complete for months and I've just been seeding them, but now I'm forced to rehash them based on the .torrent files and re download pieces of them. EDIT: I've noticed some interesting behaviour. In the directory structure of all of the corrupt torrents, I see an existing original file named: xxx.file but now I see a seemingly duplicate file named xxx.file.1 of same size but no idea of the content. My concern revolves around, well, what is uTorrent doing playing with torrents that are already complete? What is it shuffling around, at the file level, and why? This type of behaviour would explain why previously my HD i/o was going nuts at an idle and why uTorrent was constantly using ~30% CPU. Let me know if you need more details. Thanks. Ended up downgrading to 2.2.1 with much success. All my tabs were out of wack, but that's to be assumed given the different tab configuration and numbering that was in my registry. 2.2.1 is working as expected, no CPU issues, no disk throttling issues, etc

Hi there, Been using 2.2 for a long time, had no issues. Saw some of the new built-in web/mobile functionality in 3.0 and it piqued my interest. In retrospect, seems like a bad idea as now uTorrent seems to be constantly chewing CPU. (idling at ~30%) Did a few snapshots of thread/stack dumps, not really sure what it's doing.. Here are some excerpts. It should be noted that: - Running Windows 7 32-bit Ultimate - AVG is running, have noticed an increase in hard memory faults since upgrading - uTorrent has been running for 2 days straight without turning it off Not sure if this is correlated but it seems to have been a catalyst as well for Windows 7 Search Indexer.. It's constantly running on my machine now. HD i/o utilization is roughly 7-15MB/s constantly as I think it's a combination of uTorrent and SearchIndexer.exe trying to constantly update the indexes. Suggestions? ntoskrnl.exe!SeAccessCheckWithHint+0xb4a ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x7d2 ntoskrnl.exe!KeWaitForMutexObject+0x19f ntoskrnl.exe!PsIsSystemProcess+0x94 ntoskrnl.exe!KeStackAttachProcess+0x11c1 ntoskrnl.exe!ObReferenceObjectByPointerWithTag+0x233 ntoskrnl.exe!KiCheckForKernelApcDelivery+0x2 fltmgr.sys!FltReleasePushLock+0x262 fltmgr.sys!FltIsCallbackDataDirty+0x3d9 fltmgr.sys+0x16c7 AVGIDSFilter.Sys+0x5c8e ntoskrnl.exe!NtClose+0x16e ntoskrnl.exe!ObfDereferenceObject+0xd4 ntoskrnl.exe!SeAssignSecurityEx+0x764 ntoskrnl.exe!SeAssignSecurityEx+0x664 ntoskrnl.exe!KeSynchronizeExecution+0x3a43 ntdll.dll!NtClose+0xa wow64.dll!Wow64EmulateAtlThunk+0x196d wow64.dll!Wow64SystemServiceEx+0xd7 wow64cpu.dll!TurboDispatchJumpAddressEnd+0x24 wow64.dll!Wow64SystemServiceEx+0x1ce wow64.dll!Wow64LdrpInitialize+0x429 ntdll.dll!LdrGetProcedureAddress+0x240a7 ntdll.dll!LdrInitializeThunk+0xe ntdll.dll!NtClose+0x12 kernel32.dll!MoveFileWithProgressW+0x1b kernel32.dll!MoveFileW+0x16 uTorrent.exe+0x2c2c1 uTorrent.exe+0x2c417 uTorrent.exe+0x275a7 uTorrent.exe+0x26712 uTorrent.exe+0x26857 uTorrent.exe+0x268a0 second chunk ntdll.dll!ZwSetInformationFile+0xa wow64.dll!Wow64EmulateAtlThunk+0x7525 wow64.dll!Wow64EmulateAtlThunk+0x7af1 wow64.dll!Wow64SystemServiceEx+0xd7 wow64cpu.dll!TurboDispatchJumpAddressEnd+0x24 wow64.dll!Wow64SystemServiceEx+0x1ce wow64.dll!Wow64LdrpInitialize+0x429 ntdll.dll!LdrGetProcedureAddress+0x240a7 ntdll.dll!LdrInitializeThunk+0xe ntdll.dll!NtSetInformationFile+0x12 kernel32.dll!MoveFileWithProgressW+0x1b kernel32.dll!MoveFileW+0x16 uTorrent.exe+0x2c3e3 uTorrent.exe+0x2c417 uTorrent.exe+0x275a7 uTorrent.exe+0x26712 uTorrent.exe+0x26857 uTorrent.exe+0x268a0