We’ve got a new issue that seems to have only come up in the last week or so. For some reason when we launch Flame we get this in terminal (see screenshot).
Nothing happens after this, it just seems to hang up here. I don’t know if this is licensing related or what it is to be honest. The workaround that I’ve come up with so far is to restart stone+wire. That seems to let us get in and get going. It’s weird that this has started happening all of a sudden though… Anyone else seeing this?
yeah for sure. I’ll submit one. I just figured it might have been a wider issue since this seems to be occurring on most (if not all) of our Flames here. Thanks for taking the time @allklier
If it happens on multiple systems, it would have to be a common resource.
Either a shared storage (NAS/SAN), a networking problem, or a license issue. Everything else should be localized to a single system.
While you’re waiting for support, check what your shared network folders are doing, especially places where user profiles or similar may be stored. You said restarting stone seemed to help. Might be a breadcrumb trail.
Check if anything happened to network connectivity between systems, or outbound from some of them.
If that all checks out, then licensing is the left over culprit.
I agree with all of your logic. Everything you’re saying makes perfect sense. In practice we use a NAS as a common place to grab from / export to, but we all have our own storage where we stonify all of our media.
In this version (2025.2.2) I’m not entirely clear on where user profiles would be stored… As a user it’s quite different from our previous production version (2023.3). I’ll dig around on that front though for sure.
If anyone else is experiencing this issue, my case number is 24071115. I’ll update this post once I hear back from ADSK.
nothing of note anyway… I just did a great session with ADSK support though. We couldn’t really see where exactly the issue is stemming from, but we did see some oddities some of the config files. The issue isn’t happening at the moment, but we need to give it a bit of time to see if it cleared it up or if it will rear its ugly head once more. Finger crossed!
All good thoughts! It’s looking more and more like the issue is/was some inconsistencies in a few config files where some of our Flames were pushing metadata over 1gbE and others were doing it over the high speed network. We’re not entirely out of the woods yet, but so far we haven’t seen this pop up again yet.
We have multiple interfaces on the flame workstations and set the Metadata and Data keys in /opt/Autodesk/cfg/network.cfg. However, I now leave Mutlicast commented out. I can’t remember if it was 2024.x or 2025.x but when I specified the interface for Multicast, things would go wonky. e.g. the output of sw_framestore_dump or wiretap_server_dump was wrong. if you look in /var/log/messages you might see e.g.
sanitize_shared_SynColor_transforms[24306]: Unable to connect to framestore map server: Connection refused.
sanitize_shared_SynColor_transforms[24295]: /opt/Autodesk/sw/tools/sw_framestore_dump returned an error.
Those were the errors I saw when I had Mulicast set to a specific interface.
If the setup app is also not starting, you may have a case of DDS (Dreaded Dangling Symlinks). This happened to me a while back, and I could have sworn I reported it to support. Maybe it’s not the issue, but for sure worth checking out. For me it happened when I restored some setups from an archive. Nothing would start, not even setup. I finally wound up doing a stack trace on .flamefamily or something drastic like that.
What I found was that when a symbolic link is ‘dangling’, ie pointing to nothing, flame freezes up completely. Same for setup.
The solution was a tool called “symlinks” that is available in the repos, so $dnf search symlinks
should find it. Install it and run it in /opy/Autodesk/projects. Without args it will show you links that are: ‘good’ ‘sloppy’ dangling’ > The dangs are the killers. Next move $symlinks | grep 'dang'
Vegas odds you find some. That or it’s another issue completely.
Luckily symlinks has a fit them all switch, it also has a dry run switch. Sadly I’m not in my Linux part just now, but there is a man page and --help. It’s wicked simple.
After I deleted them, poof, like magic it all was back to normal.
Thanks @Beak ! It looks like in my case it was as simple as some of our Flames being configured to push metadata over the high speed network and others were configured to only push frame data over that network. Since we made the config files consistent, everything has been smooth.
