sergey.chou

Streaming doesn't work for some files sometimes. Let's hope it will evolve in the future. I think this is browser's error message, and it is Russian for you. uT tries to open HTML file in "Get started page" and it has some issue.

Try VLC media player. It is the only player, which allowed me to stream mkv files. Probably because it doesn't read indices, which are in the end of file. By the way, you can switch uT to English while testing, because not everyone knows Russian. I get this message box, when I press About -> Show "Get Started" Page. I close this message box and see next page: http://img96.imageshack.us/img96/2700/getstarted2.png There is some gray rectangle to the left. Tell me, please, how to close this page and return to table with torrents without restarting uT? Left panel is disabled in advanced settings: gui.enable_sidebar_buttons=true.

Let me comment Andre Young's message. I see 3 issues: 1. Read cache is 5MB. Write cache is 32MB. Isn't it supposed to be the same cache and show 32 MB in both places? 2. Hashing is not 0. If there was not recheck, then it may be issue. 3. There is an issue with dropzone. I also have it. This is how to reproduce: put uT in window mode (not maximized). Then decrease uT window height to minimum, so only title is visible. Finally increase window height SLOWLY. Dropzone will have ghost image similar to provided on the shot. If to increase height too fast, there won't be such effect.

Sorry, I was inattentive. You also have issue with huge hashing as pulbitz. I don't know what causes it. It is always 0 for me. It is hashing when I force torrent recheck. Can any uT developer tell, in what situations "Hashing" is used in Read disk statistics besides rechecking?

To Best Disable read cache for now. uT will read exactly that amount of information, which it should send to peers, and you won't have disk overload.

Right click table header (where you see "name"' date=' "size") and select any column you like.[/quote'] I know this but i not have seeds and peers they disappeared. "Peers" and "Seeds" are absent in context menu for header? It is interesting to see a screenshot of such menu. I have this http://imageshack.us/photo/my-images/687/peersseeds.png/

Right click table header (where you see "name", "size") and select any column you like.

So pulbitz has issue with huge "Hashing", while nothing is being rechecked, and Best has huge "From File Avg Size" when diskio.cache_stripe=128. Both use uT 3.0 build 25406. Update No, I am wrong. Both have problem with hashing.

Somehow uT is reading intensively from HDD for hashing. If no torrent is being rechecked, then it is strange for me. I hope developers can answer, what is also collaborated for Hashing in read statistics besides rechecking.

Do you recheck torrents after installing uT 3.0? I see you have 2.42 GB hashing and I think it is because of recheck.

Really, you have disk overload (3.94 MB per every request instead of default 128 KB). Are you sure, that you use uT 3.0 build 25406? If yes, what value do you have in advanced options diskio.cache_stripe? gui.show_dropzone=false, although gui.enable_sidebar_buttons=false will hide drop zone too. It can be because channel between you and peer is unstable.

Please, provide a screenshot of disk statistics, while uT is actively seeding (and overloading your disk) for at least 1 minute test.

Disk overload was fixed in RC6 and you can manually control disk usage thought diskio.cache_stripe if cache is enabled. Surely it is gone, because you don't seed, and uT doesn't read any data from HDD.

I see no problem with this. Let me try to clear up things for you. Total amount of bytes read from disk is sum of From File and Hashing in Read Statistics. In your case 367/1024 + 1.58 = 1.93 GB, which is comparable with what Process Explorer provides - 2.2 GB (0.27 GB is read information for other programs). Hashing happens when you force some torrent to recheck. Surely this operation intensively reads information from disk and it happens only for checking already download information with hash table inside .torrent file and you start it manually. In normal cases uT reads from disk only if it wants to get information for peer and such number is provided in From File row. It is 367 MB in your case. Everything, what is read from file is put into cache (if it is enabled, of course), and then some chunk from cache is given to peer. From cache should show how much information uT actually passed to peers. It is 345 MB in your case. You may ask why From cache amount is not the same as From File. It is because uT reads more data from file than peer requested in order to decrease number of disk I/O operations, because there is a probability, that peer will request for that part, which was read from file. In your case uT reads 128 KB for every request and sends 16 KB to peer. There is a probability, that peer will request another 16 KB from these 128 KB. In your case such probability is super great, because From File is almost the same as From cache. I assume, that you upload 1 torrent, which takes small space, because I have never seen such high probability in for my torrents. In my tests uT usually sends 27 KB to peer for every read 128 KB. In your test it is 120 from 128. Lucky you are! If you have read this carefully, now you understand, that uT reads more information from disk, than it sends to peers and it is done only for one purpose - decrease number of I/O operations sacrificing number of read information. The more uT reads from file for every request, the more information it will read from disk in the end. There is a new advanced option in uT: diskio.cache_stripe. It is 128 by default. If you set it to 16, then uT will read exactly the same amount information from disk (or less, if peers request some chunks from cache) as it will send to peers. So you won't have any disk overload. I prefer 64 for this value. I hope this information was useful for you. If not, you can kick me, I don't mind.

Your indignation is understandable. Well, some bugs have higher priority, than others. Those bugs, which crash uT, make HDD overload, highly increase CPU usage or damage settings usually have higher priority than GUI issues like yours. Of course, every bug report is appreciated and will be fixed one day, just developers are not magicians and each has only one brain and hopefully 2 hands, so every bug fix requires own time. From other side, you may use old stable version and wait when uT 3.0 becomes gold. Nobody pushes you to use beta. I think 3.0 will become gold, when developers are satisfied with current state and feel, that there are no major bugs. Probably your bug will be fixed too till release. And I think developers don't deny that this bug exist: rafi admitted it in http://forum.utorrent.com/viewtopic.php?pid=592418#p592418 and told how to reproduce it.

Hey hey, be easier, please. AdamK just mentioned that you missed details in your original message. Probably he didn't notice your later message, because he was writing a message to your original message and naiduv's response to it. At that time, your later message was not yet posted, because it takes time to write a message. First he posted message #680. Then he started writing his message #682 to response to #677. You posted your 2nd message #681, but he was still busy with #682, so he didn't see your message. Right after he finished it, he wrote his new message #683 missing your #681. Then he just left forum and hasn't yet seen your #681. Your bug report is appreciated.

Version upgrade history was next: 2.2.1 (using for some months), 3.0 RC4 (used for some days, installed via autoupdater for beta versions), 3.0 RC5 (installed via autoupdater), 3.0 RC6 build 25395 (installed manually, because it was unavailable in autoupdater) and such issue appeared in this version (RC6 build 25395) ~4 hours after update. Some torrents were green and were seeding, just with slow speed and some torrents were red with mentioned error status, which really looks like OS issue. Later I updated to RC7 and RC8 via autoupdater, but before I used RC6 for about another 10 hours and there was no such issue again. If such info has any sense for you I do not use uTP (bt.transp_disposition=5), allow same IP (bt.allow_same_ip=true), changed just appeared new option (diskio.cache_stripe=64, yea, it appeared in RC6 and I was actively testing this option changing it to 16 - 128 values watching disk cache statistics before finally leaving it to 64 and mentioned issue was with such value), net.max_halfopen=30 (with patched tcpip.sys for halfopened set to 500). Other non-default values for advanced options are related to GUI, and are not important from my view.

Unfortunately I didn't check it that time. After that problem was noticed, I investigated what I could, then manually quit uT and ran it again. It worked correctly for some time (I guess 20 minutes) and then quit itself without crashing report. There also was dead uT icon in the tray, which disappeared when I hovered over it. Then I decided that it might be OS issue after all (system uptime was around 6 days) and I restarted OS. I haven't noticed this issue since then. It is a bit pity, that uT doesn't remember log file, which is selected in "Log to file..." after restarting uT. It is not fun to set it manually every time I start uT. If it would remember log file, then I could provide you log for that situation, when uT decided to quit itself.

uT build 25395 x32, Win XP SP3. I have noticed many red torrents with error in status column: "An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full." uT logs shows next: [2011-06-20 03:48:00] Error: data.mkv - Not enough quota is available to process this command. [2011-06-20 03:49:05] File failed verification: C:\Program Files\uTorrent\resume.dat.new [2011-06-20 03:49:05] Unable to save the resume file. Another program might have the file open, or the disk is full. [2011-06-20 03:49:24] Error opening "k:\tor\data2\data2.mkv": [2011-06-20 03:49:24] Error: data2 - Not enough quota is available to process this command. [2011-06-20 03:51:06] Failed file save: C:\Program Files\uTorrent\resume.dat.new [2011-06-20 03:51:06] Unable to save the resume file. Another program might have the file open, or the disk is full. [2011-06-20 03:53:07] File failed verification: C:\Program Files\uTorrent\resume.dat.new [2011-06-20 03:53:07] Unable to save the resume file. Another program might have the file open, or the disk is full. [2011-06-20 03:55:08] Failed file save: C:\Program Files\uTorrent\resume.dat.new [2011-06-20 03:55:08] Unable to save the resume file. Another program might have the file open, or the disk is full. [2011-06-20 03:57:09] Failed file save: C:\Program Files\uTorrent\resume.dat.new [2011-06-20 03:57:09] Unable to save the resume file. Another program might have the file open, or the disk is full. [2011-06-20 03:59:10] File failed verification: C:\Program Files\uTorrent\resume.dat.new [2011-06-20 03:59:10] Unable to save the resume file. Another program might have the file open, or the disk is full. [2011-06-20 04:01:11] Failed file save: C:\Program Files\uTorrent\resume.dat.new [2011-06-20 04:01:11] Unable to save the resume file. Another program might have the file open, or the disk is full. [2011-06-20 04:03:12] Failed file save: C:\Program Files\uTorrent\resume.dat.new [2011-06-20 04:03:12] Unable to save the resume file. Another program might have the file open, or the disk is full. [2011-06-20 04:05:13] Unable to save the resume file. Another program might have the file open, or the disk is full. [2011-06-20 04:06:11] Failed file save: C:\Program Files\uTorrent\settings.dat.new [2011-06-20 04:07:14] File failed verification: C:\Program Files\uTorrent\resume.dat.new [2011-06-20 04:07:14] Unable to save the resume file. Another program might have the file open, or the disk is full. [2011-06-20 04:09:15] Failed file save: C:\Program Files\uTorrent\resume.dat.new Disks C and K are not full. Each has more than 16 GB of free space. resume.dat.new and settings.dat.new are absent in uT folder. resume.dat and settings.dat exist and they are being updated normally - their modification data is being changed all the time. Using Unlocker on these files shows, that these files are not locked by any program. Also those log records repeat constantly. uT is uploading good torrents (without that error) with speed around 5% from maximum. uT doesn't use uTP. Its cache is 32 MB. Using task manager I see that its virtual memory usage is around 91 MB and I have plenty of free memory. Average number of active connections is ~40. Googling I can assume that operation system is running out of non-paged pool. Windows event viewer doesn't tell any error. I do not use PAE nor /3GB switch in boot.ini. Restarting uT and starting error torrents makes uT work normally (no error message about dat files in log). I didn't restart OS. It makes me think that bug is inside uT. It is first time I see this issue.

Thank you very much for this option! I am so happy. Now I can enable read cache and set this parameter to 64 and it works! By the way, you can correct changelog text: it should be "cache_stripe", not "cahce_stripe" (in uT it is correct).

I believe this is related to issue described here: http://forum.utorrent.com/viewtopic.php?pid=590392#p590392 Problem is that version 3.0 reads huge number of bytes for every tiny request. I have upload speed 1.5 Mbit/s. There is around 10 chunk requests per second and utorrent reads 4 MB for every request in my case. It means that utorrent reads 40 MB/s from my disk. My average HDD read speed is 66 MB/s. In theory uploading speed will be stalled at 1.5 * 66 / 40 = 2.5 MBit/s if I would have sufficient upload speed. So I can't send more than 2.5 MBit/s even if I have 100 MBit/s channel. Try to disable read cache in settings and check if it helps.

There is one issue with read caching for 3.0 RC4 build 25345. Disk statistics with enabled read cache: Disk Cache Settings for above situation with enabled read cache: Disk statistics with disabled read cache: Disk Cache Settings for above situation with disabled read cache: When read cache is enabled utorrent reads full torrent piece for every request. In example above it is 4 MB. Even if only 16 KB was requested, 4 MB will be read from disk. I understand this logic, because there is a chance, that there might be a request for another chunk in read piece, so generally such approach reduces number of disk reads sacrificing increased disk bandwidth. When read cache is disabled, then utorrent always reads 16 KB for every request. It decreases number of read bytes from disk, but increases number of reads. Ok. This is understandable. But let's look how it works in reality. Test was for around 1.5 minutes. Utorrent read 4.34 GB from disk and sent 19.5 MB to client. Read/request ratio for number of bytes is 4.34 * 1024 / 19.5 ~ 228. Read/request ratio for number of requests is 1112/1253 ~ 0.89. So, it means, that uttorent saves only 11% of disk access number at the expense of reading 228 more information from disk (22800%)! Amazingly great waste of resources! Also you see, that option "Increase automatic cache size when cache is trashing is active" is enabled, but cache size doesn't even want to increase itself and stuck to 32 MB. It fills itself in less than a second with such disk demands. As you see cache reading is absolutely useless in above example. I gave you example with large torrent piece - 4 MB. Situation will look some better with smaller torrent pieces. Now let's look at utorrent 2.2.1. It reads 128 KB from file, when cache is enabled no matter of torrent piece size. In my tests, I have read/request ratio for number of bytes around 4.6 and read/request ratio for number of requests is 0.58. Much better than for 3.0. I didn't find any advanced option for reducing number of read bytes per request. It would be perfect to control it manually. I would prefer 64 KB. Default 128 KB is ok too. But piece size (up to 4 MB) is totally unacceptable.