John Heagy
Forum Replies Created
-
With our B4M Fork recordings ZFS reports 50-50 sequential/random. This is due to the elemental nature of the recordings.
-
My top wishes for AVFoundation are reference movie and third party codec support.
I’m more concerned about the end of QT APIs on Windows than OS X.
John
-
This issue persisted in 10.8.5 but was resolved in 10.9.
-
I not using a Mac to export NFS… below is how I am mounting NFS in 10.9. This is not a persistent mount.
mkdir /Volumes/ingest
mount -o resvport,nolocks,locallocks,intr,soft,proto=tcp -t nfs 10.xxx.xx.xxx:/zpool01/ingest /Volumes/ingest -
John Heagy
October 24, 2013 at 5:33 pm in reply to: FCP X “Add SAN Location” to any shared storage system[Jeremy Garchow] “Have you tried this NFS method, in general, yet?”
Only as an experiment… we’re not using FCPX generally.
-
I have an NFS mount on a 10.9 Xserve as I type. Apple claims improved NFS performance in 10.9… we’ll see.
I saw problems in 10.8.4 and 10.8.5. NFS is performing a bit better for me in 10.9 but other issues have cropped up notably client/server apps no longer connecting.
-
John Heagy
October 23, 2013 at 10:18 pm in reply to: FCP X “Add SAN Location” to any shared storage system[Jeremy Garchow] “What if it’s a Windows server?”
A Windows server can export an NFS share but it requires addition software both free and paid via Microsoft are available.
John
-
Thanks for everybody’s input.
Regarding jumbo frames… We initially had the drop with standard 1500 MTU and then switched everything to Jumbo including server, client, and switch and the drop went away. So ingest was now solid but playback was still hit or miss. They made some changes to the server and solidified playback but now the ingest drops are back.
John
-
[Walter Soyka] “Maybe it would help if there were some metadata system for identifying unique frames in unique media containers.”
This is why we still use Reel/Tape metadata in file based workflows. What you’re talking about is content ID not just file ID. In our system every frame has a content ID that is a six digit Reel number followed by the TC. For example 123456_1023212. If that number is present in another file it’s the same frame content wise.
Panasonic’s global clip ID is the same except it’s essentially a reel number for every master clip. The difference between this and a file UUID is that when subclips are made that ID passes to the subclip just like reel.
Content ID is essential when you do something like partial file restore which can generate multiple clips from the original. With our reel_TC, the content is known despite the file name changing. We don’t rely at all on path or filename… just the content ID.
Reel gets a bad rape because people still think it means tape. Sometime things work just they way they are.
John
-
Thanks for all that Bryson!
Would you agree that a “Wait for matching xml” in the Conditions tab in Worker would go a long way in making sidecar files easier to use?
John