Final Cut Pro 7.0.3 Crash Reports - Need help interpreting problem

[Dawn Minenna]

Hello.

FCP Has always been rock solid. 2 weeks ago I started having consistent crashes while using HDV-Apple pro res HQ for Canon 1080 60i Capture setting. On my MAC PRO's - one using Snow leopard, the other 10.5.3. Are getting FCP message that the program has quit unexpectedly. I've safe booted, run permissions checks on both machines, changed scratch disk, threw away preferences and still crashing any where from 2-10 minutes into the capture.

This is the crash report:


Process: Final Cut Pro [480]
Path: /Applications/Final Cut Pro.app/Contents/MacOS/Final Cut Pro
Identifier: com.apple.FinalCutPro
Version: 7.0.3 (7.0.3)
Build Info: FCPApp-1008261348~8
Code Type: X86 (Native)
Parent Process: launchd [155]

Date/Time: 2011-05-07 08:10:25.290 -0700
OS Version: Mac OS X 10.6.7 (10J869)
Report Version: 6

Interval Since Last Report: 223900 sec
Crashes Since Last Report: 8
Per-App Interval Since Last Report: 28995 sec
Per-App Crashes Since Last Report: 3
Anonymous UUID: 9817D6A3-294D-4934-8D9E-DA4F58B49AC0

Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Crashed Thread: 42

**

Thread 42 Crashed:
0 libSystem.B.dylib 0x00c9c4ee __semwait_signal_nocancel + 10
1 libSystem.B.dylib 0x00c9c3d2 nanosleep$NOCANCEL$UNIX2003 + 166
2 libSystem.B.dylib 0x00d172a6 usleep$NOCANCEL$UNIX2003 + 61
3 libSystem.B.dylib 0x00d389c4 abort + 105
4 libstdc++.6.dylib 0x0114dfda __gnu_cxx::__verbose_terminate_handler() + 433
5 libstdc++.6.dylib 0x0114c17a __cxxabiv1::__terminate(void (*)()) + 10
6 libstdc++.6.dylib 0x0114c1ba __cxxabiv1::__unexpected(void (*)()) + 0
7 libstdc++.6.dylib 0x0114c2b8 __gxx_exception_cleanup(_Unwind_Reason_Code, _Unwind_Exception*) + 0
8 libstdc++.6.dylib 0x0114c658 operator new(unsigned long) + 101
9 libstdc++.6.dylib 0x0114c703 operator new[](unsigned long) + 17
10 com.apple.FinalCutPro 0x005d7200 QTMovieWriter::addVideoSample(void*, unsigned long) + 62
11 com.apple.FinalCutPro 0x005d5e04 MP2Dec_Output::WriteQTData(unsigned char*, EFrameType, int, unsigned long long, int, RecordDate, MtdTitleTimeCode, MtdTitleTimeCode, int) + 394
12 com.apple.FinalCutPro 0x005d611f MP2Dec_Output::HandleCallBack(OutputCallBackStruct_*, EOutputCallBackReason) + 497
13 com.apple.FinalCutPro 0x005d6149 ToOutputCallBackFunction(OutputCallBackStruct_*, EOutputCallBackReason) + 31
14 com.apple.FinalCutPro 0x005d5315 MP2Dec_ICodecEnc::HandleOutput(int) + 1127
15 com.apple.FinalCutPro 0x005d54e0 MP2Dec_ICodecEnc::ICodecEncThreadFunction() + 104
16 com.apple.FinalCutPro 0x005d550f ThreadFunction(void*) + 17
17 libSystem.B.dylib 0x00c5c7fd _pthread_start + 345
18 libSystem.B.dylib 0x00c5c682 thread_start + 34
**

I'm always one to know it's usually "user error" - However, I'm pretty sure at this point after trying new HV20's for the capture, old tapes that worked before, new settings, I'm stumped??

Does anyone know of an update that happened that is causing this crash?

Cheers, Dawn

**At 9:15 am 4th crash of the morning

Thread 35 Crashed:
0 libSystem.B.dylib 0x00c9c4ee __semwait_signal_nocancel + 10
1 libSystem.B.dylib 0x00c9c3d2 nanosleep$NOCANCEL$UNIX2003 + 166
2 libSystem.B.dylib 0x00d172a6 usleep$NOCANCEL$UNIX2003 + 61
3 libSystem.B.dylib 0x00d389c4 abort + 105
4 libstdc++.6.dylib 0x0114dfda __gnu_cxx::__verbose_terminate_handler() + 433
5 libstdc++.6.dylib 0x0114c17a __cxxabiv1::__terminate(void (*)()) + 10
6 libstdc++.6.dylib 0x0114c1ba __cxxabiv1::__unexpected(void (*)()) + 0
7 libstdc++.6.dylib 0x0114c2b8 __gxx_exception_cleanup(_Unwind_Reason_Code, _Unwind_Exception*) + 0
8 libstdc++.6.dylib 0x0114c658 operator new(unsigned long) + 101
9 libstdc++.6.dylib 0x0114c703 operator new[](unsigned long) + 17
10 com.apple.FinalCutPro 0x005d7200 QTMovieWriter::addVideoSample(void*, unsigned long) + 62
11 com.apple.FinalCutPro 0x005d5e04 MP2Dec_Output::WriteQTData(unsigned char*, EFrameType, int, unsigned long long, int, RecordDate, MtdTitleTimeCode, MtdTitleTimeCode, int) + 394
12 com.apple.FinalCutPro 0x005d611f MP2Dec_Output::HandleCallBack(OutputCallBackStruct_*, EOutputCallBackReason) + 497
13 com.apple.FinalCutPro 0x005d6149 ToOutputCallBackFunction(OutputCallBackStruct_*, EOutputCallBackReason) + 31
14 com.apple.FinalCutPro 0x005d5315 MP2Dec_ICodecEnc::HandleOutput(int) + 1127
15 com.apple.FinalCutPro 0x005d54e0 MP2Dec_ICodecEnc::ICodecEncThreadFunction() + 104
16 com.apple.FinalCutPro 0x005d550f ThreadFunction(void*) + 17
17 libSystem.B.dylib 0x00c5c7fd _pthread_start + 345
18 libSystem.B.dylib 0x00c5c682 thread_start + 34


***

10:06 am


Thread 42 Crashed:
0 libSystem.B.dylib 0x00c9c4ee __semwait_signal_nocancel + 10
1 libSystem.B.dylib 0x00c9c3d2 nanosleep$NOCANCEL$UNIX2003 + 166
2 libSystem.B.dylib 0x00d172a6 usleep$NOCANCEL$UNIX2003 + 61
3 libSystem.B.dylib 0x00d389c4 abort + 105
4 libstdc++.6.dylib 0x0114dfda __gnu_cxx::__verbose_terminate_handler() + 433
5 libstdc++.6.dylib 0x0114c17a __cxxabiv1::__terminate(void (*)()) + 10
6 libstdc++.6.dylib 0x0114c1ba __cxxabiv1::__unexpected(void (*)()) + 0
7 libstdc++.6.dylib 0x0114c2b8 __gxx_exception_cleanup(_Unwind_Reason_Code, _Unwind_Exception*) + 0
8 libstdc++.6.dylib 0x0114c658 operator new(unsigned long) + 101
9 libstdc++.6.dylib 0x0114c703 operator new[](unsigned long) + 17
10 com.apple.FinalCutPro 0x005d7200 QTMovieWriter::addVideoSample(void*, unsigned long) + 62
11 com.apple.FinalCutPro 0x005d5e04 MP2Dec_Output::WriteQTData(unsigned char*, EFrameType, int, unsigned long long, int, RecordDate, MtdTitleTimeCode, MtdTitleTimeCode, int) + 394
12 com.apple.FinalCutPro 0x005d611f MP2Dec_Output::HandleCallBack(OutputCallBackStruct_*, EOutputCallBackReason) + 497
13 com.apple.FinalCutPro 0x005d6149 ToOutputCallBackFunction(OutputCallBackStruct_*, EOutputCallBackReason) + 31
14 com.apple.FinalCutPro 0x005d5315 MP2Dec_ICodecEnc::HandleOutput(int) + 1127
15 com.apple.FinalCutPro 0x005d54e0 MP2Dec_ICodecEnc::ICodecEncThreadFunction() + 104
16 com.apple.FinalCutPro 0x005d550f ThreadFunction(void*) + 17
17 libSystem.B.dylib 0x00c5c7fd _pthread_start + 345
18 libSystem.B.dylib 0x00c5c682 thread_start + 34

[Robert Lane]

Welcome to DVinfo Dawn,

From what I can see in the reports the singular repetitive error line is "sleep" or "nosleep". This could be a hardware issue - have you checked your energy saver and screen-saver settings recently to make sure they're all set to NONE. As in never put HDD"s to sleep, no screen-savers etc? That's a first place to check.

Also, the software troubleshooting you've done is surface-level only. You should download and run all the cleaning and maintenance routines in Onyx (free app) and, get a copy of DiskWarrior to address the directory.

If you're still getting crashes on both machines using the same Canon camera to capture from, it could be that the camera's communication has become wonky - which does happen and will cause FCP to lose it's grip altogether. Try using a different camera if possible.

If it does end up being the camera I'd highly suggest that at some point you migrate your camera system over to either a Sony or JVC-based system. The main reason for this is because Canon has never taken a fully professional approach to it's camera systems, i.e. they've *never* made a tape-deck - ever - for consumer or pro-sumer camera tape formats.

With a Sony or JVC system you could offload the rigorous and head-life robbing rigors of capture onto an HDV-capable deck, of which there are dozens of used ones on the market that can be had for a song.

Again, try the deeper maintenance listed above, if that fails use a different camera for the capture process. If none of that works then it's time to get with a consultant in your area who can be in-person to suss out what can't be done over the internet.

Good luck.

[William Hohauser]

I second that it's probably the camera although it might be the recorded tape if the problem is happening with the same tape. I have had problems in the past with HDV tapes that just recorded strangely. You might find the combo of DVHSCap and ClipWrap (or the free MPEGStreamclip) helpful in a situation like this.

[Dawn Minenna]

Thank You for the help.

Each Mac Pro has it's own HV20 with it's own firewire cable. Each version of FCP on each machine is legally serialized and on a different operating system. The tapes that aren't capturing correctly do seem to be crashing while using the HQ Apple Pro Res capture setting.

My 1st question - has there been an update to that codec in the last 4 weeks or so? I could see this happening on one machine, but both?

My 2nd question - I stripe my tapes to put a timecode on them before going out to my weddings. I have striped them on the HV20's in HDV. However, I can't say that each time they are in the same mode. I might stripe some in pf24 and some in 60i. But HV20 only really shoots pf24 in a 60i package right? But, I've done this for 5 years. Why would this be making an issue now?

I will get the onyx and do that. If a capture can work okay using the LT version of APPLE ProRes does that change anyone's ideas??

Thank You - 4 jobs to capture in the next week, so I hope my wonderfully solid program finds a good therapist!

[Robert Lane]

Your situation is too unique for myself - and most likely anyone else on this forum - to suss out properly remotely. I'd highly suggest looking up someone in your area who can sit down and literally look at every possible setting both on the towers/software and cameras.

With regard to any updates potentially causing the problem, again you're the only one that can answer that question since nobody else knows the past and current software snapshot that lives on both your systems and, when the last time you did a Software Update was from Apple.

Did you recently do a software update - to any major component of either the OS or FCP - and then notice the wonky behavior? These are the things only someone on-site could look into and know for sure.

For the meantime my only suggestion for getting your footage off these tapes would be to change your capture settings into another format and see if that changes the outcome.

EDIT: Ditto what William H. just posted - try that as a work-around for now.

[William Hohauser]

HQ vs LT ProRes? Yes, that can be the issue. The size difference between the two codecs is enough that you might be over stressing your capture drives if they are close to full or not RAIDs.

Quite frankly, I don't see the need to create ProResHQ files from HDV. Everyone out there correct me if I'm wrong, but you'll gain nothing in quality but lose a lot of drive space. Standard ProRes is the highest you need.

[Robert Lane]

Correct, no need for HQ ProRes for this job type and is overkill - no benefit.

[Dawn Minenna]

Thanks guys. I reinstalled the capture codecs on both machines and I am using the Standard Pro Res now. WIth the HDV-APPle pro res capture setting. I purposely shot everything this weekend in straight 60i so that I could rule out anything to do with Frame rate on one machine vs play back on another.

I've just captured 3 straight hours with not a hiccup. Thank you!

I did as suggested and changed all the energy saver items to never while doing FCP work.

I haven't done the diskwarrior yet - There are several that look like disk warrior, some are free, some charge, I don't care if it's free or not, I just want to get the right one.

So far so good though.

Thank you for your help. Can I post that this has been answered somewhere?

-Dawn

[R Geoff Baker]

This doesn't address your issue, but you mentioned that you 'stripe' your tapes to lay down timecode. Note that what you (or anyone) does is ignored by the camera in any useful sense, and new timecode is recorded with every recording. Unfortunately, the presence of 'old' timecode can cause issues, as a frame or two gap between takes will leak this old timecode and can cause capture issues.

Striping was a narrowly necessary procedure back in the olden days to create an edit suite master that could have shots inserted without tampering with the timecode baseline -- it was a required step before starting an edit, and edit decks knew how to deal with a prestriped tape. Camcorders, on the other hand, never did & never needed to. Shooting always includes timecode -- with one minor detail. If you want to identify your tapes using the convention of hour as tape number, it is worthwhile to lay down bars and tone at the top of a tape with the hour you want to use. Sixty seconds is plenty, and conveniently the first few seconds of any tape are the most likely to have drop-outs; cue your camcorder to the last second or two of the 'stripe' and start your shooting from there -- the camcorder will pick up where the timecode left off and continue that hour as a starter.

But prestriping an entire tape is not required, doesn't lay down a stripe that the camcorder will use instead of a new timecode track and 'might' cause timecode confusions if the tape is ejected/reloaded later in the shoot.

Cheers,
GB

[Robert Lane]

Originally Posted by Dawn Minenna

I haven't done the diskwarrior yet - There are several that look like disk warrior, some are free, some charge, I don't care if it's free or not, I just want to get the right one.

So far so good though.

Thank you for your help. Can I post that this has been answered somewhere?

-Dawn

There is only one "DiskWarrior" and only it actually does the job of totally addressing the Mac OS directory in it's entirety - even on disks that won't mount:

Alsoft, Inc. Makers of DiskWarrior. The Disk Utility for Mac Disk Repair, Mac Directory Repair, Mac Disk Recovery and Mac Data Recovery

Unfortunately this forum doesn't have an "answered" button; this helps keep the info fresh and available rather than ignored by others with similar problems.