Jump to content

Ben91

Established Members
  • Posts

    10
  • Joined

  • Last visited

Ben91's Achievements

Member

Member (2/3)

0

Reputation

  1. "Good" to see that a lot of people have some disk overloaded issues... For me, about "Disk overloaded 100%", it's too random to do some consistent tests ! :/ Are the devs in vacation ? (Not seen one of them since one week). Cheers. PS: Did anyone test these disk cache settings (or can test or use these settings) ? : What can you say about these "advices" ? : http://www.tribalmixes.com/forums.php?action=viewtopic&topicid=6531&page=p40649#f40649 Same here with updated version :
  2. haaaaa !!! Some news !! With pref->advanced->diskio.use_partfile to false : As reported in post #202 http://forum.utorrent.com/viewtopic.php?pid=626338#p626338 With pref->advanced->diskio.use_partfile to true : Same procedure as #202, reminder : In 10-15 minutes, as Process monitor shows : - only one 7 GB *.mkv has been created (I guess "step 1" from #202) - Then during 10 minutes (!) : a *PartFile*.dat from another torrent has been created / filled with a size of 6 MB only ! - Now it created two other *.mkv files (few seconds) - New .dat file, same speed as before < 3MB in ~5MB - uT continues to write on the .dat and create the empty final files In the uT GUI, same behaviour (true and false) : - No download (speed near < 10 kB/s) - "Disk overloaded 100%" Conclusion ? Except that to write final files the speed is about 3000 MB / min and when it comes to write in the .dat files (if PartFile is set as true) the speed is about 0.6 MB / min (5000x slower... WTF and why ?) .... it's why I asked before... By default it's unchecked and I have it unchecked... but it always create empty files.... it's not clear...
  3. And my hunch is that they did not close all the corners with this fix... TO prove that - just configure: pref->advanced->diskio.use_partfile to false, close utorrent, delete *utorrentPartfile*.dat files, start a *new* torrent, and see if the problem is gone... I should have guessed that a while ago... But sorry, I'm lost, is it normal when adding "big" torrents (ex 5x 20 GB = 100 GB), it takes about 30-40 min to start downloading because of Disk overloaded, then with standard Disk overloaded (often several times a minute, if it's a 100% overloaded, can last more than 10 seconds, causing a cut of the download speed) ??? With pref->advanced->diskio.use_partfile to false : And what happens with uTorrent ? Is it normal this situation : 1) When add a new torrent, immediately create files with final size. (few seconds) 2) Add some data (what are they ? zero-filled ?) in the files (about ~3 GB / min processed so it requires about 30 min for 100 GB), normal step ? 3) Start download when all torrents have completed steps 1 and 2. Normal "Disk overloaded" issues. Thanks.
  4. I did a little test. Added < 10 torrents (some 1080p collections) between 25GB - 200 GB), selected only few files (for a total about 50 - 100 GB), uT started to write on the disk, disk overloaded, I exited uT after 2-3 min (so nothing downloaded, less than 1 MB !). As it was writing files to the disk the process was still here writing on the disk... But even after 20 min (for now when I'm writing...) So I looked with "Process Monitor" and "Resource Monitor " Here you are the result (if it speaks to someone...say me what it means lol) : Open in a new tab to see the whole picture please. Thanks. So personnal question, why uT use a .dat file (partially downloaded data I think) but what's the difference between this file and the real "zero-filled" files ??? Another question is, why uT stop downloading when the disk is overloaded ? Why not continue and keep data in RAM or whatever, it sucks that every overloaded issue you loose all "the speed" and stop downloading... As you can see there is a huge problem in the file I/O implementation in uTorrent 3.x (3.1 here). About < 1 MB / min. I understand why some new downloads" doesnt' start"... Between cache problem ? and slow writting perf... EDIT: Proccess has exited,about 20 min for 15 MB ! (.dat file). EDIT 2 : Each time I see an extended "Disk overloaded 100%", I see in the write stats, Cache (example 35 MB of 32 MB (first number always bigger). GUI issue ? EDIT 3 : I uploaded a DUMP file (uTorrent.DMP). 143.89 MB. When it was hanging with an extended "Disk Overloaded 100%" issue. Here you are : http://www.multiupload.com/XC7U4ZPSD9 Cheers.
  5. External / USB ? Internal ? Might be a bug here related to handling of torrents with very large sized content (~80G). Yeah, I think it's definitely not specificaly related to.torrents (only the size matter). I'm pretty sure it ALWAYS happens but more data are bigger more the problem is bigger... Try with PBay, "1080p" (like collection / set / box).... Difficult to say... not always the same facts happens... Somtime it's OK... sometime not.... About my HDD, it's a pretty "good" one. No problem here. (Internal, SATA, handle easly > 100 MB/s + good access time...for an HDD).
  6. During 1-2 hours was blocked with disk overloaded / few kBps (not really downloading) and suddenly started to download but as always when it downloads few disk overloaded (evry 2-3 min and happens only 4-5 sec but with high CPU usage) DiskIO settings : (default options) : There are "Basic Cache Settings" and "Advanced Cache Settings" in Disk Cache and Super Advanced Cache Settings in Advanced / diskio.x... confusing. Now, have 100 mbps connection so problem is more problematic. Just saw this "disakio.low_prio_disk" going to check thus with set as false. I tried to switch back for 2.2.1 (Stability and Minimalism) VS 3.x (New features, GUI and network optimizations) But for me, 2.2.1 has disk overloaded problems too ! Periodic hanging and lost of network speed during "disk overloaded" (very often) was always an issue but now, this new problem that prevents me bluntly that the download starts ...Worse and worse ... arrrggh. I bet for a Cache problem or Writing issue (bad implementation) with uT or Windows because Network works fine, HDD is in free / waiting of use. @ rafi and masca90020 : Going to try your settings guys. Thanks. @masca90020 : About "Pre-allocate all files", saw in the help file : "Pre-allocate all files tells µTorrent to create and fully allocate every file you select to download immediately after starting the torrent job. Note that this option does not have an impact on hard drive fragmentation (advantageous or otherwise), as µTorrent already allocates each file upon writing to disk even without this option." Don't see why there is this option (disabled by default ?!?) of this option / checkbox, as it said, isn't activated by default in uT (I mean, when adding torrents, zero-filled files are automaticalyl created, isn't it ?) Thanks guys for the help. PS: Downloading since more than 3 hour at full speed, few hangs from few sec but it's all ! Really strange...
  7. Hello. It's really random. Yesterday, impossible to download something... Today, in the morning, all my (same) torrents finished in one shot. So I tried new couple of torrents (same sizes, same disposal...) and since 20 min, nothing happens (apart "Disk overloaded 100%" problem). My 46 GB of "empty" downloading files are written on the disk... (WTF about Cache ???) : (Open in new tab for complete view, please) : Enough free space on your HD? Any hash fails (see in your logger tab)? Can you show the info tab and you cache settings advanced->cache/diskio.*? Can you pm your .torrent link? Yes' date=' > 400 GB free. (Downloading tests about < 50 GB) My example was with less than 10 torrents, each between 1.5 and 10 GB. Torrents with between 1 and 5 files, Files are single-files between 1.5 and 4 GB. So a total about of ~40 files No hash fails errors, even no errors at all in the logger tab. Look at info of one torrent : (Don't look total size of the torrent, only downloading a little part) : (Open in new tab for complete view, please) [img']http://image.bayimg.com/calfkaadh.jpg Disk Cache settings are the default ones. Never changed : Sorry for .torrent(s) but it's private :/. Maybe I'll try on public trackers but don't think that this "Disk overloaded" problem is .torrent related, do you ? Thanks for you help. Cheers.
  8. Hello. uTorrent 3.1 Build 26616 32-bit on Win 7. Always have "Disk overloaded 100 %" (on Dedicated Caviar Black 640 GB....lol) Before these last build it was temporary (few seconds) now it hangs forever !!! Permanent message : (Open picture in new tab for complete view on the right) EX : No download since 10 min, had to stop / start => Solves the problem (restart downloading)... for even not 2 minutes then again disk overloaded, nothing happens... no writing on HDD no Downloading.... Pfff.... 3.x sucks.... Should be in BETA !
  9. Hello. (Happened once when uT crashed, seems to be ok for the other times) This button does anything... An option to hide Feeds would be cool, in the left panel. Extremely laggy : CPU usage is heavier and heavier (relase after release, even worst). Between 10-40% (more between 10-20% with uT 3.0). Whitout speaking about disk I/O problems since 3.x ! uT should be renamed without u, one of these days or stop developping it and focus on Bittorrent... :mad: Why uT team doesn't use a ticket system instead of a forum ? Why changelogs appears always weeks after the releases ? Why 64-bit releases aren't on the same development stage as 32-bit ones ? Cheers. PS: Hope to see some improvements about Disk I/O...
  10. Hello. Build 25806 doesn't update to Build 25824, even manually. (There is no new version available at this time.). Had to do it by downloading installer.
×
×
  • Create New...