[Mike Parfit]

For anyone else who has experienced this, it does look like a bug to me. If a computer program tells you it’s going to do something, does it, and it doesn’t work, that’s a bug. If it can’t do what it promises, then it should give an error message, not just go ahead and botch the job.

It appears that the problem with Print to Video in my systems is related to the way the individual clip is made. I have now been able to print to video by making movies with the Recompress all Frames box checked, as well as the self contained one.

This seems odd, since one of the clips I made that didn’t work was a self-contained QuickTime movie turned into HDV from DVCPROHD, which one would think would result in recompression. However, codecs and their elaborate rituals of reconstitution are a bit beyond me, so I won’t speculate further. Recompressing seems to work; that’s good.

To me the bug is not in the fact that it didn’t like the self-contained movie I made without recompressing all frames; that could make sense. But FCP shouldn’t take those kinds of files and tell you that they were adequately conformed, then try to print them to the tape. It should simply either take the time to conduct the conforming procedure or it should tell you the file isn’t properly prepared.

Mike

[Mike Parfit]

Well, Mike…. I have some questions for you. What is your Easy Setup? How are your drives striped? Do you have them Journaled?

Hi, Wayne,

The same thing happens in several different setups. One is DVCPROHD, another is HDV. Both are custom setups to take all the easy setup parameters except that the video plays back in 8-bit 1080i through the Kona 3. My 3 Seagate drives are striped Raid 0 into one volume. They are not journaled. The volume is less than 1/2 full.

Thanks for any ideas you may have,

Mike

[Mike Parfit]

I have the same problem of inevitable dropped frames on my Mac Pro, with a raid 0 set of 3 Seagate 750s. I sometimes even drop frames trying to play back a single clip of audio only! AJA numbers look great but there are spikes on the graph down to very low speeds. You’d think this would be related the problem, but how do we fix it? I am simply unable to play through my project smoothly ever. I, too, hope it’s a setting somewhere, but so far no enlightenment has come.

Mike

[Mike Parfit]

Hi, Jerry,

Thanks for the quick response. Yes, the file plays back perfectly from the timeline. However, I’m afraid I don’t know what you mean by doing a crash record to my camera. I thought there was no other way of getting HDV out of the machine except to conform and print to video. Can you explain?

Many thanks,

Mike

[Mike Parfit]

Thanks, Wayne,

Our memory is OK: It’s 4GB of original Apple memory installed as specified in the article you cite. So that’s probably not it. Certainly makes sense to check, though.

Mike

[Mike Parfit]

Thanks for all the responses.

Went to barefeats, which I’ve always liked. Saw they’d revised their Seagate assessment, but couldn’t find the original comment on the three-drive array.

Here’s a possible clue and question: My Kona system test of the raid array shows high speed transfer, but the chart and text versions show significant downward spikes of much slower data delivery in the frame-by-frame analysis. Is this significant, or does the cache on the drive, which I’ve disabled in the Kona test, take care of those spikes? If it doesn’t, then that could account for the dropped frames. The additional single Seagate 750 that is also on my system does not show such dramatic drops.

Thanks,

Mike

[Mike Parfit]

Although I heard they had possibly fixed the issues, the Seagate 750gb “perpendicular” drives were creating problems when stripped together in a raid configuration

Holy smoke! I had no idea. I thought I’d been reading here fairly carefully, but maybe not. Isn’t that a ripe irony? People have been telling me for months on this forum and others to get rid of the firewire stuff and invest in an array of Seagates, and now this? I thought everyone was using these drives in their Sonnet and CalDigit arrays.

Is anyone else having these issues, and if so would we who are using highly compressed formats be better just going back to individual drives at 50MB/s?

Meanwhile I’ll try to run my show as a QuickTime on my old FW 800. What fun.

Thanks,

Mike

[Mike Parfit]

Thanks, Walter, but unfortunately it made no difference. I moved or trashed every piece of media on the system disk, trashed the prefs again, set the scratch disks to the raid, rendered audio. But it only took FCP about 30 seconds to have its first dropped frames. (By the way, I am getting the dropped frames warning; I’m not just seeing bumps.)

Anything else I can do?

Thanks,

Mike

[Mike Parfit]

Many thanks for the responses.

I frequently trash the prefs, using FCPRescue. I use the Kona card to monitor the output on a Dell, and I turn off mirroring on the desktop. I did all these things before I wrote the first post, but to no avail.

One possibility that you raise, Walter: I’m pretty careful to reset the scratch disks after the prefs are trashed, but now that I look, I see that a few render files are on the system disk. I get 50MB/s on that one, so I wouldn’t think it would have an effect, particularly with the HDV at less than 4 MB/s, but it’s sure worth a try. I’ll fix that and report back.

Thanks.

Mike

[Mike Parfit]

One comment:

We have been working with footage originated in HDV, DV and even some old Hi-8 and VHS. Basic cuts and dissolves have been no problem in HDV. It’s not junk. Stuff looks fine; it’s just a bit weird and slow to work with compared to DVCPROHD, but not terrible. (Though with our big project we still may do a DVCPROHD online through the Kona 3, to prepare for color correction, etc.)

To put it back out to HDV for portable review at higher definition than a DVD, we first export an HDV Quicktime clip of chunks of the timeline (recompressing all frames) then put those clips in another HDV sequence. If you don’t do anything to those clips, FCP conforms the HDV in moments and it can be printed to tape. Of course the clip export takes a lot of time, but then you have a clip that can be moved around and then conformed to HDV output again without spending hours conforming, whereas when you conform a timeline and then fiddle with the timeline, you have to go to an overnight or longer conform process again.

Not sure if this has any value, but it works, usually, apart from the crashing problems we have, which is another matter.

Good luck,

Mike