ezcry4t3d

Haven't been back here in a long time because I'd gotten tired of waiting for any forward development on the torrent client part of uTorrent. Specifically, I've been waiting for "append torrent label" to be re-added as a directory feature before I can go back to updating my uTorrent client. I grabbed this current RC version to see if it's been re-implemented. Fresh Install on a test machine (I've finally learned to test things BEFORE I mess up my torrent box), first run, I get a screen full of what I guess are ads, two of which have completely naked chicks in them. WTF Assholes, I have kids at home that don't need to see your porn. MY suggestions to your company: Throw the last couple YEARS of "developement" in the trash. Stop trying to be a media player, a social network, a toolbar installer, and whatever else, and focus on developing a TORRENT CLIENT. I could care less about streaming ads, I know you have to keep the programmers fed. But you have to add features that someone who uses torrents from multiple servers can actually use, like label based limiting, ratios, and directory sorting. Not that I think any of that will actually happen at this point, or that anyone at the company will even read this. So, peace out.

Advanced->Disk-cache Override auto.... = 32M (default) + unchecked... + General->preallocate - unchecked + how should I know what else you've set on your own... And for me - this is called a flat CPU line... no 100% or 10% spikes. Maybe you AV acts up or something... http://www.imagebam.com/image/dfe408244000008 I crashed the disk subsystem again. http://img854.imageshack.us/img854/2065/diskcachefail2.png Per the graph, it filled the 128MB cache and then stopped downloading. After a short bit, it decided to screw the cache limit and just put the rest of the data in there too. How did I crash it? I selected 35 torrents, right click, Advanced, Set Download Location. Picked a shared drive on my server for each of them. It moved 32 before it died. Not sure if the copy killed it or if I started a new torrent before it was done and that killed it. But, when I started a new torrent it stuck on "allocating" and it downloaded all 763MB of torrent into the 128MB cache and won't write a thing to the disk. It is no longer moving any torrent data either, although the last 3 I moved still have a status of "Moving" It moved 14.6 GB of about 17GB before stopping. As far as the CPU spikes, I have no AV and it's the utorrent process going to 100%... An argument could be made that there are repeating spikes on your graph as well, you just have enough CPU that it finishes whatever utorrent is doing before it hits 100%. My P3 866MHz does not have that luxury, but I did not see the spikes with utorrent 2.x., so I don't know what utorrent is doing differently now.

So far so good.... Re-tested your CPU spikes with that settings ? >I am seeding about 100 torrents... Ideas? 1. Don't. My settings do not allow that... 2. Upgrade your CPU/hardware... ; 9 hours and disk subsystem still hasn't crashed, nice. Which utorrent checkbox do you suppose needs to be relabeled "crash disk I/O subsystem"? (On an unrelated note, where did the Preferences -> Directories "append torrents label" checkbox go in the latest version? I miss that.) Those are fresh screen grabs with your settings file. It was also doing it before your settings. It still spikes the CPU in the same intervals even with no torrents active, the CPU usage between the spikes is just far lower. Whatever it's doing is either broken, or needs to be spread out so it's not freezing up the UI. I'd bet it does it on other hardware as well, my old hardware just makes the spike more noticeable since it plateaus at 100% for far longer than a new CPU would. 1. What needs to be changed in your settings to "allow" 100 seeding torrents. (It looks like they're seeding fine to me...) It is very rare that any of them are active, but I will be keeping 100 seeding for the foreseeable future. 2. Shall I PM you the address to send the new hardware or the email address to send the PayPal money for the new hardware? uTorrent runs fine on the dedicated 25 watt box. It keeps it from slowing down my personal desktop and I don't have to run my 200 watt desktop 24/7.

Loaded up your settings file and I'll try to get the disk subsystem to crash now. So far it's gone for an hour. On to the next problem with 3.3+ UI Freezing while CPU spikes. http://imageshack.us/a/img203/5137/bandwidthl.png http://imageshack.us/a/img9/8849/cpuur.png This is while it's going full speed on my connection, 15MBit down 2Mbit up. The CPU spikes still happen just as bad when no torrents are downloading, just seeding. CPU is only a Pentium 3 866MHz, but uTorrent is the only thing it runs, so it is sufficient. The CPU spikes roughly correspond to the times bandwidth is lost on downloads (makes sense) but what the hell is the new uTorrent doing every 90ish seconds that kills the CPU? DHT is disabled, so it should not be that. I am seeding about 100 torrents, but I've seeded 700 before and I don't recall the problem being any worse then. Ideas? Also, thanks rafi for your help.

I applied those settings long ago. net.low_cpu = true reduce memory usage when the cache is not needed - unchecked gui.transparent_graph_legend = false pre-allocate All Files - checked

The new Disk I/O system is unstable. I have a dedicated XP box with nothing installed except uTorrent which runs 24/7. It has been this way for YEARS. I have no trouble running any versions of uTorrent prior to 3.3. In fact, 3.2.0 build 27886 is running stably right now and has no trouble running for weeks at a time without incident. (So, blaming my machine is a bit ridiculous.) When running 3.3, uTorrent eventually stops writing to the disk, sometimes within minutes, but always within 48 hours. It continues transfers afterwards, putting the data in the cache until it eventually crashes. Exiting uTorrent after the disk subsystem has stopped results in the uTorrent process never stopping. Stopping the process results in all files downloading being in an invalid state and requiring re-checking. Specific versions I've seen this error in include: 3.3.0 29126 3.3.0 29342 3.3.1 29213 Here are screen caps from Disk Statistics and Disk Timing after a particularly brief run and failure. http://imageshack.us/a/img10/7079/diskstatistics.png http://imageshack.us/a/img194/512/disktiming.png Note the bottom left pane of Disk Statistics screen, uTorrent starts downloading, file writing to disk stops but uTorrent continues downloading to cache until I pause all downloads at the end of the graph. The uTorrent process never recovers and never writes out the data from cache. As you can see on the left in Write Statistics, cache size is 861MB of 31.9 MB. As to cache settings, in basic settings both boxes are unchecked, in advanced all boxes are checked. I have never installed 3.4, so problems do not stem from it not being uninstalled properly.

Ever since 3.1 I've been getting perhaps 10% of torrents that stop at 99.9% with one or two pieces that repeatedly fail CRC checks. The torrent is actually completed, however, and sfv checks and rar extraction verify completion. Any ideas?

As far as the load time difference, I believe I can explain what's going on. When this new utorrent starts up, it hits the file system and checks that every single torrents files exist on the drive, regardless of the torrents status, it does not matter if they're stopped, finished, or whatnot. It sparked quite a discussion in the previous beta thread. The result was that it is an intentional change and they will not revert it. So all 2000+ of your torrents are having an existence check on every single file they contain every time utorrent loads. The solution is to either remove all the torrents from utorrent or revert to the previous version.

I have to agree with GCRaistlin. Until you implement this archive method set the file check back to it's previous behavior. There is no reason to check files on finished torrents unless the torrents are manually restarted. My P3 866MHz torrent box does not appreciate checking thousands of files on finished torrents every time utorrent starts. It is annoying for no reason and goes against utorrents (very) tiny and efficient ideology. On a different note, has there been any discussion on expanding the power of labels so that they can control other things about torrents beyond download location, such as minimum ratio and seeding time? I know this feature has been requested many times for many years.

Now that I've had some time to poke at this some more... It only screws up on torrents with single files in them. I'm guessing that the first one that completes gets moved as the folder name instead of being placed inside your completed folder. This first one still seeds from the misnamed file. Every single file torrent after that does not get moved, presumably because the misnamed file already exists. As soon as these complete the torrent breaks and does not seed. I was finally able to get these broken torrents pointed back at the proper files and seeding by using the Advanced->Set Download Location option and MANUALLY inputing the full file name. (Since the open dialog will not actually show any files) Also, in preferences I have "move completed downloads" set to a folder and also "append labels" checked. (along with all the other folders on that preferences pane set) Hope that helps debugging some.

Agreed, it's totally hosed everything I've downloaded. Files renamed to "Complete" instead of being moved into the "Complete" folder.... Trying to point the torrents back to the files to restart them seeding results in the file selection dropdown being full of nonsense ASCII and it won't display any files, even when set to show "All Files" This is XP, and the logged in account has full admin rights, so it shouldn't be a permissions problem.