[Aaron Rock]

Thanks Bryson, I see what you’re saying. When we move files into or out of catdv, we often just use drag and drop.

To archive files into catdv and onto our server, we run into issues.

When we add a file to a catalog from one of our computers, we drag and drop the file into the catdv window. Then copy the media files onto the raid we use as a server (using “Copy Media Files” and being sure to include the checkbox “update media so they refer to new copy”).

However, if files are accidentally copied to the wrong location, or their media reference point isn’t updated, then we have to update the connection to the base file in the tree, Whether I select the files individually and search them out, or grab a cluster and choose “update media location”, once it tries to access the server and populate the list of media files in our server, it freezes up.

Generally we use the tee to reference catalogs and nothing else. It seems like the slowdown comes when the program tries to populate a list of all the media files housed in our RAID. These files are easy for it to reference in smaller catalogs, but not when it is trying to open a window which accesses our entire media folder. There is a smaller folder of files we kept separate in the database. Accessing these files takes a matter of seconds, where the main database can take 5 mins. plus.
Below I’ll try and illustrate what I mean.

This is our media folder, right around 27,000 clips. Copying media to this folder through catdv is next to impossible thanks to the size of the folder.

Conversely, this folder only holds a limited base of clips, this updating items in this folder either through catdv or finder is a breeze.

So my question is, would the best way to fix the problem be to bring files into catdv only from the server (as in copy the files to our server raid, then bring them into catdv or would it be better to trim this folder down to a more manageable level with sub-folders and keep on using it the way we have? Or is there a better option than either of these?

Thanks for all the feedback. I definitely appreciate the help.

[Aaron Rock]

The Memory allocation helps somewhat, thanks, I think there’s a communication mixup on the “database” question.

The server (database) as in, the raid where we house all video files is massive.
The catalogs are relatively small (at least the ones I’m working with) the particular catalog I’m in only has (had) about 75 clips, however I was trying to update the media location to the files on the server as opposed to those on my computer.

The folder holding these files contains about 15000 items. These are nested in various catalogs on CatDV, but housed in one location.

No matter how small or large the catalog I’m in is, I still deal with the program freezing as soon as I try and access this folder location through CatDV. Does that make sense? I’m wondering about shrinking the size of this folder by adding subfolders, but don’t know if this will get to the core issue, at the same time I know the core issue can’t be catalog size because it happens in any size catalog

[Aaron Rock]

Massive (15k clips+), which is part of the issue, but the database has only recently slowed down to this extent, and we haven’t added too much to the initial catalog.

Over the past year probably 1500 clips, when we started with CatDV 2 years ago, the Catalogs already had roughly 12k clips and the speed was markedly faster.

I guess thats why I’m wondering about the sudden slowdown. Could it be anything else or are we just finally getting to the point where we’ll need to sub-folder some of our footage?

[Aaron Rock]

E-sata is the only connection option for our raids. HDMI would probably be less problematic.

[Aaron Rock]

I had heard of this issue from another forum. I renamed a few timelapse folders on the raid with “DCIM”, but these were subfolders, thus it didn’t resolve the issue. The “CONTENTS” folder I had to copy to my RAID last night was the culprit.

[Aaron Rock]

Finally resolved my own issue.

The interpretation of the RAID by FCPX was the tipoff. Turns out that one of the folders on my RAID was labeled “CONTENTS” which is what many cards store media information in. Thus X was interpreting my raid as a card and not a drive.

I hope this helps anyone who runs into similar issues with their RAID/ FCPX.

[Aaron Rock]

Sigh, I don’t know whether to laugh or cry. Trie opening FCPX, creating a new event, then importing within the program to see if I could essentially recreate the event. Unfortunately, FCPX is reading my RAID as if it were a p2 card, listing it under cameras and populating it with ever video and graphic file on the drive… I have never seen anything like this before in my life.

[Aaron Rock]

Thank you for all the feedback on this. It has yet to be pegged down. My boss believes it’s a raid issue, I disagree. Ive used 2 separate raids with no permission errors and this issue still occurs. Another anomaly of X that goes unanswered.

[Aaron Rock]

Andy’s method does work to fix this issue, but it can be confusing at first.

For a quick fix, just take the title, drop it to the timeline, turn it into a compound clip. (Opt-G)

From there you can trim it to the desired length, rather than FCPX automatically retiming it.

Hope this helps.

[Aaron Rock]

Thank you all for the feedback,
David, thank you for assuring me that I’m not the only one who’s come across this. Like you said, the issue only seems to happen with FCPX. Unfortunately the crash is so complete that it doesn’t even generate errors on the log in console. Thus I have no direction to go in to fix it.
Like you said Jeff, I could spend weeks tinkering to try and find the root of the problem and not get to the cause.

A few points to make: NVRAM I did reset. Will check to make sure the ram installed is seated properly. Disk utility, disk permissions, all come back okay. I’m not supported for the AHT (a major PIA). So my next hope is apple support. Once I get to the root of this I will be sure to share it here.

Thanks again.
Aaron Rock