ProRes clips going offline on new SAN

[pgsengstock]

We have a serious issue plaguing us on our new SAN. We're having students ingest AVCHD media via FCP 7.0.3 to ProRes 422 (proxy). Occasionally, the transferred clips will go offline in FCP, and the logging info will just show their target as "Xsan:" or "Xsan:Clip #X.mov". More details can be found in my post here:

https://discussions.apple.com/message/16883569#16883569

Part of me is thinking it's just poor logging/asset management on the students' part, but I can't really tell that to a class of 130 intro production students. They're even starting to point fingers at specific workstations: "That's the bad one... It made my clips all red." Of course, it's not localized to any few workstations or projects; it's completely random.

I'm at a loss for what could be causing this oddness. As always, any suggestions are most appreciated.

Thanks!


Pete

[pgsengstock]

Just in case the Apple discussion gets removed or altered, my post:

We are having the exact same problem, but it's much more widespread. For the record we are using the following:

Mac OS X 10.6.8
Xsan 2
Final Cut Pro 7.0.3
Sony NX5U AVCHD media logged and transferred to ProRes 422 (proxy)

Sometimes our students can reconnect without issues, but often it's next to impossible to reconnect, so they have to batch capture their footage from their archived media. For one or two clips, this isn't too bad, but sometimes it's almost an entire project. I can confirm that this is the same issue because the clip paths in FCP now just list "Xsan:" (our Xsan volume name) or "Xsan:Clip ####.mov" (where there should be many other folders). Permissions aren't an issue, because all the files show up in Finder and can play back in QT without issue.

One thought I've had is about how FCP auto-names the ProRes clips as they are ingested from the source archives or cards. All the clips are sequentially numbered as Clip #1, Clip #2, etc.. If a student ingests from more than one media archive (or SDHC card), they will have multiple Clip #1s, Clip #2s, etc.. In Capture Scratch, FCP will automatically increment the clip name until it finds the next available name. Example:

Card A
Clip #1
Clip #2
Clip #3

Card B
Clip #1
Clip #2

If I ingest the following from Card A:
Clip #1
Clip #3
And then try to ingest files from Card B, this is what I get:
Clip #1 becomes Clip #2 (the next available name)
Clip #2 becomes Clip #4

You can see what a mess this can become. The issue is further compounded when our students fail to uniquely name their archived cards. In the logging information, all the reels are listed as "NO NAME", so it's impossible to figure out whether a clip is from one card or another.

Most recently, I've noticed the following behavior: students reported that some clips suddenly started "flashing colors" and playing rapid random frames. When restarting FCP, the clips in question (and several others) were offline. This seems to be the first effect of this problem, but I can't trace it back to a specific cause.

Lastly, today, I discovered issues with students clips that had been recaptured after going offline. I saved the project with a new name in an attempt to distinguish the newly captured files from the old ones. One would expect a new project folder within Capture Scratch, but instead, I got several new clips right in the main Capture Scratch folder, all named "[new project name] #".

I'm thoroughly frustrated with all this, as are our students. I think some of this just boils down to maintaining a very rigid ingest workflow, but the offline clips is very troubling. Any other suggestions or similar experiences would be greatly appreciated!


Pete

[JSal]

Are all of your luns online and intact? Is your Xsan set to round robin or balance allocation, could it be putting these clips on a corrupt lun?

[pgsengstock]

As far as I can tell, the SAN itself is rock solid. If we had a corrupt LUN, I'd expect much bigger issues than a few FCP linkages getting messed up--I'd expect ALL our media to be going offline and projects to be completely corrupted beyond repair. As it is, it's only a few here and there. Worse yet, sometimes it fixes itself when the students move to a different workstation!

Another point I should make is that we have an editing class of 30+ students all sharing the same DV-NTSC assets, and not a single one of them has been affected. They're building much larger projects (full feature) than the intro students, who are just cutting 5-7min docs.

I'll have to wait until another time to do this off hours, but I will check the SAN's status with cvfsck and report back if I find anything unusual. All the logs seem to indicate that it's running fine, though.

[no_xvi]

Hi Mate, we had the same issue here.

Its a character bug between XSAN and FCP.

Resolution is simple.

You need to remove the hash tag from the clip.

For example, at the log and transfer stage, change the clip name from;

Clip #1

to

Clip_1

This should resolve the issue.

Regards,
SJ

[pgsengstock]

That's what I was thinking!

Do you have any evidence to support this?

Unfortunately, it far to late to correct this for this semester, but I feel like custom log and transfer names are in line for the future.

Will test to confirm.

[pgsengstock]

Anyone have suggestions for quickly cleaning up 100+ student projects which all have files that were ingested as Clip #XX? We don't have time for them to all batch capture again. I wish that renaming files to match clips would be enough, but I'm afraid to tell EVERY student to do this if only some are having problems.

Update: one student reported that simply reconnecting the offline clips didn't work. She could reconnect most, but sometimes they were not the correct source. Of course, this was only apparent when she started working on her sequence. In Finder, the problem clip seemed to have the same content as a different clip. No clue how.

[no_xvi]

You should be able to script it.

But thankfully I saw it on the first project we did with AVC ingest and bit the bullet and manually renamed the clips and then manually re-linked.

Pain in the ass. But it worked.

Then implemented a workflow whereby all our MCR ops had to abide by.

Regards,
SJ

[thomasb]

pgsengstock: Did you manage to fix or confirm this? Did renaming the clips solve the problems?

I just stumbled upon very similar issues with files from a Sony AVCHD cam that were ingested via Log & Transfer in FCP 7 with hash # in the file names. Clicking "Reveal in Finder" on clips in FCP 7 showed different file names in Finder. Importing a folder containing 50+ clips only imported about 40 clips. The contents of the files were not right according to the clip number.

Avoiding the hash # in file names seems to do the trick here too. Reingesting the material without hash # in the file name seems to have solved the problem.

The Xsan volume seems 100% healthy. No file system errors to be found.

We noticed this issue on a 10.6.8 client running Xsan 2.2.2. MDCs are running Lion 10.7.5 and Xsan 2.3. We also noticed this before upgrading the MDCs to 10.7. Seems to be a problem with hash # in file names and FCP 7 on Xsan.

I have yet to be able to reproduce this issue 100%, but I will try it in our lab environment if I find the time to do it.

Has anybody else seen problems like this?

[pgsengstock]

The following semester, I preconfigured all the student accounts so that they would default to a custom file naming convention during ingest, something like [customname]_YYYYMMDD_HHMMSS.mov.

We didn't have any issues at all. Since then, we've moved to Premiere. This introduced its own set of workflow headaches, but I think we've been able to work out most of the kinks. Now if I can just get the students to RTFM...

[thomasb]

Thanks for the quick reply!

Good to hear this solved the problem for you too.

Anybody got an idea why hash # is a problem in file names with Xsan and FCP 7?