Forum Replies Created

Page 9 of 56
  • John Heagy

    November 20, 2013 at 10:23 pm in reply to: Periodic network drop and recovery

    With our B4M Fork recordings ZFS reports 50-50 sequential/random. This is due to the elemental nature of the recordings.

  • John Heagy

    November 18, 2013 at 10:10 pm in reply to: The death of QuickTime as we know it

    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

  • John Heagy

    November 11, 2013 at 4:59 pm in reply to: Periodic network drop and recovery

    This issue persisted in 10.8.5 but was resolved in 10.9.

  • John Heagy

    October 24, 2013 at 10:12 pm in reply to: @John Heagy

    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

  • [Jeremy Garchow] “Have you tried this NFS method, in general, yet?”

    Only as an experiment… we’re not using FCPX generally.

  • John Heagy

    October 24, 2013 at 5:31 pm in reply to: NFS does not work with OS X Mavericks

    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

  • John Heagy

    October 17, 2013 at 8:30 pm in reply to: Periodic network drop and recovery

    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

  • John Heagy

    September 25, 2013 at 10:55 pm in reply to: So where are we in the game?

    [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

  • John Heagy

    September 8, 2013 at 10:42 am in reply to: Sidecar files

    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

Page 9 of 56

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy