olympia
-
Posts
458 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by olympia
-
-
I've just started to look into reencode a lot bunch of documentary DVDs I have.
@ClunkClunk, thank you for the precompiled packages.
My origintal intent was to reencode all the DVDs to mkv with x.264 parameter and whatever quality, but I would like to preserve all the audio tracks in their original format (ie. keep them as they are).
It seems that as there is no such parameter, it is not a simple task. I figured that the only way to do this is to do a scan first and then save and parse the output to set the correct number of tracks and formats during the encode.
Have somebody experimented something like this yet?
Thank you for the feedbacks.
-
OK, thank you for all the hints!
-
Ooops, yes, sure it's belongs to here. Sorry for messing this up.
Can clearing with -n option considered to be safe against undelete/unerase/unformat tools?
-
Hi Joe L.,
I am wondering if it would be easy for you to include an option for completely wiping the disk instead of preclearing it.
Or the preclearing method in it's current form can be used for this purposes? (but at least the readback seems unneccessary in this case)
That would be extremly useful on a disk replacement, when the old disk is going to be sold out.
Thank you in advance for your feedback.
-
if you are running cache_dirs, then that is it.No, there is not any scheduled task on my setup. And as I mentioned, parity is spun down.
Which is interesting, that there are only small amount of reads from each disks. Maybe cache_dirs? But if I check the open files in unMENU, then there is no active find command...
The preclear script reads/writes the entire disk being pre-cleared in a way that is pretty much guaranteed to make the directory entries attempted to be cached by cache_dirs to eventually end up as the least recently accessed blocks and subsequently returned to the pool of blocks available to use as disk cache.
The cache_dirs script can only work if the rate at which it can access the directory entry "blocks" is more frequent than the rate at which you use other disk blocks in your array.
The preclear script is accessing the disk being cleared far faster than normal use when playing a movie, or scanning directories. I can see how it can easily end up with the blocks on its disk as being cached and more recently accessed than any from the directory scans. (remember, oldest/least-recently-used in the buffer cache are those that are re-used for current access needs)
The solution... cancel the cache_dirs... or live with the fact that it is doing its job, trying to keep your directory listings of the shares on your server as responsive as possible.
If you kill cache_dirs, in an hour or so, the other disks will spin down, and you will have to wait for directory listings until they spin up.
Joe L.
Thank you for the comprehensive explanation Joe L. That's fully logical, except I thought cache_dirs only doing its job on the array and the cache drive. That's why I thought, that a drive, which sits outside the array cannot affect it. But now I know I was wrong.
Thank you again for both great scripts!
cache_dirs is only scanning the disks in the array and one the cache drive...your thinking was correct. However, the disk buffer cache is shared by all disks, regardless of their assignment to the array or not. That same buffer cache is used by anything accessing the disks.
If the preclear script uses disk buffer blocks faster than the cache_dirs script can re-scan a given directory, the cache_dirs script must re-read the directory to get satisfied.
There is only one set of buffer memory for disk I/O, it is shared by everything.
Joe L.
Now I fully understand. Thank you very much Joe L.!
-
if you are running cache_dirs, then that is it.No, there is not any scheduled task on my setup. And as I mentioned, parity is spun down.
Which is interesting, that there are only small amount of reads from each disks. Maybe cache_dirs? But if I check the open files in unMENU, then there is no active find command...
The preclear script reads/writes the entire disk being pre-cleared in a way that is pretty much guaranteed to make the directory entries attempted to be cached by cache_dirs to eventually end up as the least recently accessed blocks and subsequently returned to the pool of blocks available to use as disk cache.
The cache_dirs script can only work if the rate at which it can access the directory entry "blocks" is more frequent than the rate at which you use other disk blocks in your array.
The preclear script is accessing the disk being cleared far faster than normal use when playing a movie, or scanning directories. I can see how it can easily end up with the blocks on its disk as being cached and more recently accessed than any from the directory scans. (remember, oldest/least-recently-used in the buffer cache are those that are re-used for current access needs)
The solution... cancel the cache_dirs... or live with the fact that it is doing its job, trying to keep your directory listings of the shares on your server as responsive as possible.
If you kill cache_dirs, in an hour or so, the other disks will spin down, and you will have to wait for directory listings until they spin up.
Joe L.
Thank you for the comprehensive explanation Joe L. That's fully logical, except I thought cache_dirs only doing its job on the array and the cache drive. That's why I thought, that a drive, which sits outside the array cannot affect it. But now I know I was wrong.
Thank you again for both great scripts!
-
No, there is not any scheduled task on my setup. And as I mentioned, parity is spun down.
Which is interesting, that there are only small amount of reads from each disks. Maybe cache_dirs? But if I check the open files in unMENU, then there is no active find command...
-
Your other disks are spinning because they are being accessed by something... But it is not the preclear script.The script is running currently on my setup, pre-clearing a WD 1TB disk.
MY question: is that normal, that other disks are not spinning down in the meantime? All the disks are spinning except parity. And it script still only in pre-read phase.
It does perform a test when first invoked to ensure the disk being cleared is not part of your array (not assigned to the array, and not mounted), but that is it.
If you really want to see what is accessed on your other disks, download and install inotifywait.
http://lime-technology.com/forum/index.php?topic=3759.msg33489#msg33489
Joe L.
Hmmm.. Very strange. All I know is running at the moment is one desktop pc with one putty session(to run the preclear script on the unraid machine). But something is _continously_ reading from ALL disks, it can be monitored from unRAID read statistics.
I've installed inotifywait, and ran by "inotifywait -m -r -e access /mnt/disk*". Nothing detected so far up until now.
-
The script is running currently on my setup, pre-clearing a WD 1TB disk.
MY question: is that normal, that other disks are not spinning down in the meantime? All the disks are spinning except parity. And it script still only in pre-read phase.
-
The anti-vibration bay
-
Front.
-
A bigger look.
-
What does the front look like? How small is it?
Well, unfortunatelly I don't have an own pic from the front, but it is this case:
http://www.gigabyte.com.tw/Products/Chassis/Products_Spec.aspx?ProductID=2482
The drive bay was completely dremmeled out, together with the aluminium front of the case, because of the airflow.
After that, a custom drivebay has been made and installed, which can hold 6 disks. I am not sure if they can be recognized, but there is 2 12cm fan attached from the front side.
-
This is how mine is looks now.
Small factor and anti vibration is in main focus.
HowTo: Install HandBrakeCLI on your unRAID server (rather than in a VM)
in User Customizations
Posted
Thank you for the feedback.
Yes, this could potentially work (I think), but the bigger problem is with the number of audio tracks.
I want to preserve all, ie. if there is 2 or 3, then all 2 or 3, but of course a general command would needed in a batch process. Unfortunatelly if I set -a 1,2,3 then HB cli is exiting if the input file doesn't exactly has 3 tracks. Means you always have to give the correct number of tracks for this parameter which of course you don't know in a batch process.
The scan first, then parse scan results approach was suggested on HB's irc channel, but my scripting knowledge is close to 0, so I am not able to accomplish this...