.SCC File Recovery
Hi Screenflow team,
Now I've been reading / searching for a while on this and have seen a few similar problems, but never a resolution, so I thought I'd try again.
Essentially I had a program crash whilst recording and have managed to find the .scc file in the OS temp.
Now the project was never saved (since I had to force quit Screenflow at the time) so I only have the .scc file.
Only problem is that when I open the .scc file there is no media on the timeline, just a blank project. This is very strange since the file is 154gb — a 40min recording.
I am using El Capitan and Screenflow 6.2
Are there any know fixes to 'unwrap' an .scc file? Surely the media must be there somewhere when the file is that size?
Any help would save my life.
If the file is corrupt, is there any service that repairs corrupted .scc files?
Unfortunately, no probably due to the file's proprietary nature.
please do fill out the previously posted support form since we may need to investigate a solution or at better prevention.
Simon I see lots of potential issues there.
As a general rule (not even specific to ScreenFlow) a drive, especially a system drive should never have less than 20% free space. The current version of ScreenFlow is 8.2.3. Always keep Check For Updates enabled in ScreenFlow Preferences unless you check frequently on your own. Updates include bug fixes. Missing a bug fix can result in you experiencing issues that we've already fixed. Apple updated Mojave to 10.14.6 and that has helped with some issues as well.
Justin Wanajrat I'd like to help but without technical information, I have no idea if your issue is related to the original poster. If the export is fine then it may not be at all related. Please provide information as if you wanted someone to reproduce the issue otherwise there may be a lot of back and forth questions.
I've also had corrupt/unusable .scc files a number of times - out of disk space, computer crash etc. Despite the hard work of the developers "to prevent any problems" described in this thread, problems do and will happen. Corrupt files do happen and corrupt .scc files are unusable with no fix available of any kind because the file format is proprietary, undocumented and the company provides no recovery tools or solutions of any kind. I just went back to a corrupt 38 GB .scc file from Nov 2020 trying again to salvage it somehow. It's hopeless - time to delete it.
Obvious requirement: the ScreenFlow temp file format should record progressively in such a way that any interruption does not corrupt the entire file irretrievably. Whatever is recorded up to the point of the interruption should be available and usable. There's no good excuse of any kind for interruptions to corrupt the entire session. The file format needs to be reliable and resilient to interruptions and corruptions.
Without a reliable file format, cannot trust this tool with important content.
Are you guys kidding? This topic is opened and relevant for >4 years, and still the problem is not solved! I had my disc space run out and 40 GB scc-file is not opening. Why shall we pay for a product that have such issues? I'd better pirate your next version and never pay pay again until it gets fixed!
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).
* 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?
Eduard Rozenberg said:
I'm seeing more frequent crashes recently after updating to Big Sur which may not be related to disk space or ScreenFlow.
If you're seeing a ScreenFlow crash (not a hang) we'd like to look at the crash logs. When it happens can you post here exactly what you were doing and we can give you the steps to retrieve the crash log.
ScreenFlow does have a recovery feature but the results may vary depending on the cause.
If the macOS itself is crashing that would be different.
Eduard Rozenberg said:
I'm having system, not app, crashes. The entire Mac shuts down unpredictably.
Usually those are caused by either hardware or kernal extension issues. ScreenFlow hasn't used kernal extensions since version 7.
Eduard Rozenberg said:
my experience so far has been in most cases, when my Mac crashes during a recording, it is impossible to recover anything.
That may well be the case if the entire Mac is crashing.
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