Craig Thomas quinlan
Forum Replies Created
-
-
Yeah you can do this in Terminal easily. The command is “diff”: this will give you a list of differences between two volumes or directories. It looks like this
diff -rq FolderA FolderB
the ‘r’ flag to recursively compare all subdirs, and the ‘q’ for brief output, only showing the differences. If you’re not comfortable in CL that’s fine, just open Terminal and type
diff -rq
then put a space in, drag (from Finder) the first directory, then drag in the second directory, hit enter. Terminal will populate the directory location if you drag folders in.
This is the fastest way to get a list of files that never made it from A to B. Do a ‘man diff’ to get more options if you want them.
-
Just remember that if you set the data rate too high in compressor, it won’t play in many players.
Think about it this way – a compression algorithm, even a variable one, can only be tweaked so much; even though it’s reducing the file size greatly, remember that it has to be heavily compressed to not only fit on a DVD, but enough that a standard DVD player knows what to do with it. So even though it isn’t using the full 4.37 G capacity, it’s properly formatted to be useable by most dvd devices out there. You wouldn’t want to increase the quality past that…DVD is obviously a limitation, especially for high-def footage. Exactly why there are blu-ray disks.
So even though you may be able to tweak these settings, you’ll only increase it so much, and then the data rate will be too high to play properly.
-
You could open Terminal and type in
cd /Volumes/[RaidName]
to bring you to the right raid volume directory location, then type
ls -R > raid_output.txt
This recursively lists all files and folders in all directories and all subdirectories, and outputs this into a text file living in your home folder, or wherever you tell it to go. This would give you a nice “snapshot” of everything on the raid.
If you want more options for sorting, type in
man ls
to go to the man page for the ls command. Lots of flags to choose from.
-
I’ve always liked Onyx:
https://www.macupdate.com/info.php/id/11582/onyx
Use v2.0.6 for Leopard 10.5.x.
-
No 4TB single sata drives yet, but you can definitely just slap in a 2TB sata and format it HFS+, no problem. Generally have a higher failure rate with those than 1tb right now though. Use whatever you want; enterprise class is best. Hitachi is usually a great brand for 1TB enterprise drives, we use those all the time.
Many people buy 3 sata drives and create a big internal software raid0 stripe through Disk Utility, which would let you approach about 250MB/s sustained throughput. If you lose a drive in that stripe, though, you lose the whole volume, so plan accordingly.
-
They’re the same exact driver, only the Desktop Display output is disabled in the NDD version. This is to help the people who run into issues extending their desktop over the kona card output by simply removing it as an option.
-
[Matt Callac] “We were told to keep these on the SAN. ”
Many people do. This point is strictly a performance consideration. If you’re using relatively low-bandwidth media you might never notice, but if you’re heaving around many streams of uncompressed HD across an Xsan and you litter the r/w ops with tiny render writes and cache writes, you take a performance hit.
There’s a very long list of tweaks that can be made to take an Xsan from good to excellent in terms of performance and stability. It’ll work fine with a lot of what you throw at it, but to really get the most out of it, there are some rules to follow.
-
This is a really common issue. Don’t run your project files from the san. Your problems will rapidly go away. Probably not the answer you want, but there are very well sussed out ways to work collaboratively with FCP and Xsan and this isn’t one of them.
There are a few really great reasons not to do this that I could spend all day on, but I’m going to try to keep this succinct.
When you say San 2.2, I’m making an assumption that you’re using Xsan, and this is classic collaborative FCP workflow confusion. Here are some basic rules, otherwise you’ll keep running into issues.
-Keep all shared media on the Xsan. This is what it’s designed for.
-Keep all cache files local (Waveform, Thumbnail, and autosave vault)
-Keep all render files local (video and audio)
-Keep all project files local (this is key).Note: the project files can LIVE on the san, but you need to save as locally before you start working on them. Use it as a organizational tool for your files, but don’t actively use them from the san volume.
A few reasons to work project files locally:
-Xsan was designed for big video blocks. When you hammer it with thousands of tiny r/w operations from render files or project files, you really destroy performance. Your raids and metadata were tuned (if they were set up properly) to heave around big blocks of media, not small files.
-You immediately run into all sorts of permissions issues, as well as an array of other errors (a common one is the one you’re seeing)
-Natural separation of media and project files. You don’t want to lose both should the xsan go down.I know people get away with working project files off the xsan, sometimes for long stretches of time, but as you’re seeing, it doesn’t always work. Collaborative FCP workflow is concurrent r/w access to the same media, and it doesn’t relate this way to project files. The Error: File Unknown messages go away immediately after working project files locally.
As a sidenote, you mentioned sleeping the xsan clients; do not sleep computers connected to the xsan, or any san for that matter. Completely disable sleep. This is best practice for any san setup.
-
Do you mean XML? MXF perhaps? That would make a lot more sense…
Did you use Log & Transfer in FCP for the P2 media? You have to retain the folder structure of the P2 media to be able to work with it. Sounds like you may have changed the folder structure or are trying to open individual files in the folder without properly transferring them.
Use Log & Transfer to properly pull your clips in. It really isn’t any more complicated than that.