Older versions work fine, but when we try to launch 0.9.9, it gets stuck at an auth page on waiting:
I got this to work, once, by removing the 0.9.9 folder, and re-installing, but then the thing wouldn’t use all the lasers, and after restarting is stuck in the “authorize online” state.
After restarting a few times, the auth issue seems to have resolved itself, but now we can’t get all the lasers to arm correctly:
Wow. moving back and forth between 9.6 and 9.9 is… not so easy, because of the way this new auth stuff works..
So.. once you use 9.9 don’t try to go backwards?
Stuck between that last message and this one:
Have to admit, it’s pretty frustrating to get all excited about all the things in the new beta, schedule some time to work on it, and then to end up here after downloading and troubleshooting licensing instead of new stuff in the software itself. Very much hope this situation gets sorted soon..
Hi Eric,
Thanks for posting all of this. Just a quick reminder up front that 0.9.9 is an early test build still in active development, and part of the goal is to catch exactly these kinds of issues before a stable release. If you’d rather avoid running into problems like this, it’s always safer to stick with the latest stable version. That said, your feedback here is genuinely helpful and very much appreciated, and I’m sorry you hit these roadblocks.
To start with the DACs: since you’ve been able to arm all four lasers, it looks like the license is activating correctly (was that in 0.9.9?). The red squares next to the DACs indicate a connection issue. This isn’t related to licensing (which only affects arming, not connections), so I suspect the DACs may have entered an error state or hit some kind of network problem. A few things to try:
- Quit Liberation (all versions), reboot, power cycle the DACs, and restart
- Check which network interface is being used - especially if you’ve got both Wi-Fi and Ethernet active
- If the DACs connect fine in 0.9.6 but not 0.9.9, let me know - that could help narrow it down (although I don’t think that code changed, which suggests it could still be permissions-related)
Re the authorisation stuff: I’ve manually de-authorised your activation, so that should help move things forward.
For your information, 0.9.9 uses a new machine ID system I built specifically to avoid problems we’ve seen before on Windows, where system IDs would come through blank unless the app was run as admin. The new system uses hardware identifiers like CPU ID, BIOS serial, motherboard serial, disk serials, and MAC addresses - things that are usually accessible even without admin. This is Windows-specific - macOS doesn’t throw up the same hurdles (of course, lol).
Because of this change, the machine ID in 0.9.9 is different from the one used in 0.9.6. That means the two versions effectively see themselves as running on different machines. If 0.9.6 is still authorised, the new version won’t be able to authorise until that’s cleared. That’s likely what you ran into.
Once you click “Authorise” in 0.9.9, it enters a “WAITING” state - that just means it’s polling more frequently to see if a matching license has been issued. If it doesn’t find one (because the authorisation process failed), it stays stuck. A restart usually resolves it once the license is in place.
It’s not totally clear yet whether the blank ID was being sent by 0.9.6 in non-admin mode, or if something’s going wrong in 0.9.9 too. Since you managed to arm lasers in 0.9.9 (right?), it suggests that version is generating a valid ID - which would mean the issue is on the older version. If that’s the case, great - that’s exactly what the new system was meant to fix. But if 0.9.9 is still sometimes sending a blank ID, then I’ve got more work to do.
The machine ID issue (the one I’ve attempted to fix in 0.9.9) doesn’t affect all machines - I’ve never been able to reproduce it on my own Windows setup, which has made it really hard to track down. I’ve been working somewhat blind trying to fix a permissions-related failure that only seems to appear in the wild. So if you’re up for it, I’d really appreciate it if you could DM me your logs - they’ll help me work out exactly what’s going on.
I know it’s frustrating to set aside time to dig into new features and then hit this kind of stuff. But your feedback is helping me catch edge cases I wouldn’t otherwise see, and that makes things better for everyone - so thank you again for testing this.
Kindest,
Seb
1 Like
Ya, I’m always the edge case in life, it seems..
In any case, it’s now licensing properly, thanks. I did modify the shortcut to always run as Administrator, because when I was launching it without that, i got a message about my systemID being blank. as soon as I launched as admin it worked fine.
Something must be up with my project, because with a new default project, all the lasers work, but with my old existing one, only half the lasers work… I guess I get to start over with a new project and reprogram the lasers each time there is a major release.
Ha, well I really appreciate you being the edge case - genuinely. These are exactly the situations that help me improve the system for everyone else.
The new ID system was designed specifically so you wouldn’t have to run as administrator, so if it’s not working that way on your machine, I’d really like to figure out why. (If you switch between running as admin and not, it can cause file permission issues - especially if some files were created in one mode and then accessed in the other.)
That issue with your old project file sounds super weird - you definitely shouldn’t have to rebuild things from scratch every time. Let’s take that to PM - if you’re up for it, please send me the .lprj file and I’ll take a look.
Glad to hear licensing is working now, at least - that’s a good step forward.
Thanks again for sticking with it and helping dig into this stuff.
Seb
(PM coming)
I’ve discovered that if I authorise my (Windows) install of Liberation whilst plugged in to my USB-C dock, and then subsequently disconnect the dock and restart Liberation, it becomes de-authorised again. Reconnecting the dock again and restarting gets me back to my authorised installation.
I’m guessing the hardware IDs change with the dock connected so it thinks it’s been installed on a new device? I also can’t de-authorise it with the dock unplugged so can’t free up the license unless I’m plugged in!
yeah this is because it now uses the MAC to generate the UID which is the identifier the auth system uses, tbh MAC’s should not be used for this as they tend to change a lot and can be spoofed really easy anyway
1 Like
Been doing some testing with Seb and we’ve worked out the issue - something to do with disks /removable storage in my case. He’s going to work on more changes to try and overcome the problem on Windows.
2 Likes
Thanks everyone - just to clarify: the MAC address was only ever a fallback in the machine ID system. Even when I disable MAC-based IDs entirely, disconnecting the dock still seems to change something deeper - potentially the BIOS serial or another hardware identifier.
It’s incredibly frustrating how inconsistent Windows can be in this area. Depending on the motherboard, firmware, and how the OS reports things, even subtle hardware changes (like docking/undocking, or inserting a USB drive) can completely alter what the system returns. And because I’m trying to avoid relying on admin permissions, the available info becomes even more limited and unpredictable.
I’m working on a new version of the ID system that should be much more resilient to these kinds of changes. Thanks again for helping track this down - I really appreciate the detailed reports.
Seb
1 Like
OK new Windows ID system is up for testing here!
As before you’ll need to de-auth your existing installation before re-authorising this one.
Let me know how you get along!
Seb
1 Like
A post was split to a new topic: Windows protected your PC warning
3 posts were split to a new topic: Ether Dream connection issues when upgrading to new versions