AVCHD files going offline in FCP
After Log and Transfer FCP keeps losing track of my clips, telling me I need to reconnect and alerting media start and end conflicts. The original ProRes 422 files on disk remain intact, but when I reconnect the original clip FCP seems to rename some files (not all, but inconsistent ) they change to another file name and the content changes accordingly. Once started I can fully edit but when I shut FCP and restart the clip sequence is changed.
I'm editing in Final Cut Pro 7.0.3 and ingesting AVCHD clips from a Panasonic AF100/1/2 recorded to SDXC 64GB cards. I'm on a Mac eight core running Mac OS 10.5.8.
I recall some others had this issue, but couldn't find a thread of resolve. I'd be grateful for any help as I've exhausted all possibilities I can think of(short of using say Clipwrap to pre-ingest and transpose).
[Chris Ripple] "I'm editing in Final Cut Pro 7.0.3 and ingesting AVCHD clips from a Panasonic AF100/1/2 recorded to SDXC 64GB cards."
I hope this isn't your workflow. Hopefully you are copying your sd cards onto multiple hard drives and are L & T from the hard drives.
When you edit, make sure the hard drive that your media (proRes from L&T) is stored on is mounted before starting FCP.
Here is a the correct workflow for tapeless media.
Eisen Video Productions
Chicago Final Cut Pro Users Group
Thanks for your thoughts Steve, much appreciated.
Files are backed up on dual redundancy offsite RAID over permanently mounted fibre linked SAN, so they should be pretty safe and yes we always L&T from the source. (I assume the file structure off source is the same??) We have always and still are direct ingesting P2 and other data formats as pro-res 422 without an issue, but with this new PanAF AFCHD- dramas!!
So that takes us back to the problem.
Curiously while the offline issue is always there at FCP start-up, where in the file directory it manifests itself changes. After launching FCP and importing files the file directory is duplicating some files (not all) and creating new file names. It appears at face value that FCP, or the file management system on behalf of FCP is tampering with the file / naming structure??.
While we can only ingest AVCHD on v.10.6 the transposed PR422 files should have no compatibility issue with v10.5? In any case we've tried on both 10.5 and 10.6 (we run both for various reasons) in case there is a difference in embedded header info, but no resolution. Starting to think this may be an Xsan issue.
Is anyone else familiar with this problem?
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.
Having tried all know resolves we weren't able to reduce the problem on the current Mac 10.5 / XSAN / FCP platform. Curiously the problem appears unique to only pro-res.mov files ingested to FCP from Panasonic AVCHD source, all other files behave perfectly. The problem continued outside of FCP while copy those same files across networked directories suggesting it's most likely a file manager or metadata server related problem. We've temporarily worked around by pulling footage direct from RAID to FCP via eSATA. It's extremely slow but does not show these problems. We are rebuilding the server farm to XSAN 2 and will try again.
It's worrying that this problem just started with AVCHD -> Pro-res 4:2:2 files ingested from new Pana AG AF 100. Thanks Peter for sharing your experience, If anyone is aware of this problem we'd love to know. This problem is costing us considerably.
when image matter
I started a thread over at Xsanity, and we're on to something: http://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...
Thanks to Peter for encouraging me to post here -
We encountered a similar problem with students losing L+T files, having files appear offline anytime they closed the project or moved to another computer in spite of having their footage on an external hard drive.
it seems that at the core was a skipped step pre-ingest. Because of time and computer disk space issues some people used the Log and Transfer straight from the memory cards.
What confused us at first was the issue seemed to only affect certain groups, even though several had adopted this procedure- however on inspection this seemingly random slice of luck for some students was down to their being no other AVCHD files on the system when they entered into the L+T window.
And so, sorry if it seems like stating the obvious but -
with our machines on FCP 6.0.8, their is no option to use ProRes HQ, and therefore, it seems, no timecode for FCP or mere humans to confirm that a clip is really the intended/named clip
coming straight from the cards the Volume is NONAME which becomes the Reel Name in FCP, which Reel Name would be shared by all other straight from card transfers -as would the title 'Clip #1' 'Clip #2' etc and so while the FCP project might work with those files in the beginning, as soon as the project is closed and re-opened it can look for a 'Clip #1' etc that is not the one that was Log+Transferred into the project, but one that was L+T'd by someone else-
as someone mentioned in a previous post, FCP/L+T will see that there are already clips from NONAME in the L+T cache and so will increment from the end of those clips, thereby making what we see as supposed 'Clip #1' into what the computer sees as Clip #Seemingly Random Number
having scratch disks set incorrectly or having these conflicting 'Clip #Names' all going into the same scratch disk seems to compound the issue as does continual reconnecting and project copying
Without saying there is a simple fix - creating a new project and copying the cut sequence in as either a straight Cut + Paste or by using an XML import - and then reconnecting manually seems to have resolved the issue for those affected. And when the correct clips are back online - changing the Reel Number manually and also using the Rename File to Match Clip function after changing clip names in FCP - this seems to keep it all together thereafter.
Hope it helps someone
Did you manage to resolve this? I am having this issue now.