Hey Everyone,
Kalle from Berlin here - I’ve started out on Flint in 1996 but for some reason, I’ve never come across this forum! Weird, as I’m a huge Logik Matchbox fan … but yeah. Living a bit too much in my bubble it seems! I hope I’m welcome nonetheless and that this is the right category for my question
Sooo I’m using Flame 2020.3.1 on my iMacPro for years and yesterday, I got a new warning I’d never seen before: “The critical Stone+Wire database server is offline”, as described here:
Thing is though, I don’t get the “Rebuild” option so far, so hopefully, not all is lost (yet). When the message appears, I can press “Restart” and everything works somewhat normally. What’s weird though is that my RAID (a Pegasus 6-bay) is constantly accessed. Even after closing Flame (!) the sw_dbd process goes wild and hogs 70% of CPU on average. It keeps ging through all the folders of my Framestore, at least the folders called /.mirror/ and it does so in an endless cyle, going from folder 0 up to 56, rinse and repeat.
When I start Flame, it also says it hasn’t been able to run vic for 3 days. when I try to run vic manually, it stops with the error “MISSING_COLOUR_TRANSFORM requested from server ‘Media I/O’”. So I’m guessing the root of the problem is that I’m currently doing a project in ACES and tried to create a new viewing rule a couple days ago. Maybe that messed it all up.
Seems the Flame documentation suggests uninstalling and re-installing Flame in case something is wrong with colour management. Supposedly, all projects, users etc will be retained in the process. Has anyone done this recently and can confirm it works? Would be a bit bad otherwise
Any other tips are of course also more than welcome. I’m really worried continuing with my work while the sw_dbd shreds my HDD RAID in the background, that can’t be good
Digging around more on this, I’ve come to think that several factors are at work here, some of which might even be normal
So if someone wants to do me a favor, could you have a look at the Terminal shell and run the command “top” to see the top processes. Would be interesting to know if sw_dbd is also hogging ~70% CPU with you at all times basically.
Then, run the command “sudo fs_usage |grep [DRIVE NAME]”. Instead of [Drive Name] put the name of your RAID volume (in my case, it’s “Pegasus2” for example), and you will be asked to enter your Mac’s admin password. Then you willl see if if your machine also accessing all /.mirror/ folders in your framestore in an endless cycle.
(Note, both these Terminal process can be stopped by pressing CTRL+C or closing the window)
If all this stuff happens with you, too, at least I know that this is normal and my trusty Pegasus is not on the verge of breaking down. In that case, I’d only have to figure out how to get vic to run again
Thank you! I already received a reply from them, apparently it’s possible that the Stone+Wire manager is already trying to rebuild a corrupted database, but I haven’t given it enought time
That’s a bit weird as my first hunch was that it’s some kind of indexing thing that is going on and I kept it running for at least 45 minutes. But the support was speaking of 1-2 hours, so I’ll try that first
Hi Kalle. As an old East-Berlin guy from the LSD-Viertel, let me give you the following recommendation. I’ld suspect all the processes like “sw_serverd” within Prozesses of Stone and Wire have been added to the security panel already for fully system access?
On which macOS is the iMac Pro running? When we had issues with Backburner, we uninstalled and re-installed Flame and all was fine. Comparing to the trouble shooting we did before which took hours without a solution, we now considering a reinstall sooner even if some customised requirements come on top of a standard install. Since we din’t changed the IP anymore of the Flame Computer all is running stable.
Hey Waldi, in the block where I grew up in Schöneberg, there also was a building called LSD but it was an acronym for something other than what it means in Prenzlauer Berg
At any rate, thank you very much for that info on re-installing Flame. That sounds very encouraging! I will let the sw_dbd run for a couple hours (I’ve allotted the 1st half of the day for it) and see if it will ever finish. Next step would be re-installing Flame! Since I already archived everything by now, I guess it should be fine in any case
Indeed, the log showed data corruption and I’ve followed the steps to rebuild the database from the /.mirror/ files. Still, vic is showing a “fatal error”
So let’s see what support will say. For the moment, I’m continuing work on the internal framestore with my archives, but of course I will run out of space soon, so I’m hoping for a solution
Okay, so I guess this whole issue has come to quite an unsatisfactory end. After a day of inactivity, ADSK support did a teamviewer session and tried to get the vic to complete, but to no avail. The vic kept saying that some frames were not found (in the end, as little as 110 of them) but there seems to be no way of forcing it to spill the beans exactly where those frames are or to force it to ignore the issue.
Also, after this whole thing most of the projects where trashed. I tried to archive some unimportant stuff which I can also recover by simply re-importing the footage and loading the BFX setups, but most of the clips I tried to archive had missing frames, so I quickly gave up. That’s kinda weird, as before the attempt to rebuild the database, everything still worked and I was able to archive the most important stuff I did in the last couple days without issue.
In the meantime, I had already ordered a shiny new Pegasus32 which arrived today and is currently synchronizing. I will load all the archives into it tomorrow. Once I’ve finished my current projects on it, I can clean up the old framestore, delete it and then I have another, nice and empty Raid
So I guess the thing to be learned for technically unsavory people like me: If weird stuff happens, check the Stone+Wire logs (sw_dbd.log), and if there is any corruption mentioned there, archive all important stuff, attempt a reconstruction of the database, and then delete the entire framestore anyway
Sad to hear Kalle! At least I like that you may take it easy even loosing time and material - but as you wrote in your book - indeed “Berlin Zombie City” - yes It is! Thanks for keeping this thread updated.
Well, I always assume data loss can happen at the most inconvenient time, so by writing archives and time-machining setups, I’m kind of prepared. As far as Berlin Zombie City is concerned, I was a bit embarassed when the team viewer session started and the first thing that popped up was a PNG of a side-by-side comparison of different cover designs for the prequel, “Berlin Zombie Zero”. No idea why I left that pic on the top level of my Pegasus and tbh, it looked a bit like pr0n
But I guess the ADSK guys will appreciate it when people do book cover designs using Flame
I definitey spoke to soon. Now the Stone+Wire is unable to start AT ALL and my brand new Pegasus32 already has sw_dbd corruption. Now I have finally reached the point where I am NOT RELAXED ANYMORE AT ALL!
So now I have uninstalled and reinstalled Flame and it hasn’t helped. Also browsed through some other threads on here with similar issues, but they were mosty mac-security related, but I’m still on OS 10.13.6 where this whole thing didn’t exist yet. Additionally, I looked into the sw_serverd log and it said at one point it couldn’t start due to a port conflict, this message doesn’t show up in the more recent logs though. Guess there is nothing left to do but contact support again, now with Severity One as I cannot work at all anymore. Just great
If anyone has andy advice, it would be greatly appreciated
Hi Randy, I just used the uninstaller & then installed again … Waldi has since told me there is probably still of old stuff there, especially since I also have 2018 and 2020 versions on the machine. Currently, I’m running a time machine backup of the current state so I’m ready for more far-reaching steps …
I did not wipe the old framestore yet, I made a new one on a brand new Raid and commented the old one out. So the new corruption is really concerning …
Hey, thanks a lot for the offer! I was just about to write that Support really were on their toes today and fixed the issue first thing in the morning. I was just too busy to post in here, but now I got the most important stuff done for the day.
Seems the issue was that I had a framestore on the iMac Pro’s internal storage, which is not best practice, as it turns out. There was still some data corruption in there, and after I deleted the projects, Stone+Wire was able to start again. I guess in all, this whole mess was a mixture of different unfortunate factors. As soon as I have my current projects wrapped up, I’ll do some maintenance and get rid of all the old stuff
Of course today wouldn’t be a perfect monday if I hadn’t come across another annoyance, this time courtesy of Pegasus. Turns out the Pegasus32 has 2 fans, a large and a small one. And the small one runs all the time, even while the Mac is powered off. And that’s how it’s supposed to be, according to service. If you don’t want to hear this whiny noise all afternoon/night, they advise to power off the Pegasus manually before you shut down the Mac. Mindboggling, imho
Hey Everyone, I’m reviving this old thread as today, almost 3 years later, CORRUPTION has returned to my sw_db
This time, I thought I should better act immediately, so I’m wondering if I should follow these instructions here:
This blog entry is only 11 years old, which is pretty recent by Flame standards
Or should I rather contact support … even if that didn’t go too well the last time around, but probably wasn’t their fault. But if that method described above is safe to use, I guess I won’t have to bother them. And I’ve aready made sure that there is indeed sw_db corruption by looking at the log file. Any opinions, advice or last words?
