Matt Lyon
Forum Replies Created
-
Cool Jonathan, glad to help. I would also suggest restricting the characters you use in filenames to UNIX/LINUX/DOS friendly ones: No slashes, no spaces (use underscores instead), no question marks, etc. It’s one less thing that can trip up the system.
Matt Lyon
Editor
Toronto -
Yeah, I’d have to agree with David that it is likely an issue with the Edit-Share. Could it be a problem with file names being too long? I worked on a project a few years back where we used a Linux based SAN (that used some kind of software layer to stay compatible with the apple double file system). If file names exceeded 32 characters (IIRC), the server would randomly append gibberish to the end of the file name, much in the manner you describe. But this was in the pre-xsan, FCP 4.1 days … so you’d /think/ that issues like this wouldn’t be around anymore, but you never know.
Matt Lyon
Editor
Toronto -
Hi Alex,
How are you ingesting sound? Are you syncing digital files after you run the video through cinema tools? Or is the audio already married to picture on your rushes tapes?
I would also recommend that you work in 23.98, NOT 24.00 (which is what you are using, if I understand your post correctly). 23.98 (or, more correctly, 23.976) is the standard way of working and will cause much less headaches down the road then 24.00.
Matt Lyon
Editor
Toronto -
don’t forget to type a space between “cd” and “/Volumes”!
Matt Lyon
Editor
Toronto -
Okay, I just had a brainstorm that this may be an issue with the way your hard drive is being mounted. How comfortable are you in using the terminal?
open the terminal and type: “cd /Volumes” (no quotes) then hit “enter”
next, type “ls”
the screen will print out a list of your mounted hard drives. Look for the name of your media drive. See if there is a duplicate entry with something like “-1” attached to the end. If this is the case, it may be that your drive is mounting using the wrong pathname, so the xml is being fooled to look in the wrong place when it loads. eg, “media_drive-1” instead of “media_drive.” Most people won’t even know this is happening because the HD retains the correct name in the finder. You will only see the problem in the terminal window.
This happens sometimes when a drive doesn’t dismount properly (like during a crash), it may not delete it’s own entry from the list of devices OSX stores in its system files. When the HD is mounted again, it creates a new name, like “media_drive-1.” If this is the case you need to unmount your media drive (and unplug it, if you are paranoid like me), then repeat the terminal commands from above. You will see that there is still a listing for your media drive, even though it isn’t connected. This is actually a bogus alias that points to nothing. Delete it by typing:
“rm
” followed by enter. Reconnect your drive and try to import the xml again. If this doesn’t work then I’m at a loss!
The only other thing to check would be to have you both export a “good” xml of the same sequence, with all media attached. Open the XML files in text edit and do a search for “
.” Every clip in the timeline has a “ ” entry that tells FCP where the media lives. Find the entry for the same clip in each xml and check if there is any difference in the full path name. (Note that the problem I described earlier in this post would make XMLs that exhibit this behaviour). This is a good place to begin looking for problems. Let me know if this helps at all!
Matt Lyon
Editor
Toronto -
If the FCP files work fine, why don’t you send them instead of XML files? If you zip the .fcp files, they will be about one tenth the size (if file size is a concern).
I guess XML files don’t support the slash (“/”) character, so it sounds like your only other option would be to rename all the files in both projects that contain this character, which might be a big pain!
As a matter of habit, I use underscores (“_”) instead of spaces or slashes (or almost any other symbol, for that matter), because they are less likely to cause problems across various file formats, programs and platforms.
Matt Lyon
Editor
Toronto -
Me too! As far back as FCP 4.1, IIRC … always w/ Kona (although maybe Decklink too, my memory is hazy). I had some success fixing this by exporting my timeline as a self contained quicktime, then importing the file into a new, empty project and dumping to tape from there (with nothing else open). Of course, drive space might become an issue now that HD is more common. Try adjusting your preroll setting too.
Matt Lyon
Editor
Toronto -
Did you ever at any point change the timebase of the problem sequence from drop frame to non drop frame (after editing had begun)? I noticed a weird glitch recently (in FCP 6) where I had done that, and the EDL I exported had improper timecodes. Copying and pasting the footage into a fresh timeline fixed the problem.
Matt Lyon
Editor
Toronto -
I’ve had the exact same problem, and like several folks pointed out already, simply copying the project and deleting bins/sequences doesn’t do the trick.
And you can’t copy and paste from your project into an empty project without crashing. My solution would be to try loading the project file with the media offline (in other words, unmount the media drives, then launch the project). Move only your essential sequences and bins into a brand new, empty project. Save, close all open projects, and quit. Plug in your media drive, launch FCP and open the new project. Relink media if necessary. Also a good habit is to copy and paste using keyboard shortcuts, not via drag and drop.
FWIW, it is the sequences that eat up the most room, not the bins. I try to keep my projects around 50-80 megs. At over 100 megs, I start to notice performance hits and less stability (Okay, that’s a BIG generalization … but it’s still a rule of thumb for me).
HTH,Matt Lyon
Editor
Toronto -
Hi Nate,
I wish I could offer more concrete advice, but I haven’t experienced your issue directly. That being said, I have in the past dealt with troubleshooting integration issues between FCP and custom and/or 3rd party tools, so I feel your pain. Have you tried exporting a “bad” project via XML and comparing it to an XML from a “good” project? You can use an XML diff tool that might be able to shed some light on what syntax is different, which could offer clues as to what is causing the problems. Depending on what resources you have available (know any good shell script gurus?), you might be able to write a little program that could essentially do a “find and replace” in your xml to fix the bad tags. Having been through this process, I should warn you that it can be very time consuming to do all the iteration necessary to get a script working properly. Have you tried contacting the makers of “Clipfinder”? Maybe you could send them an xml and see if they could shed some light on the issue? Please keep us updated on whether you solve this issue! Hope this helps,
Matt Lyon
Editor
Toronto