I don't know if this helps anyone else out or not, but this problem hasn't happened since I switched over to Drewnet Cluster V6. Before that I'd been using Quantum 9b.

I actually like the workflow with ClipWrap better b/c I get to organize my clips into folders first and then import those as keyword collections

@driftwood copying it to the hard drive doesn't help and I'm using non spanned clips. My only work around is to import using 10.0.5

Here's an interesting speculation on the future of FCPX.

http://filmmakermagazine.com/56928-fcp-x-and-the-future-of-editing/

Essentially, it argues that Apple is really the only company truly innovating in the NLE space, and that FCPX truly represents the future of editing. Some interesting history in there too on editing in the past.

If you've avoided trying FCPX until now, this article might tempt you to give it a go.

FCP 10.0.6 import has also stopped seeing spanned clips shot with Sanity on a newly formatted SD card. They just don't show up in the list of clips. :(

I am also can confirm the same problem when importing hi-bitrate files like SEDNA or AN BOOM into FCP X 10.0.6 Very strange behaviour with time code and exactly those files are refusing to import. Seams that with lower bitrate patches like FM 2.02 importing works as it should. So far I man using 5DtoRGB batch, quite slow and inconvenient but developers have promised multicore support in future. Why there is this timecode issue? Is it camera? Final Cut Pro X? or patch?

@5thwall

I confirm the same problem using Sedna-A. This is double sad having to mess with a workflow that had taken a while to refine. I have iCamcorderWrapper and this solved the issue for me.

@b3guy what are your 5d2rgb settings?

I tested out clipwrap and it works great. Keeps the content created field, as well. Good workaround for now.

Just to edit what I wrote above, all the "bad" clips start at 23:27:41:06. At least that's the way that 10.0.6 sees them on my multiple systems (2 mac pros and 1 laptop). 10.0.5, clipwrap, Prelude, Premiere all see the clip with no issue and that it's TC starts at 0.

UPDATE: I moved over to flow motion 2.02 and all is working.

@5thwall I never see the error when I import direct from a card written by my AF100. It's only with the hacked GH2 that I get errors, and only with some high bit rate patches (for example, I'm running AN 444 Soft right now.) Yes, that's the error message that pops up.

I'm not too worried about the problem -- I just Clipwrap footage, then import from there as a standard part of my workflow these days.

@5thwall The clips totally fail to import, and throw an error exception during the import process. I didn't see anything related to 23 hr, but I wasn't looking. I was hoping 10.0.6 might improve this, but no change that I can see.

@kellar42 @arvidtp Thanks for the info, guys...

So here's more of a description of the problem as I'm seeing it in FCPX 10.0.6. The import window sees all the footage. But when you scroll over the bad clips (the ones it won't import), it shows TC at 23:00:00:00. Very odd.

When I recorded a bunch of clips with stock firmware, all TC stayed at 0. On top of that, I haven't had any issues bringing the same footage in with Prelude/Premiere/Adobe Media Encoder. Also, this is not an issue with 10.0.5 or prior. I'm keeping a copy of that around for importing.

Ultimately, I'm not too concerned about how I bring the footage in. My most important concern is that the original camera record date/time stays valid so that I can use FCPX to sync audio or do multicam syncs (so that it'll match my 2nd source audio). Does anyone know if clipwrap keeps that info in the clip?

I'll test this out more later. It's Saturday here, so enjoying some downtime ;-).