[Peter Sengstock]

I started a thread over at Xsanity, and we’re on to something: https://www.xsanity.com/forum/viewtopic.php?p=74023#74023

As I suspected, it seems like the # in the clip names makes FCP go batty when dealing with files on an Xsan volume. I haven’t been able to find any documentation from Apple to support this, though.

We’re having much bigger issues with the workflow, mostly in that many students haven’t uniquely labeled their archived reels prior to ingest. I’ve seen projects where every reel is just called PRIVATE or NO NAME. Add the incremented “Clip #XX” naming issue and it’s nearly impossible to get some of these projects back to normal.

Our original solution was to just have them batch capture all the offline clips to get their projects going again, but this just makes it too complicated. Another thing to watch out for with this method is having multiple source volumes loaded during Log and Transfer. Per this Apple support doc for FCP 6, they say that clips can get confused during ingest. We’re running FCP 7.0.3, but maybe this is still an issue simply due to the fact that it’s AVCHD media. I can confirm that I’ve seen clips change, but because of all the haphazard testing we’ve been doing, I can’t confirm whether or not it’s in line with the issue in this support doc.

For students that haven’t had issues, we’re telling them to uniquely name their clips in FCP, making sure to remove the # from the clip name. Then they just tell FCP to rename the files to match the clips. We only started trying this today, so we’ll see how it goes.

Hope this helps save someone else some stress…

Pete

[Peter Sengstock]

We’re seeing the same issue with a handful of our students. It had only be affecting a few, but more keep coming up. We’re running FCP 7.0.3 on Mac OS X 10.6.8 with the latest version of Xsan on the backend.

I suspect it might have something to do with FCP naming each file as “Clip #xxx”. I’m not certain that # symbols are valid in file names, but perhaps someone else can speak to this. Curiously, even though our students have indicated that they captured they media correctly, for the problem clips, FCP thinks that their location is at the root of our SAN volume, rather that the Capture Scratch folder they were originally captured to.

We tested this workflow out before we bought our new Sony NX5Us and never had this issue. Now it’s popping up periodically. For 150+ undergraduates, it’s not sufficient to just say, “yeah, it does that sometimes… try it again and keep your fingers crossed…”

Keep me posted if you come across any solutions.

Thanks!

Pete

[Peter Sengstock]

Did anything ever come of this, or did you have to give up?

I’ve got the following issue, but with our Io HD. We have an old production telecine that we use for transferring student films. We’re trying to make tapeless film transfers by going straight from the telecine to the Io HD. Keycode reader picks up the keycode, passes it off to our TC generator, which pushes out TC to the LTC port on the back of the Io HD. This whole process works great, except for the fact that all of our files end up with timecode that’s exactly 5 frames early. Every. Single. Time…

Our engineers have been complaining that the Io HD doesn’t jam sync like a deck, but I think that we just need to figure out how to offset the 5 frames. We’re just using AJA’s Xchange app.

Does anyone have any suggestions? Thanks!

PGS