Firmware update for HD200/250 'minimizes' FCP ingest issues

[Dave Beaty]

I did extensive testing today with the HD250 firmware and the FCPro 5.1.4 Split Clip problem. Unfortunately I am left more puzzled than ever. I think what I found speaks volumes about this problem and the users out there.

First, we have about 6 of the HD50's and 2 HD250's. We have 2 full blown edit suites with all outboard gear, AJA Kona and so on.

First I updated the camera with V1.0.5 for the VTR system as posted on JVC's website. Then I recorded 50 minutes of HDV30p color bars on a Panasonic DVMQ tape. Then I cleaned the heads and recorded 20 or so on a Sony HDV tape.

My edit room was busy so I went to an isolated Mac Pro with a BR-HD50 attached and FCPro 5.1.4 to digitize this material. The HD50 had old firmware, so I updated that unit to 1.0.8. I think it had 1.0.6.

I did an easy set up, set to HDV 720p30 and saw the capture scratch was internal HD. I started a capture now with the Panasonic Tape. Immediate splits. Every 6-10 seconds I was getting a split with the "searching for TC" then "capturing" on the capture window...every few seconds a new clip. I got up to 48 clips before I stopped at about 6 minutes into the continuous shot. I then put the Sony HDV tape in. Same problem. Split's Ville City. I was thinking...OK, this update made the problem WAY worse that I had it before.

Next step, try another system and HD50. So I moved to my edit room in another part of the building and set up the same Easy Set Up and loaded the first tape. BR50 with 1.0.6 firmware. Log and Capture to my external 4 disk SATA RAID 0. ..Capture Now...no splits! I captured about 20 minutes before I stopped to write this. I was totally surprised that the systems caused that much difference in the problem.

They both are Mac Pro's with about 3 or 4 Gigs ram and FCPro 5.1.4. Both have the HD-50 and Easy Set Up Defaults, both have the same OS, 10.4.9. The only diff, as I see it, is bandwidth of the capture disks. Any other testing anyone can think of?

Perhaps this has some explanation why some users are seeing this and others are not.

Dave Beaty

[Jeffrey Butler]

Originally Posted by Dave Beaty

The only diff, as I see it, is bandwidth of the capture disks. Any other testing anyone can think of?

I don't suppose the deck firmware would have anything to do with it? I mean, the original solution was a camera firmware update - or - the playback mechanism. I wouldn't think the firmware on the deck made the difference, but perhaps you could take the deck into the other room and run the capture again...

Maybe scratch disk preferences could potentially do something, too - are they set to (not the same volume) the same thing capacity-wise? Meaning - leave so much drive space free, etc. Are they both capturing a/v or just a or just v?

.02
jeff

[Steve Mullen]

Originally Posted by Dave Beaty

The only diff, as I see it, is bandwidth of the capture disks.

I can't remember if OS X is an "interrupt driven" or an "event polling" OS. If it is polling OS, the faster it can get rid of a block of data, the faster it can poll for the TC data from the camera/VTR. It's possible that with a tape rolling and slow disks -- when the computer does get around to checking TC -- the count is not what is expected. So it thinks there has been a TC break.

PS: If 720p generates a new TC every 1/60th second, that is twice as often as 1080i that is every 1/30th second. Thus, with 1080i the computer would have twice as much time to get back to checking TC. Thus, no problems.

All this is speculation, of course.

[Steve Oakley]

I have a deck here with V1.08 and it captures MUCH better than the HD100 without update , not that there is one... yet ! do hope there is though.

I'm curious though - why use sony and another brand back to back ? thats almost asking for a problem.

one setting you need to change, and I bet its the difference, is to go into User Prefs in FCP and change the timecode break setting to warn after capture. its really out of the way when you think about it, but that solved a lot of problems plus the firmware update and I am close to 100% successful with FW capture. G5 2.5G 4.5G ram fcp 5.1.4 everything else current

[George Strother]

I am also close to 100% success rate on the broken clip issue, capturing from an HD 100(a) to a G5 DP 2.0, 6GB RAM, FCP 6, usually over firewire.

I have a 2TB Raid that tests over 200MB per second and an internal 500GB SATA data drive that tests over 60MB per second with AJA System Test.

I haven't found any consistent difference between these two drives.

[Dave Beaty]

Regarding my testing with two identical systems...

I started testing with the system A with internal capture scratch, the HD50 had 1.0.4 firmware...I thought this was the problem, so I flashed it to 1.0.8. But no change in the splitting up of clips. So firmware of the deck did not change things. (The system B with RAID capture scratch had firmware 1.0.6 and captured with no splits).

I think Steve Mullen may be on to something. I plan on bringing a Firewire 800 drive up and capturing to that with the same tapes. If this is the case, then the seemingly random user experiences may have more to do with system specs than any one failure within the JVC/Apple protocals.

Originally Posted by Steve Mullen

I can't remember if OS X is an "interrupt driven" or an "event polling" OS. If it is polling OS, the faster it can get rid of a block of data, the faster it can poll for the TC data from the camera/VTR. It's possible that with a tape rolling and slow disks -- when the computer does get around to checking TC -- the count is not what is expected. So it thinks there has been a TC break.

All this is speculation, of course.

[Gary Williams]

Originally Posted by Dave Beaty

Regarding my testing with two identical systems...

I started testing with the system A with internal capture scratch, the HD50 had 1.0.4 firmware...I thought this was the problem, so I flashed it to 1.0.8. But no change in the splitting up of clips. So firmware of the deck did not change things. (The system B with RAID capture scratch had firmware 1.0.6 and captured with no splits).

I think Steve Mullen may be on to something. I plan on bringing a Firewire 800 drive up and capturing to that with the same tapes. If this is the case, then the seemingly random user experiences may have more to do with system specs than any one failure within the JVC/Apple protocals.

Let us know what you find out I am very curious see what happens.

[Dave Beaty]

I just finished capturing the same tapes to the Mac Pro that was giving me the splits. This time I attached a Western Digital Firewire 800 500GB drive as the capture scratch.

I captured 10 minutes of the same material with absolutely NO splits. With capture scratch set to internal, I was up to 20 clips in the last test.

So I conclude, at least some of the issues with splitting up of continuous takes is capture drive related. This is assuming you have the latest firmware in the camera and deck.

The internal system HD is NOT a place you want to capture too in any event.

So now if we could overcome the loss of material at the START of each clip we would be very happy editors. Setting preroll to 1 sec helps reduce the loss of material, but it still is a huge problem. I think this will take a software change on Apple's part to fix.

Dave Beaty