We just installed 2025 on a machine to start kicking the wheels and update our hooks and noticed something very annoying with the new licensing method (adskidentitymanager). When you use HPAnyware it logs you in automatically which seems to not allow the licensing manager to set the credentials in your keyring meaning you have to login every single time you start Flame (at least that’s why it would seem like is happening).
You crash, login. You exit and restart login. Over and over again.
Has anyone else noticed this or figured out a workaround?
We’re also running into this issue since installing Flame 2025 on Rocky Linux.
We’re able to work around it by doing the browser dance, but we have to repeat those steps every time we launch Flame. It also affects previous versions of Flame, too.
The Autodesk troubleshooting page says to disable Auto-Login, but we have it enabled for HP Anyware/Teradici. I disabled it temporarily, logged out/in, and it appeared to solve the issue, but the problem returned when I turned auto-login back on.
Seems you went to the generic ADSK support which is offshore and has no understanding of what Flame is. ONLY submit tickets to the Flame support team with ADSK.
I hope this is helpful in your efforts. I have been investigating this issue and after some troubleshooting, I have not had to log in again since making the below changes. The functionality appears to persist after reboots and logouts. I am able to launch and license Flame without the keyring message after performing these steps:
Remove files in ~/.local/share/keyrings/
I would recommend to move the files rather than rm
Disable the following settings under Firefox:
Block dangerous and deceptive content.
Query OCSP responder servers to confirm the current validity of certificates.
Choose Custom protections under Firefox settings instead of strict or standard and untick the boxes under this item.
When prompted to create a new Keyring, leave the values blank and continue.
Note The above steps may not all be necessary, but this was my troubleshooting process.
This allows me to keep AutoLogin enabled, use a remote solution, and avoid encountering the keyring message mentioned above. This is not an official solution and has only been tested on 1 instance of the issue, so remember to backup files and proceed with caution if using this process. Have a great weekend.
To be transparent, while this workaround was effective for my system, I have been informed by another member of the Flame community that this solution is not working for their system. I will spend some time looking over the issue again after a system rebuild.
It seems like this is pretty much exactly what we are experiencing.
The knock on effect for us is that 50% of the time (when clicking through the error) the project window is completely unresponsive and we need to terminate the flame shell window.
unfortunately leaving a blank keyring password doesn’t work in our case as the keyring remains locked after a new sign in. Additionally we can’t use auto login as these are floating systems that are authenticated through sssd so we’re a little stuck!
We’re also seeing an unresponsive Flame project selection screen periodically across multiple systems. We have to kill the process or close the shell to crash out. It usually works fine after launching again. I haven’t been able to reproduce the issue on demand and I hadn’t considered it may be related to this licensing issue.
Project startup delays can also be related to background services.
Sometimes, if you have multiple flame family workstations there can be delays, errors and even crashes while attempting to discover or communicate with remote framestores.
This is problematic if you have multiple versions of the software, if multicast has been disabled (go choke your sysadmin/engineer friends) or if someone helpfully changed UUIDs while installing software because they didn’t know that you might be able to keep backups of that kind of information.
There is not one bulletproof solution - and if someone tells you that there is, they’re not being entirely honest with you.
The issue being discussed here is directly related to some new licensing workflows instigated with 2025. This issue isn’t a delay, but a complete inability to interact with the Project selection window. The only solution we’ve found is to switch to the terminal window spawned by Flame, and to Ctrl-C kill it. Start Flame again, and usually things are back to normal.
This has been consistently working for me. after login (assuming you don’t use your linux keychain for anything but this licensing nonsense) , use the command.
echo “” | gnome-keyring-daemon --replace --unlock
launch Flame it’ll probably ask you to sign in again, if that command is run at the beginning of every login (after the first time) before I run Flame, I’m not asked to log in anymore. Not sure if it’s helpful or not.
@ALan did you ever find a solution to the unresponsive Flame project selection screen? Is your support case 22335292 closed?
We’re seeing a similar issue since installing 2025.1 that only shows a drop shadow outline of the “new features” splash screen or the project selection window at launch. We have to alt+tab to the shell, crash out, then relaunch and it usually works fine.
Edit: And for that matter, any updated solution for the license website authentication issue? Still dealing with it on our systems. @miles suggestion didn’t work for me, but will try now that 2025.1 is installed.
The dev are apparently aware of it, but as far as I know, it has not yet been fixed. We are still on 2025.0.2.X, so maybe it was fixed in 2025.1 but I don’t think so.
I can confirm it happens in 2025.2. I ran into it last night. Going to open a case with Autodesk to put 1 more hit on this issue and help escalate it along.
