Crash when I delete a fixture

markshankel · Post by **markshankel** » Thu Mar 28, 2019 12:12 am

LX Beams crashes almost every time I delete a fixture or multiples. I updated to beta 5.5.1 to no avail. Am using 2018 15inch MB Pro with latest OSX update...

Thanks

Post by **admin** » Thu Mar 28, 2019 1:08 am

This does not happen in general, so there is likely something specific about the plot you are working with or the way you have the preferences set that is causing the problem.

If you open /Applications/Utilities/Console.app you can possibly locate the crash reports by looking in the User Reports tab. If you can email a crash report, that can help find what the problem is.

Even better, if there is a plot that causes the crash in a repeatable manner, you could send that with what steps cause the crash and that is very helpful in figuring out what the problem is if you email the plot that is causing the problem.

It is possible the problem is caused by a report that is open in a window or tab when the lights are deleted. So, the more you can explain what the situation is when this happens, the more likely it is that the cause can be tracked down and fixed.

If use the Finder's Go->Go to Folder command and enter ~/Library/Application Support/com.claudeheintzdesign.lxseries/logs, you'll see the LXBeams log file which contains messages from the most recent session. It is possible that there is a clue in that file. But, in the case of an outright crash, its not too likely to be helpful. The crash report or steps that reproduce the crash are much more useful.

markshankel · Post by **markshankel** » Thu Mar 28, 2019 7:14 pm

So, Yes it was one particular plot, I was making changes to a copy of our house plot for a proposed upgrade to LED fixtures. I had charged a bunch of S4 Lekos to color LED Lekos, creating multiple address conflicts for each one. I was thinking I'd keep purpose and channel numbers for now and work on re-addressing (and circuiting) later.

I probably had 100's of conflicts and never scrolled down beyond the visible few in the conflict pop up window. I deleted all the useless addresses and I think all is well.

I guess the right thing to do in this case is delete a single channel unit and then add a multi-parameter or at least delete the addresses for now.

Post by **admin** » Thu Mar 28, 2019 8:28 pm

That's a really good clue. If you can find the crash report, that would be great. Otherwise, I'll try to re-create the problem and see if I can get it to happen.

Post by **admin** » Thu Mar 28, 2019 8:36 pm

When LXBeams crashed, did it quit or did it give you the spinning colored wheel and you forced it to quit?

markshankel · Post by **markshankel** » Sun Mar 31, 2019 5:53 am

Just plain quit...

Post by **admin** » Sun Mar 31, 2019 2:02 pm

I've had no luck re-creating this problem. I've switched back and forth between LED and Conventional with 100 units, creating conflicts with a number of reports open, used undo, and still no crash. I'm beginning to wonder if the crash was actually something to do with the messages window. That is, the creation of address conflicts did not cause the crash. But, the updating of the messages window to report those conflicts did. If so, that's going to be extremely hard to track down and even reproduce. The crash report might provide a clue. But, it could also be a multiple thread issue where it is the exact timing and circumstances that cause the crash.

Post by **admin** » Mon Apr 01, 2019 9:40 pm

It turns out that this was a problem with the automatic update of the key block and not any of the other speculative causes in previous posts. There's a new version 5.5.1 (14701.1) posted as the latest build. This version should address the issue and will improve the performance of automatically updating the key block every time there is a change.