FCP 7.0.3 frequent crashes

I haven't extensively tested smoothcam in FCP 7. In fact, I don't use smoothcam that much, unless I have to.



www.strypesinpost.com

Oh, sorry, my bad, it's the EOSs that you can transcode during import. You could media manage when things started getting wonky and make everything you had so far into Prores. Of course the files are a lot bigger and it's a pain to do this. Lets hope it does get easier!

I haven't seen any problem with smoothcam yet, but someone did apply a whole bunch of them on a project I was working on just as I was leaving the other day, so when I go back to that job I'll see how it went.

Thanks...jw

Have you thought about trying to edit some of your pieces with FCP 6 (i.e., install FCP6/FCS2 on a new drive with your current setup)?

I really doubt that the issue is exclusively related to HDV or XDCAM EX footage. I have been editing both formats extensively in the past few years and haven't had significant problems. You even mentioned that this behavior has occurred since FCP 7 came out (and no "big" problems prior). Luckily, I haven't run into any issues in natively editing HDV with FCP 7 (I haven't edited any XDCAM EX footage with FCP 7 yet). I tend to use ProRes sequences.

It's tough to know what the real cause of the issue is... it could be FCP, QuickTime, graphics drivers, or some interaction with the OS (or many of these in combination, or other things)...

I hope you can further identify a more specific cause (and report anything relevant to Apple)...


-Dave

My problem is ours is a rather lean, results/product driven operation so I don't have or at least perceive I don't have the time to experiment. This last hour is going smoothly and then I need to begin writing and producing a very complicated series that is beyond my current level of expertise/knowledge so I'll be focusing all my "OJT" on this new project.

Once we start editing I'll have a better handle on what I can experiment with.

Thanks again for your insight and help...Jw

jwatt Wrote:
-------------------------------------------------------
> My problem is ours is a rather lean,
> results/product driven operation so I don't have
> or at least perceive I don't have the time to
> experiment.

Most of us are in the same boat...


It's no fun spending time trying to troubleshoot issues...

I would be very frustrated if my system crashed as often as you and Mike have mentioned...

Luckily, I believe I have only had FCP crash on me a couple times in as many years... hope that continues...

Let us know if you discover anything new... thanks.


-Dave

Hi,

Just came across this searching on google. We are having the exact same issue here, XDCAM HD & EX projects crashing often when scrubbing the timeline. Crash logs look just like what I've seen here. Only thing we changed before this started was the addition of Boris. So I've been thinking that's what it is but now I'm not so sure. We are on FCP 7.0.3. as well.

This is driving my crazy!! I've got editors who need to work with out crashing.. Apple has been helping us but so far we haven't found the cause for sure.

I am under the impression that FCP crashes easily when FCP's resources are over taxed. Crashing on complex/long XDCAM EX or XDCAM HD sequences is not a new complaint. You will probably encounter less crashes by transcoding to ProRes for the edit.



www.strypesinpost.com

Ben: thanks for the detailed questions.

Ben King Wrote:
>Guys can you test the speed of your HDDs?
>Use the AJA system test: [www.aja.com]
>Or if you have it Mike - use the BM Speed Disk Test.


HDD's. Only the first internal is used much with FCP. It has apps on it.
All media, projects and renders are on the externals.

BM Speed test, R/W MB/s , and R/W 8 bit 422 HDTV 1080:

4 internals (apps, appsbu, data, databu)

98/92, 24/24
96/105 24/26
69/82, 17/20
74/81 18/20

3 Externals FW 800 Gtech Gdrives

78/63 19/16
79/14 20/3
47/17 11/4

I don't have the SATA raid from my last project to analyze.
Did analyze one stray SATA drive not used in project just to compare: 110/107, 27/27
I was crashing just as much with the sata raid, though, as I was with this FW project.


-------------------------------------------------------
> Just to get a few things out of the way - do you
> have the crash reports you can upload somewhere?
> Unless you've tested the crashes already with
> Crash Tester in the FCS Maintenance Pack? What did
> it say?


FCP MP found 20 crash reports since November. 11 of them were labeled MPEG Media, 5 Effects Rendering, 2 User Interface , 1 Open/Save Dialog, and 1 Digi Effects Plugin. (The last came when I couldn't get the timeline to crash and turned on those filters to nudge it along; guess it worked.)

Project has 14 audio , 8 video tracks, but no Motion. It does have quite a mix of codecs and framerates: Pro Res 422 HQ 2398, PRO Res 422 2997, DVCPRO HD 2997, XDCAM EX 2398, XDCAM HD 2398, , Photo jpeg 2398

All of the FCPMP crash analyzers have a red warning at the top saying that the cause was because FCP was overloaded, either from being too complex, using Motion (I don't have any), or MPEG media.
>
> Also - have you tested for corrupt fonts? Open
> Fontbook and validate all your fonts. Remove any
> once with major issues and disable those with
> minor.

disable 38 minor problem fonts prior to crash tests
>
> Do you both have Motion projects on the timeline?
> Scrub back and forth over them lots if you do to
> make sure its not them causing the issue.

No Motion
>
> Mike - have you tried using an actual ProRes
> timeline instead of an XDCAM EX (with render to
> PR) like JW do you have the same issue?

I have not; just an ex.
>
> JW are you running two hi-res monitors @1920x1200
> off the 8800 and using GPU accelerated
> FX/filters?
>
> ...likewise Mike on the 4870 with two Planar
> Monitors?

The Planars are: 20" at 1600x1200 and 26" at 1920x1200
>
> What are your user prefs, Memory & Cache, et al in
> System settings?

Minimum allowable free space 2047 mb; Mem Usage App 100% 2560, Still cache 10% 241; thumbnail cache disk 8192k, ram 512k
>
> I assume you both have the latest drivers and
> firmware for all your gear?

can't find any update for the 4870
>
> Do you have any third party CODECs installed or
> Perian?

had an old shortcut for perian, but no program
>
> Is FCP just quitting (no report) or is it actually
> crashing?

actual reports
>
> Can you replicate the crash by going over the same
> part of the sequence(s) or doing the same
> function(s) each time?

Of course, now that i've taken the fcp car to the lafcpug mechanics, i can't make it do it--strangely, the beach ball gets started, but then recovers--something it NEVER does. It always goes to a crash once the beach ball starts, but it has now recovered three times from the beachball.

Timeline also feels "smooth" when I scrub, instead of the "sticky" which I feel whenever I know it's going to crash.

I should also mention that I use a Kensington Turbo Mouse Pro, with a trackball to move around the timeline.

Discouraging to think that it's just the use of ex footage which in general causes the problem--I would think Apple has had more than enuf time to deal with this.

Mike,

I answered Ben's questions in an earlier post. I'm about 40 minutes into my third, 1 hour show in this series cutting on a ProRes timeline and have had pretty decent luck, as in a crash or two a day.

This is an FCP7 issue. I edited about 8, 1 hour shows on 6. whatever right before 7 came out and had no problems. Also Smoothcam worked brilliantly. Now in 7 it's worthless.

FYI I'm not mixing formats...all XDCAM EX HQ, 35mbs VBR.

thx...jw

Thanks, jw, I guess 18 months isn't long enuf to fix it.

I think all the engineers are too busy with IOS. We're a very, very small piece of moisture in the bucket compared to that market.

The problem is I have no desire to switch systems at this point and for the most part it's a great program, it would just be nice for someone to pay attention to fixing a few of these issues.

Wondering if someone would comment on those drive speeds--they seem very different from what jw said his were, and one of the externals looks like it might have a problem. (not that this influences the analyses of the crashes, as with SATA drives the crashes were happening just as often)

My drives are in a fiber channel Xserve raid so they should be quite fast.

Hey guys

Sorry have been busy on an edit.

Regarding your disk speeds:

3 Externals FW 800 G-Tech G-Drives
Read / Write
78MBps / 63MBps
79MBps / 14MBps
47MBps / 17MBps

The read speed for the first two are fine but the write speeds are very poor for the second and the third drive I suspect is well over half-full - even my 5400 LaCie Rugged drives do at least 60/60MBps so you have an issue right there but I've been testing pushing single speed HDDs over the limits and I get spinning beach-ball but no crashes. Regardless; you really should be using a RAID array that is much much faster. It's something no edit suite should be without!

However after pushing my system to silly numbers of concurrent PiP XDCAM EX and semi-transparent layers on an XDCAM EX timeline I got it to crash with the same error but only when I reached the Video memory limit and/or stressed the system with 17+ layers of XDCAM EX running simultaneously with motion transformations and transparency. Even then it might not always crash in the same place.

For comparison this system is a 2008 MacPro 8core 3GHz with 32GB RAM and Nvidia GTX285 1GB and 700MBps SAS attached RAID 6 and 800MBps attached SAS RAID 5.

The reason I asked about your GFX card is that both of you have only 512MB V-RAM and you will find that large screen resolutions and media playback stresses your GPU. Couple this with the fact you both run two monitors that means you further push it - this often cause your system to feel sluggish and although it might not contribute to a crash you might find getting a faster GPU with larger memory (1GB or more) helps considerably in the general feel of your system. I've been quite shocked at just how much V-RAM different apps and windows take up!

Certainly if you are running 8 video tracks including FX and lots of audio tracks you are pushing your system if you don't have a damn good GPU and fast RAID storage.

So there are a number of things going on here. Mike definitely needs faster media storage, JW needs to figure out what other factors are affecting the system (plugins and/or GPU).

JW - did you test the system running only on one monitor to see if it was more stable?

Like-wise Mike you could try the same.

If it turns out to be a GPU issue then I suggests upgrading to a 1GB+ V-RAM model such as the new ATI cards or if you can afford it - one of the new 2GB Nvidia Quadro 4000s.

I would love to ask the FCP development team if stressing the GPU and especially it's Video memory really does have this effect, but so far its the only consistent test that I have found resembles your issues.

I'll run some more tests with ProRes and see if I can get the same problems and feedback. I certainly would like to know what specific factors contribute to the "MPEG" issue other than just asking too much of it.

Of course if you render down the layers of video before you playback then you shouldn't get any issues as it will essentially be 1 stream.

If you guys want to test what your V-RAM is doing - then you'll need to run the OpenGL Driver Monitor app which you'll need to get from developer tools.



For instant answers to more than one hundred common FCP questions, check out the LAFCPUG FAQ Wiki here : [www.lafcpug.org]

Quote
Ben King
If you guys want to test what your V-RAM is doing - then you'll need to run the OpenGL Driver Monitor app which you'll need to get from developer tools.

Thanks for mentioning that utility. I have used atMonitor, as well.

Quote
Mike Chandler
Project has 14 audio , 8 video tracks, but no Motion. It does have quite a mix of codecs and framerates: Pro Res 422 HQ 2398, PRO Res 422 2997, DVCPRO HD 2997, XDCAM EX 2398, XDCAM HD 2398, , Photo jpeg 2398

Are these different frame rates used in a given sequence? Mixing HD and SD sizes and codecs is one thing (which I always try to avoid), but mixing different frame rates in a single sequence/timeline may be an important contributing factor leading to your crashes (if, in fact, you are mixing frame rates ).


-Dave

I have to say that I've also done a lot of mixing frame-rates in offline - unrendered - just until I'm happy to "Nattress" them (shameless plug there G ) or run them through Compressor et al. With no crashes until pushed to the limits. So although it could be a contributing factor to overloading the processors I wouldn't consider it THE single cause.

My feeling is that both systems are not optimised, both are using older GPUs with two monitors sharing 512MB VRAM and slow media storage and probably a few filters that are not fully compatible with FCP7 and/or Snow Leopard. Its like having a real beast but then tying it up and not feeding it properly yet still expect it to hunt like it does in the wild! If you get my analogy.

It would be extremely helpful if anyone reading this thread has 10 to 15 minutes to try and crash their FCP whilst monitoring their GPU and CPU load to see if we can correlate saturation of video memory with these issues as it will be a good benchmark when we try and ascertain why certain setups crash more often when there is no obvious cause except extreme workflows.

Yes 8 layers of video in mixed formats and framerates and codecs is extreme Mike!

Quote

Thanks for mentioning that utility. I have used atMonitor, as well.

Good call D - link for that is: [www.atpurpose.com]

So I have managed to crash my system at over 95% of my Video Memory Capacity whilst the GPU is at 13% and all eight of my Processors are at 45%.

This was achieved by 21 layers of XDCAM EX 1080 29.97 all rotated and transformed in scale so that all of them were showing on screen in some way - no filters. If you have less than a GTX285/Quadro 4800 then I would expect you to crash earlier.

Anyone else want to share their findings?



For instant answers to more than one hundred common FCP questions, check out the LAFCPUG FAQ Wiki here : [www.lafcpug.org]

Quote
Ben King
I have to say that I've also done a lot of mixing frame-rates in offline - unrendered - just until I'm happy to "Nattress" them (shameless plug there G ) or run them through Compressor et al. With no crashes until pushed to the limits. So although it could be a contributing factor to overloading the processors I wouldn't consider it THE single cause.

Good points. Mixing frame rates doesn't seem to be the cause, or even the primary cause (as I mentioned). However, it is real tough to know exactly what is causing this issue. All parts of the computer are being heavily taxed (RAM, VRAM, GPU, disk drives, OS... it doesn't seem that CPU is a limiting factor, except on lower-end machines). FCP doesn't seem to utilize all CPUs or virtual cores when rendering.

It would be nice if Apple would make FCP a bit (or a lot) more robust and maybe provide some warnings about its limits, similar to RT and drop frame warnings (which may be difficult to implement).

It may well be that there are some bugs in the various graphics drivers, FCP itself, QuickTime, or the OS that are contributing to this issue.

Quote
Ben King
My feeling is that both systems are not optimised, both are using older GPUs with two monitors sharing 512MB VRAM and slow media storage and probably a few filters that are not fully compatible with FCP7 and/or Snow Leopard.

Diagnosing this stuff is tough. Mike is still using Leopard. JW is using Snow Leopard.

Quote
Ben King
It would be extremely helpful if anyone reading this thread has 10 to 15 minutes to try and crash their FCP whilst monitoring their GPU and CPU load to see if we can correlate saturation of video memory with these issues as it will be a good benchmark when we try and ascertain why certain setups crash more often when there is no obvious cause except extreme workflows.

It would be nice if we could create a test project to use for testing (so that anyone who does some testing is using at least one thing in common). We don't know if RT settings, or other FCP preferences are part of the issue (render settings, memory settings, motion quality, etc.).

The atMonitor utility application can log certain parameters, so that might be helpful for tracking RAM, VRAM, GPU, CPU, and disk usage during testing. Those logs may help Apple figure out what's happening.

Quote
Ben King
So I have managed to crash my system at over 95% of my Video Memory Capacity whilst the GPU is at 13% and all eight of my Processors are at 45%.

This was achieved by 21 layers of XDCAM EX 1080
29.97 all rotated and transformed in scale so that all of them were showing on screen in some way - no filters. If you have less than a GTX285/Quadro 4800 then I would expect you to crash earlier.

With that many layers of video, I wonder if your disk I/O was a factor. I suspect that for many people disk speeds may be more of a limiting factor than VRAM, CPU, etc., and make it difficult to push some/all of those parameters into the "red" (or not???).

It would probably be helpful to report various FCP sequence, RT, and preference settings with any report...

Ben, thanks for helping to push this forward...


-Dave

Quote

With that many layers of video, I wonder if your disk I/O was a factor

Hell no; my disks run at ~650 to 850MBps and 21 layers of XDCAM EX Video @ ~5MBps is nothing

If the processing could handle it the RAIDs I have would dish out more than enough for 130 streams of XDCAM EX.

- I would expect the CPUs to have been more taxed though - certainly it was dropping frames but trying its best to chug through. But with more than 50% CPU free I was a bit annoyed!

But then FCP is only 32Bit and not really MP or GPU optimised. (Fingers crossed for the next version hey?).



I've just tested the same files off of the LaCie Rugged that does 60MBps R/W via FW800 and the timeline is simply more sluggish and prone to beach-balling but doesn't crash until the same over stressing of the GPU V-RAM.


I am starting to think it really might be a GPU/Driver issue you know!



For instant answers to more than one hundred common FCP questions, check out the LAFCPUG FAQ Wiki here : [www.lafcpug.org]

Quote
Ben King
I've just tested the same files off of the LaCie Rugged that does 60MBps R/W via FW800 and the timeline is simply more sluggish and prone to beach-balling but doesn't crash until the same over stressing of the GPU V-RAM.

I am starting to think it really might be a GPU/Driver issue you know!

Thanks for the additional test results.

I haven't noticed FCP using more that about 45% of my CPUs, as well.

Graphics card drivers have always been the Achilles' heel of Macs in recent years. Or, some part of the "graphics subsystem" in FCP may be buggy in FCP 7.

I would think that if someone is doing "lots" of tracks of video that there may be a better tool to use than FCP (i.e., do the work elsewhere and import the "composited" clips into FCP). ???

Quote
Ben King
Hell no; my disks run at ~650 to 850MBps and 21 layers of XDCAM EX Video @ ~5MBps is nothing

I wonder, if in practical or real-world usage, if the number of simultaneous streams is more taxing on a disk array than the data rate (latency, total I/O bandwidth in terms of separate streams, etc.)? In other words, is it possible that many smaller concurrent disk I/O "streams" can reach some sort of "saturation point" or "bandwidth limit" separate from the maximum data rate of a disk array?

-----

In terms of helping JW and Mike...

If the crashes are so frequent that they impede productivity and cause lots of frustration (and potential data corruption?), it may be a viable workaround to temporarily reinstall FCP 6. I would get rather frustrated if my system crashed every day, if even only once...



-Dave

I couldn't get developer tools to install (error: run tools preinstall script) , so I used atMonitor instead. Got the timeline to crash (Crash Analyzer: MPEG MEdia) and stats at the time of the crash were:
CPU 6-9%,
GPU 0%
VRAM 55%


While scrubbing through the timeline beforehand to make the crash, VRAM was about 63-69% and got as high as 71%.

Apple Activity monitor showed 1.23 GB for FCP, CPU 1.1-1.3, Threads 71-72

Mike Chandler Wrote:
-------------------------------------------------------
> I couldn't get developer tools to install (error:
> run tools preinstall script) , so I used atMonitor
> instead. Got the timeline to crash (Crash
> Analyzer: MPEG MEdia) and stats at the time of the
> crash were:
> CPU 6-9%,
> GPU 0%
> VRAM 55%
>
>
> While scrubbing through the timeline beforehand to
> make the crash, VRAM was about 63-69% and got as
> high as 71%.
>
> Apple Activity monitor showed 1.23 GB for FCP,
> CPU 1.1-1.3, Threads 71-72

Mike, thanks for the report.

Besides disk I/O and the graphics card ideas/explanations, I wonder if just having to access so many different clips from the disk drive(s), along with having to decode and process them for playback is a factor (which may be consistent with the number of threads in-use in some of the crash reports, and as mentioned in Jon's crash analyzer and by Jon himself).


-Dave

P.S. - It might be good to report as much of this info as possible to Apple...

Mike Chandler Wrote:
-------------------------------------------------------
> I couldn't get developer tools to install (error:
> run tools preinstall script)

If you tried to install the current developer tools, it probably won't work with Leopard (Snow Leopard is required). You should be able to install the tools from the Leopard OS installer DVD, or possibly find an older version on-line. Someone else may be able to confirm that (I can't right now, as my Leopard-based system is off --- in the middle of rearranging my office).


-Dave

Dave--it was off the Leopard disk. The other two Developer tools packages would load, but not "tools" itself.

Is it time for me to switch to Snow Leopard? Any advantages?

Does that 55-70% mean that it's probably not the video card?

700MBps SAS attached RAID 6 and 800MBps attached SAS RAID 5.

Ben--What raid products are these?

Mike Chandler Wrote:
-------------------------------------------------------
> Dave--it was off the Leopard disk. The other two
> Developer tools packages would load, but not
> "tools" itself.

Okay, sorry about that. You could always try to download Pacifist and use it to try to install the developer tools.


> Is it time for me to switch to Snow Leopard? Any
> advantages?

There are some known issues with Snow Leopard and Quartz Composer based FXPlugs used in Final Cut Studio apps, as well as a few other things. I am running a system very much like yours and still using Leopard. My "test" system is running Snow Leopard. It seems like there aren't many remaining issues that would prevent me from upgrading now... just have to plan the move...

With all of your crashes, I would consider getting a new hard drive, putting Leopard or Snow Leopard on it, along with FCS2 (FCP 6.x) and using that for now... Or, maybe try to work with fewer complexities in your projects (fewer tracks, or fewer mixed frame rates, or...). The large number of crashes you've experienced is probably not typical (no wonder you contemplated moving to another app).


> Does that 55-70% mean that it's probably not the
> video card?

I have no idea... sorry.

Your ATI Radeon 4870 is a pretty good card. Moving to a 5770 or a 5870 would require you to upgrade to Snow Leopard. Depending on your time and budget, you could always upgrade to a new graphics card (in your case, I'd go with the 5870 rather than the 5770 --- of course, one of the higher-end cards may work even better). Let's see what Ben, or anyone else, thinks...

As I mentioned before (Ben, too), there are many possible causes for your crashes... since FCP heavily taxes most of every part of the computer HW and SW, it could be one, or more, things...


-Dave

I use one 1680x from Areca with a 16x1TB 16TB RAID 6 (14TB formatted) although I just installed a 1880x in a clients suite in London and it performs better.

The other card is a Highpoint 3522 with 8x1TB 8TB RAID 5 (7TB formatted).

Both are connected via SAS to a Promise JBOD/RAID Chassis.

There are 100s of options but I've found the Areca cards to be the most reliable overall.

Both of these I built myself. None of which is rocket science but you do need to throughly test all your components if you do this. I wrote a small article on RAID in the SuperMag which is still available free here: [www.supermeet.com]

Quote

I wonder, if in practical or real-world usage, if the number of simultaneous streams is more taxing on a disk array than the data rate (latency, total I/O bandwidth in terms of separate streams, etc.)

Each card has 2 external SAS ports, each supplying 4 x 3Gb/sec SAS channels (4x 300MBps = 1200MBps) so total bandwidth is not an issue. Masses of smaller I/O calls might have an issue but I also tested the same project on the single FW800 LaCie Rugged which crashed at the same GPU load as with the RAID based project - the only difference was the Rugged was sluggish as hell and the RAID was quick as Jack Flash.

So this leads me to the conclusion that is not down to the Media Storage speed but rather the complexity of the MPEG footage as Jon's Crash Analyser states.

So, rather than simply being a CPU issue because my system is similar in CPU Horsepower but clearly is massively more capable than either of these having issues, and, if not a software issue or hardware defect then by simple deduction my dear Watson... I surmise that the GPU must have a major impact on performance and how much you can handle before FCP goes by-by.

Hopefully I'm right and then its something to bear in mind when buying an FCP Edit Suite. If its just a big coincidence then we're back to stabbing wildly in the dark and pointing fingers at this and that.

Quote

Does that 55-70% mean that it's probably not the video card?

Remember that your card is also mush less powerful than mine (sorry that sounds a bit locker-room) and has half the memory so overloading might occur in a much quicker timeframe. For instance I can get my VRAM usage to jump by well over 100MB simply by adding a GPU enabled filter - on a 1GB cards thats nothing - but on a a 256MB or 512MB card thats a huge percentage.

Try doing the same thing again but with the sampling interval set to 0.5 seconds so you get a better indication of what level it jumps to before a crash.

Also try (as I did) adding a track at a time with different footage and/or transformations to try to increase the GPU load gradually and see if past a certain % it goes cuckoo.

You might also want to try one monitor connected rather than two - I have 1GB of VRAM so it takes a lot even on a 2560x1600 screen to fill it up. On yours you have the VRAM divided between the two monitors so I'm guessing you'll be better trying 512MB dedicated to one screen for the tests.


Its by no means guaranteed so this is why I'd like more people to test it as I'm really not convinced that its down to CPU and not from slow storage (from my experience) like it used to be. Slow storage only ever seemed to hang the system or app but never actually crash the app unlike corrupt data or faulty soft/hard ware. Other people's experience will vary but I've got a fair few years on FCP from 1999 with all manner of systems and this has been the case for me.

Do you have the Unlimited RT Playback set to ignore dropped frames and to dynamically adjust frame-rate and quality? If not try it.

Quote

Is it time for me to switch to Snow Leopard? Any advantages?

Personally I've been on Snow Leopard since it was released - the downside was that some Apps and some drivers weren't updated or ready but the majority are now patched/fixed/updated so I see no reason for people to hang back. I prefer Mac OSX SL to Leopard - especially on the intel macs it is just that bit quicker.

Right now in the middle of your project however - it is highly discouraged to update your system.

Personally though I do - however I always make a full System Clone (on a separate new HDD) and update that so that I always have the old one if things go wrong.



For instant answers to more than one hundred common FCP questions, check out the LAFCPUG FAQ Wiki here : [www.lafcpug.org]

Quote

Your ATI Radeon 4870 is a pretty good card. Moving to a 5770 or a 5870 would require you to upgrade to Snow Leopard.

Dave is right it is a pretty good card however having had an 512MB Nvidia 8800GT and now the 1GB GTX285 I'd highly recommend going for the most bang for your buck and that currently is the new Fermi based Nvidia 4000 for Mac with 2GB [www.nvidia.com]

But thats just a guess until the guys over at [www.barefeats.com] do a thorough test of it - especially as it's double the cost of the 1GB ATI 5870. I think they should be getting their 4000s soon (or I hope are in the middle of testing) I for one would like to know as I'd like to upgrade mine if it is that much better.

Re. The ATi 5870 - according to some sources you should be careful connecting it to certain monitors via the Display port with third-party cables as I've read that it has sleep/wake issues. Will look up the article(s) later if I get time.



For instant answers to more than one hundred common FCP questions, check out the LAFCPUG FAQ Wiki here : [www.lafcpug.org]

Quote
Ben King
Its by no means guaranteed so this is why I'd like more people to test it as I'm really not convinced that its down to CPU and not from slow storage (from my experience) like it used to be. Slow storage only ever seemed to hang the system or app but never actually crash the app unlike corrupt data or faulty soft/hard ware.

I went back and looked at the first snippet of the crash log that JW posted. There are a lot of function calls that seem to involve reading, decoding, filtering, etc. The number of threads is interesting, as well (Jon mentions that fact specifically). So, I would offer a suggestion that anyone testing her/his system try to monitor the number of active threads when the crashes occur (some limit may be exceeded, causing the crashes).

On my Snow Leopard machine, atMonitor shows a Utilities menu with a Launch submenu, containing links to various tools that are installed with the developer tools (I believe). A couple of the apps, like Instruments, can track things associated with specific processes/applications. These tools might prove useful when testing FCP... Ben, care to do your crash testing with some of these other tools running?


Back to "real work"...


-Dave

I'll definitely be up to testing things a little more nearer Xmas but I too have 3 onlines to get finished before next week so won't be doing much deliberate crashing!

Will poke Jon Chappell a bit later with the Developer Cattle Prod App and see if he can come up with a more satisfying reason for overload than:

"its MPEG Jim... but not as we know it!"



For instant answers to more than one hundred common FCP questions, check out the LAFCPUG FAQ Wiki here : [www.lafcpug.org]