Spent the day trying to populate a new library without success thanks to frequent crashes or hangs.
I successfully loaded my data collected to date into a 2024 library, but when I tried to load my 2023 data in a different library, Observatory crashed when I tried to drop the whole folder (1.25Tb).
I tried loading a dozen or so dates at a time and got through November, but even loading one session at a time the program crashes...but not always. Import doesn't work at all, simply ignored.
(There are 100Gb free on the internal SSD.)
The crash reports indicates Termination Reason: Namespace SIGNAL, Code 6 Abort trap: 6.
I've restarted the program several times, of course, and tried uninstalling and reinstalling to no avail.
I haven't received a full crash report from Apple yet. The only ones I received are for the Quick Look plugin (may be related to the colorful icon issue you have been having). Unless you have disabled the crash report sharing in your Analytics & Improvements System Settings, I should receive it in a few days, which should help me find the underlying cause of the crash.
It sounds like it could be caused by a single November or December image though. It may not be consistent because Observatory 2 imports multiple images simultaneously*.
* Unless it runs in Observatory 1 mode, in which case it imports images sequentially (one CPU core only), which is way slower.
Is there an Observatory 1 / Observatory 2 switch somewhere other than Settings?
IOW, it seems you're saying Obs2 can run as if it were Obs1.
If that is correct, how are the modes selected?
Share with app developers was off. Crash report attached.
Tried loading just one session, any session. No joy.
Restart didn't help.
Disk Utility ran successfully on the volume where I save previous year's data. Observatory is on internal SSD
Deleted app, downloaded new copy from App Store. Problem persists.
Couldn't find any App Support or plist files or I would have deleted them too
New wrinkle: Tried to close 2023 and then open 2024, but Observatory said 2023 couldn't be found, did I want to create a duplicate. I said yes and now is not responding.
Force Quit, Reopen. Now there are two albums for every session, M31 subs in NGC 7000 albums, etc. Most dupes contain no images
Timemachine wouldn't restore the 2023 databse (locked files?). By chance do you have a tool that will rebuild the database/index?
Thanks, I have now indeed received automatic crash reports that are related to importing. Probably from your machine.
Observatory is sandboxed, so the App Support and plist files you are looking for are in ~/Library/Containers/com.codeobsession.Observatory. Just deleting the application from /Applications and redownloading it does not remove the settings. Finder nowadays shows that as ~/Library/Containers/Observatory, not ~/Library/Containers/com.codeobsession.Observatory as before ::) .
I deleted ~/Library/Containers/com.codeobsession.Observatory and tried to load a folder of Lights.
Still crashes
When you delete that folder, make sure to empty the trash afterwards so Observatory can really not find it.
Did it crash now for a folder with new lights or old ones? The crash reports contain many kinds of different activities that are happening during importing. I wonder if the crash happens during decompressing XISF images. What version of PixInsight are you using? Can you check if this is happening with other image formats? What about older XISF images? Did you select a different compression method for XISF files?
QuoteWhen you delete that folder, make sure to empty the trash afterwards so Observatory can really not find it.
I did
QuoteDid it crash now for a folder with new lights or old ones?
Both
QuoteThe crash reports contain many kinds of different activities that are happening during importing. I wonder if the crash happens during decompressing XISF images. What version of PixInsight are you using?
I always update when a new release comes out. Currently using 1.8.9 - 2 Build 1601.
I'm trying to load images from 2023, FITS header doesn't include what build was used, but it was version 1.8.9 - 2
QuoteCan you check if this is happening with other image formats?
Yes, it is.
QuoteWhat about older XISF images?
2024 images were imported without an issue. I'm trying to load older albums (session). All loaded ok until November. I have a vague sense that the issue is large folder imports. I've been able to load individual files and managed to load on folder with 59 images. But a folder with, say, 200+ lights will always hang or crash
QuoteDid you select a different compression method for XISF files?
No.
---
I continue to get an error msg: This document could not be autosaved. The file doesn't exist.
But it does. And if I use CMD-S it saves fine. And I can launch by double-clicking on 2023.observatory.
However now two windows open, both named 2023.observatory. That didn't happen earlier today.
Just restarted from the crash log "Continue" and have just one library open.
Back to my question from several messages ago: do you have a tool that will rebuilt
BW, often, but not always, after a crash I have to force quit Finder, whatever that proves.
Just tried to create a new library with 2022 data, and it won't import anything using menu or drag and drop. Activity says it Imported 0 images in 0.1 seconds. Then tried a download from the Virtual Observatory and got this error:
"The document "2022.observatory" could not be autosaved. The file has been changed by another application."
Did you recently upgrade to macOS Sonoma? Having two windows open for the exact same library seems to be a macOS Sonoma-only regression. One that I have not been able to reproduce. It shouldn't be possible, but with Sonoma it apparently is. Observatory cannot work correctly in that state. Its library versioning (time machine) is supposed to help you restore an Observatory library to a previous state, but it sounds like it is in a state where that is not even possible.
Quote from: Sander Berents on March 06, 2024, 08:44:47 PMDid you recently upgrade to macOS Sonoma?
No, I updated last September when it came out.
Having two windows open for the exact same library seems to be a macOS Sonoma-only regression. One that I have not been able to reproduce. It shouldn't be possible, but with Sonoma it apparently is. Observatory cannot work correctly in that state. Its library versioning (time machine) is supposed to help you restore an Observatory library to a previous state, but it sounds like it is in a state where that is not even possible.
[/quote]
That happened once and hasn't happened again. Timemachine did restore the 2023 library. But I still get the "can't autosave because library doesn't exist" message.
The larger problem is I can't import images without
Observatory crashing.
I provided all the other details with the hope they, along with the crash reports, would help you figure out what's going on. As it stands, the program is useless.
To be clear, the problem may well be of my doing, and I love your program features and very much want it to do what it is supposed to do, but so far I don't feel any closer to a solution than I did when I started this thread over a week ago.
I have not been able to reproduce any of these problems, and although the crash reports provide some hints, it is not clear to me yet what is the exact cause of the crash. The autosave issue may be permission or sandbox related, but that too I have not been able to reproduce. I'm trying to pinpoint the cause, but right now I do not seem to have enough information.
You are not doing anything "wrong". You are just running into an obscure Sonoma or Observatory bug. After all, it worked all this time, and now all of a sudden it doesn't. The bug reports I have received for this crash are all for macOS 14.2.1. The current version of Sonoma is 14.4. Can you confirm you run the latest version?
Quote from: Sander Berents on March 08, 2024, 07:48:51 PMThe current version of Sonoma is 14.4. Can you confirm you run the latest version?
As a matter of fact, it is not. It was 14.2.1 just as you said.
Auto update is on, and when I looked in the Settings, General, and Sysytem Update the OS told me it was up-to-date.
So I rummaged around, found Apple's swcdn, downloaded the 14.4 installer, and ran it.
Good news is, now I really am running the latest OS. Bad news is, Observatory still hangs or crashes.
And I still get a message that the library doesn't exist.
Successfully loaded several sessions, but when I tried to save, the error msg said the file couldn't be found, try saving a duplicate. When I tried that Observatory hung.
Tried renaming and saving the library, which seemed to work, but when I double-clicked on the file to launch Observatory, two windows appeared and the program crashed, no crash report.
Tried duplicating the file. When I double-click to launch nothing happens. When I tried Open With... two windows opened, then hang.
All that seems to be Sonoma specific behavior, and document versioning related (Observatory's integrated Time machine support). I wonder if that is the underlying problem, that there is an obscure conflict going on with how Observatory handles versioning and some undocumented changes in Sonoma. I haven't touched that part of the code for years, so it is really a change in Sonoma that causes this.
The Observatory Demo has versioning disabled, but it doesn't allow saving libraries so we cannot test this theory with it.
I'll look into that and also add a few (hidden) settings to Observatory in the next update so that feature can be disabled and we can test if that "solves" it.
What's weird is that I have never seen this behavior myself on Sonoma. I have only been running Sonoma on an Apple silicon machine though, while you run it on an Intel machine. I have now upgraded one of my Intel machines to Sonoma as well, and maybe that allows me to reproduce it.
Sounds like a plan. I look forward to the next update.
Are you actively working on the next update or should I look for another solution (Observatory is useless to me as things stand)?
I cannot reproduce it. But Observatory 2.0.5 will contain two new settings that may solve the issue for you:
- The ability to disable library versioning (the Time Machine integration);
- Explicitly set the number of CPU cores to use for importing.
I am still working on a few other items before releasing it.