So I'm trying to err on the side of caution with loading the indexes in parallel. In the documentation, Astrometry.net just warns you to make sure you have enough RAM to load all the indexes at the same time. Earlier I had StellarSolver detect the total installed RAM and just calculate whether it can load all your indexes based upon that. However, since a user might have many programs open at the same time, that really isn't good enough especially on a PI. If you run out of memory you could get crashes and we were getting reported crashes earlier on PI's, which I think were because of this option. So I changed it to be more conservative about using this option. We will certainly keep doing testing and if it becomes apparent that we can give a little more leeway on whether to load all the indexes and it doesn't cause crashes, we can certainly do that. It is also entirely possible that it was not this option that was causing crashes and it was something else that we since fixed, but I would still lean on the side of caution and aim for stability rather than speed.

Hi Greg,

Thank you for doing some testing!

I am confused by your first issue: "BTW - when testing with the simulators I left the Solver Action as "Nothing" but the slew still occurred". I think this is a miscommunication in the interface. If you clicked the "Load and Slew" button then it is always supposed to slew to the target. The selections for the Solver action are only applicable if you click "Capture and Solve"

" after the unwanted slew, the Load and Slew button was now greyed out." So was this after it arrived at its target after the slew you mentioned? The buttons should be disabled while it is slewing, but after it gets there they should re-enable. If not, that could be a KStars bug.

" image has some problems including mystery stars". Do you mean that it detected noise as stars? This is certainly possible depending on your selected options profile. We are trying to develop better options, but they aren't quite perfected yet. Did you only try the one profile or did you try any others?

"However, this one of the same field does not solve. The main differences I can determine is the median signal of this frame is higher than the other two and the image is rotated 180deg from the others." I downloaded this file and it solved quickly. Which profile are you using to solve?


" Interesting that it says it needs 19.7GB of RAM. Is that true?" So the way astrometry's "load all indexes in parallel" option is supposed to work is that it loads all your index files into memory simultaneously, at least according to their documentation. This of course will make it much much faster than loading each index file one after the next. But if you have bigger index files than available RAM, this could be serious problem. I am not sure that it always will use that much RAM and if you have SWAP files or ZRAM, that could certainly prevent any crashes that could occur from taking up all the RAM, but I don't want to risk crashes, so in the code right now I calculate how much RAM there is and how big the indexes are and report that and disable the option if it is too much. We can play around with that to see if it really does take that much, but for now, I'm being cautious.

Thanks again for testing and let me know if you have any further questions,

Rob