Jump to content

µTorrent 3.0 "Falcon" (32-bit) alpha 25207


Firon

Recommended Posts

  • Replies 1.5k
  • Created
  • Last Reply

Top Posters In This Topic

In other words, I can't reproduce this, so I need more info. :P Anything else you've changed? Sparse files? Compact allocation? Pre-allocate? Prepend !ut ?

It would actually be useful to get a full memory dump of uTorrent while this is happening, in addition to the other info. To do so, in the task manager, go to Processes, right click on uTorrent.exe and hit Create Dump File. Compress this, upload it to www.mediafire.com and email the link to firon at utorrent.com

Thanks!

Link to comment
Share on other sites

Are you using default cache settings or not? default and all other settings default

Downloading more than one torrent at a time? only dl/ul one torrent at a time

Almost out of disk space? no

Writing to a network drive? no

In the pieces tab complete pieces don't get removed.

Link to comment
Share on other sites

Yes, I know.

I did mean that when I right click the µtorrent process in the task manager, the create dump option is greyed out.

I also second rnr's observation on complete pieces not clearing out.

What's more, on restart, µtorrent starts rechecking the torrent file on its own.

Link to comment
Share on other sites

I started playing with many settings to find a possible trigger for the continous 100% CPU issue, and it seems I found a workaround:

- set "bt.determine_encoded_rate_for_streamables" to false.

- restart uTorrent;

However, as soon as I change the option back to true, even without restarting uTorrent, the CPU jumps instantly to 100% and remains there.

At the time of the test I had 96 torrents in uTorrent, all idle - not downloading or seeding - out of which: 10 were not streamable, another 8 were streamable but had an error status because I moved the videos to different folders after the download was completed without informing uTorrent, and 78 were streamable and their status was finished (but less than half of them had a green round play icon, the rest had the gray square play button) ;

I'm using Windows 7 x64.

As an added bonus, during my search for the cause of CPU issues, I found many advanced options that I overlooked until now, and some of them sound very much like some features I was requesting, for example "bt.prioritize_partial_pieces" and the "streaming.*" options.

I will test streaming as soon as possible with the "bt.prioritize_partial_pieces" option enabled to see if it makes any difference.

Later edit: it doesn't make any difference. uTorrent still "forgets" that some blocks (colored white inside the pieces) are required for streaming while VLC is open, and suddenly "remembers" them and starts to download them as soon as I close VLC (the white blocks required for streaming suddenly become green as soon as I close VLC).

And I'm using version 18936.

Link to comment
Share on other sites

Sent you the dump Firon.

I haven't changed anything except the default player for streaming and added a few columns to where the list of torrents are.

i think i've found out what's wrong with mine. one of the torrents i have running rechecks itself whenever i restart uTorrent, even after shutting down properly. once it finishes, i get the disk overload 100% none of my other torrents are doing that. i never noticed it earlier because it was an 18 gb download and took so long to recheck.

Link to comment
Share on other sites

I previously reported that files in finished torrent directories get ".!ut" appended to their names whenever I start µTorrent version 2.1 despite all the files remaining marked 100% complete on the µTorrent Files tab (I have "Append .!ut to incomplete files when downloading" option enabled). This always happens when a multiple file torrent contains at least one video file. Re-checking the torrent will remove the unnecessary ".!ut" appendages but also clears the torrent's "Completed On" date! Momentarily starting the affected torrent(s) removes ".!ut" from file names without disturbing "Completed On".

I neglected to mention that "Error opening..." messages would sometimes also be logged at startup.

I reported in the same post that if I add a torrent I had previously downloaded and removed from my Finished list then re-check it, the Done percentage indicator always stops at around 99.5%. I have to re-check a second time for the torrent to be indicated as 100% Done.

Today I found that these problems are a result of Advanced option "bt.determine_encoded_rate_for_streamables" being set to its default value of True. Setting this option False resulted in no more problems for me whenever I start µTorrent version 2.1. I am especially glad that re-checking multi-file finished torrents containing video files no longer clears the "Completed On" date.

I am running Windows 7 x64 and have made sure that the directory in which my finished torrent files are stored (on partition D) is not being indexed.

Link to comment
Share on other sites

Here is my dump of disk overloaded state (uT 2.1.18936): Dump

This happens with tampered manual cache setting of 200MB and with auto. The writing cache just fills up and uT makes no attempts to flush anything to hdd.

I have enough space and the hdd is not on network. Downloading a single torrent (streamable) with 25 files at quite low speed of 100-150kB/s considering the 200MB cache. And it still fills up. Having multiple downloads at 5MB/s combined doesn't produce any different results. On exiting it still runs and has to be manually closed through Task Manager. Running Win7 x64.

Will try to enable windows caching...

EDIT1: Yay! uT hung big time after trying to change from Disk Statistics to Files tab. But cache was written out very peacefully with windows managing it... Dump

EDIT2: *sigh* The hang is reproducable. Even by doing nothing. Win caching enabled.

EDIT3: Now that's is getting weird. Without any write caching enabled uT managed to succesfully operate for about exactly 20 minutes. Currently, even with cache being disabled, it is being filled. No hard disk writes from uT side... This might have happened when I deleted some unrelated files on the disk in question.

As a side note: no uploading can take place... Read cache exceeded its capacity 4/2.1MB. Drag and drop sharing is also lost. The progress bar does not go anywhere and it is not possible to close it... Writing to cache continues.

EDIT4: A separate case: uT hung when performing Re-Check on files with previously some pieces completed then deleted completely (only tmp file left).

Link to comment
Share on other sites

I was downloading torrent with 8kb/s even with 115 seeders. Disk overloaded 100% was up. When I changed "Overwrite automatic cache size and specify the size manually (MB) to 1024. I started downloading with 2.3MB/s and Disk overload was gone.

18959

ps. also utorrent crashes sometimes on shutdown. haven't tested if it still crashes with 1024mb cache yet.

ps2. i guess i was too fast. after few minutes disk overloaded 100% returned. and speeds of 8kb/s too :(

Link to comment
Share on other sites

Seems to periodically stop writing to disk and just store it in cache. Regardless of what cache settings you change. Sometimes it does this shortly after startup other times it does it randomly. Yeah overriding the cache can help by it not bottlenecking itself as it doesn't want to write to disk quickly. Despite the drive being able to handle almost 400MB/s write speed (RAID array) when I lowered the cache back down and the data to be written was higher than the cache size...instead of quickly writing the excess data to disc it wrote some of it quickly but when it got to 100MB of data left in cache it was only writing 2-3MB/s to disk and then download rate dropped to nothing. Even with the cache high it will still periodically stop writing data to disk. Disabling caching completely seems to have even worse results of it not writing any data to disk.

This wasn't a "crash dump" but it was a dump after the program closed and was not responding but the process was still there. Helps to include link http://www.megaupload.com/?d=I0IYKISP

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...