.SCC File Recovery

I'm back because a week ago I lost another (1 hr+) screen+audio recording and I have even more "valuable learnings" to share. I obviously haven't learned enough yet because it keeps happening.

iMac 27 5k, had over 200GB free on internal drive. I thought it was enough. Nope. After 1 hr+, the computer crashed, and after restart the scc file was only about 20GB - not nearly enough to represent 1+ hour of raw video. And of course it didn't open and was corrupt and the session completely lost (and un-redoable because you can't redo a live online call).

"Valuable learnings":

* ScreenFlow uses much more disk space during the recording process than the space used by the final (native, unexported) ScreenFlow file after a successful (uninterrupted) recording. If you're recording 1hr, 2hrs or more, need to have many hundreds of GB's free to be safe.

* Since almost nobody has many hundreds of GB's free on their internal drive, you need to use an external drive with many of hundreds of GB's free, and set the scratch space setting to that external drive in ScreenFlow advanced prefs. And gd help you if for any reason the cable/connection to the external drive comes loose during the recording process.

* Use a tool such as iStat Menus to monitor free disk space (specifically on the disk you set as scratch disk for ScreenFlow) and pop up a warning when the disk free goes below say 50 GB.

* Record the audio in addition in a separate tool (using for ex Audio Hijack and make sure to get the audio routing correct) so that if ScreenFlow predictably loses the session, maybe you'll at least still have the audio for however much that helps.

* And finally unless you're comfortable losing a long, unreplicatable, valuable session, maybe don't use ScreenFlow for your long recording needs. Use it only to record 1 minute clips of your mouse pointer moving around the screen. I've personally had fantastic luck recording short clips of software behaving badly for submission to many software authors.

ScreenFlow's reply on this forum and elsewhere has always been sorry, the scc is a proprietary format, it's a hard problem, we try hard. Yes d, reliably recording media in a reliable way is a hard problem, and that's why people buy software written by other people to solve this hard problem. Losing people's valuable sessions for many years running is "hugely uncool" to say the tiny least.

ScreenFlow should (f obviously) be:

* Monitoring free disk space on the disk where it's recording and warning the user when a threshold is reached. Yes that might put a popup into the recording itself, but that's 10,000% better than blindly filling up disk space until the Mac is forced to crash for lack of disk space and lose the entire session.

* Providing an optional feature to store duplicate in-progress recordings on two separate drives in parallel for users who really value redundancy and reliability. The way most pro cameras can do now.

* Provide info and feedback about expected disk use ("at your current recording settings and screen resolution ScreenFlow will use approx 4GB per minute") before starting the recording. Instead of blindly and silently filling up the disk and wishing the user "good luck with that".

* Never under any circumstance blindly fill up the scratch disk, forcing the Mac to crash, and losing the entire session in an entirely predictable, well-known, well-documented and rightly wailed about by many users known and unknown for many years already.

* Never under any circumstances corrupt and lose the temporary session file if the disk fills causing the Mac to crash. You filled up the disk and crashed the Mac with that session file. How about at least keeping that session file around so that the user can recover the recording up to the point of the disk full? You ScreenFlow filed up the entire disk and crashed the Mac with that session file, how about at least keeping it, in an uncorrupted state?

CraigS  stopping my Mac from crashing would definitely be great. Macs are (maybe?) more stable than Windows, but compared to most Linux/Unix servers still garbage. I've done a bunch of things and if still no luck I'll have to ride the funtrain to its final destination and do a complete OS reinstall and configuration from scratch with no Time Machine restore.

* Apple Diagnostics: OK (rebooted and hold 'd' to get to diagnostics)

* MemTest: OK (rebooted to USB stick with Passmark MemTest Pro v9, overnight test - 4 passes)

* Removed old Telestream kext (/Library/Extensions/TelestreamAudio.kext) - Telestream v8, v9 never cleaned this out, sure would be nice if they did! Removal process: ScreenFlow 9 Prefs -> Advanced -> Uninstall Sound Driver (removes the kext), then Install Sound Driver (does not install any new kext).

* Removed all other 3rd party kexts from /Library/Extensions (Luna Display - Astropad stuff and DriveDx SMARTSAT* stuff), leaving behind only Apple's own default items (AppleMobileDevice.kext, HighPointIOP.kext, HighPointRR.kext, SoftRAID.kext)

I'm "good" for now, no more to say, other than I hope ScreenFlow will work on being able to recover data in all situations including out of disk space and hard Mac crashes - that's not an optional feature or a "nice to have" when recording important irreplaceable events.

ScreenFlow 10 is horrible, I never had these scc corruption issues with ScreenFlow 5 to version 9. I have tried ScreenFlow 10 on 3 different computers and 50% of the time I get corruption of the *.scc file on all 3 of them. I have reverted back to ScreenFlow 9 and it works great again. I submitted a request for a refund on SF10 after losing many recordings that I will never be able to replace. Also, all 3 computers have over 200GB of disk space so that isn't the issue, I run Disk Utility on them to keep them running smooth as well and run the latest version of MacOS Big Sir, v11.6