Jump to content

3.4.x Beta


AdamK

Recommended Posts

  • Replies 2.3k
  • Created
  • Last Reply

I test it again.

 

In 2.2.1.25534 (which I commonly use) "diskio.sparse_files=false" is set by default and I must it set to "diskio.sparse_files=true".

In 3.4.3 39773 (as I checked now) this setting is already "true" by default.

 

Post #1669 was tested with DEFAULT SETTINGS with "diskio.sparse_files=true".

 

Why you think there is something wrong with my settings? It worked until they've change recently the cache scheme...

 

Because with DEFAULT SETTINGS there is NO PROBLEM.

With YOUR SETTINGS I have got the same issue.
Just backup your settings and try default...

Link to comment
Share on other sites

Same here... That can explain why I've started to see the issue now. I had it set to default (false) and it self-changed to true  in one of the recent builds. So, My perfect settings was modified by the devs, w/o any mention of this in any of the changelogs (nothing new here...) .

Saying that, there is no reason for the client to behave that way with any settings combination. It is a bug!

 

 

3f939c400410395.jpg

Link to comment
Share on other sites

rafi,

 

So, I tried downloading another DRP ISO, this time stopping all other torrents. Client behavior was normal until I interrupted it at 21.6%. Here a screenshot at 8.4%

 

       57ccd8400442514.jpg

 

In my diskio preference I can see that minimize kernel caching is enabled. I haven't tested to see if it makes a difference though.

       ac2f09400442515.jpg

Link to comment
Share on other sites

rafi,

 

In my diskio preference I can see that minimize kernel caching is enabled. I haven't tested to see if it makes a difference though.

 

What is your advanced setting for sparse_files (default changed to true now)? what is your setting for general->pre-allocate files?

 

This is what I found  out:

Pre-allocate  Sparse

--------------------------

Enabled          True                 -> issue seen when starting the download

Disabled          True/False      -> issue is not seen

 

BTW, according to the help - Pre-allocate should override/cancel Sparse-files

Link to comment
Share on other sites

What is your advanced setting for sparse_files (default changed to true now)? what is your setting for general->pre-allocate files?

 

This is what I found  out:

Pre-allocate  Sparse

--------------------------

Enabled          True                 -> issue seen when starting the download

Disabled          True/False      -> issue is not seen

 

BTW, according to the help - Pre-allocate should override/cancel Sparse-files

 

General / Pre-allocate all files is unchecked. So, this confirms your findings. I was having problems with my disk cache last year with this stting enabled.

Link to comment
Share on other sites

In my diskio preference I can see that minimize kernel caching is enabled. I haven't tested to see if it makes a difference though.

       ac2f09400442515.jpg

Oh! This is interesting...

 

The name of this setting is making me wonder a few questions:

 

1) Can I asume "diskio.minimize_kernel_caching" is like disabling Windows caching from older µtorrent versions that disapeared on newer versions like I was talking about here (click the link), so in another word it was replaced by this setting?

2) If not, what does it do exactely?

3) Can it be used to prevent the ram leaking problem from Windows caching that some peoples been complaining about?

4) If no to question #3, can it be used to reduce it?

 

Can anyone confirm this please?

Link to comment
Share on other sites

1) Can I asume "diskio.minimize_kernel_caching" is like disabling Windows caching from older µtorrent versions that disapeared on newer versions like I was talking about here (click the link), so in another word it was replaced by this setting?

2) If not, what does it do exactely?

3) Can it be used to prevent the ram leaking problem from Windows caching that some peoples been complaining about?

4) If no to question #3, can it be used to reduce it?

 

Can anyone confirm this please?

According to the uTorrent help file, the diskio.minimize_kernel_caching option "disables compact allocation, might be POSIX only", so it won't do anything to fix the Windows caching problems.

 

Older versions of uTorrent (2.2), with the "Disable Windows caching of disk writes" option checked, use a flag called FILE_FLAG_NO_BUFFERING when creating/opening a file that it's going to write to. I'm guessing this was causing some sort of problems since the option was removed in later versions, cause it does seem like it'd be a good idea to simply tell Windows not to cache anything, instead of blaming "Windows cache stupidity". Perhaps the "Windows cache bugs" that we've heard about so often on these forums are related to that flag somehow. The Windows dev pages do say that "An application must meet certain requirements when working with files opened with FILE_FLAG_NO_BUFFERING", so it's probably not easy to get it right.

 

In any case, file read and write caches are usually good things, but if software starts to fill up those caches with useless content that really doesn't belong in a cache, there will be significant performance problems for other applications that actually benefit from them, so I'd almost say it's irresponsible of uTorrent not to disable it if it's possible to do so.

 

A problem with BitTorrent downloads is that the piece download order is supposed to be more or less random. If you download a piece from the end of a large file and don't use use sparse files, you're going to have to tell the operating system to fill the empty space before that piece with zeroes, which takes a long time and delays any new write instructions to that same file. That's why the uTorrent cache sometimes fills up at the start of large downloads (again, unless sparse files is used), and that's also why you sometimes get the "Disk overloaded" messages. The problem would even be exaggerated by the "bt.prio_first_last_piece" setting, as you'd end up pre-allocating all files with zeroes.

 

Curiously, uTorrent doesn't seem to care about the bt.prio_first_last_piece setting when it's downloading media files, so I suppose it really wants to get the headers and metadata for all files as soon as possible. And because of cross-file pieces, you end up pre-allocating all files in a torrent except the very last one. Not even the bt.sequential_download option changes this. Consequently, if you're not using sparse files, the effect is more or less the same as checking the General / Pre-allocate all files option.

Link to comment
Share on other sites

According to the uTorrent help file, the diskio.minimize_kernel_caching option "disables compact allocation, might be POSIX only", so it won't do anything to fix the Windows caching problems.

 

Older versions of uTorrent (2.2), with the "Disable Windows caching of disk writes" option checked, use a flag called FILE_FLAG_NO_BUFFERING when creating/opening a file that it's going to write to. I'm guessing this was causing some sort of problems since the option was removed in later versions, cause it does seem like it'd be a good idea to simply tell Windows not to cache anything, instead of blaming "Windows cache stupidity". Perhaps the "Windows cache bugs" that we've heard about so often on these forums are related to that flag somehow. The Windows dev pages do say that "An application must meet certain requirements when working with files opened with FILE_FLAG_NO_BUFFERING", so it's probably not easy to get it right.

Thanks for clearing that out for me, I also feel the same about the blaming of "Windows cache stupidity".  I don't know why they removed it but I guess they had some good reasons in the background, perhaps they are seeking a new/better way to implement it in the future.

 

Since that most private trackers tends to ban/not recommand to use µtorrent 3.x because of all the bugs and problems, I basicaly moved to a different bit torrent client.  I don't like the idea to use old versions of a program so I prefer using a different bit torrent client.  At first that new client I am using had this same ram leaking problem and I couldn't find an option to disable windows caching anywhere.  So I googled every now and then until I find that they added an option to disable OS caching in the newer versions and now its not leaking anymore.  I really hope they re-implement this to µtorrent in the future because if windows caching is that much of a problem it needs to be disabled.

Link to comment
Share on other sites

It is allright. Look at this again!

Newer version is 3.4.3 beta build 39773.

Older is 3.4.2 stable build 39776.

The build number is irrelevant.

 

True, however the Changelog page lists the last two builds as part of the 3.4.3 branch, so the dialog is a tad funky. ;)

Link to comment
Share on other sites

True, however the Changelog page lists the last two builds as part of the 3.4.3 branch, so the dialog is a tad funky. ;)

 

Not true...

µTorrent 3.4.2 beta (39776)... It is beta of previous version, not stable 3.4.2, not current beta 3.4.3... x_facepalm.gif

I'm afraid to look into changelog... :blink:

 

QmLUpXg.png

Link to comment
Share on other sites

3.4.3.39891 now available:

 

-- 2015-04-03: Version 3.4.3 Beta (build 39891)
- All fixes from the latest stable (39744)
- Updated media parsing, with more reliability
- Fixed inefficiency and CPU usage when navigating torrents
- First beta of new streaming trial flow (limited rollout, may not be activated for your install)

 

Note: The link is currently downloading 3.4.3.39910

 

Also, compared the the previous 3.4.3.x beta, the DHT bit is now off centre and some of the text (part of the 'e' and all the 's') is cut off too.

So that needs looking into (I'd like to see the spacers between the information in the image below draggable).

 

2015.04.03_21h11m34s_001_zpszpfsav25.jpg

Link to comment
Share on other sites

Archived

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


×
×
  • Create New...