Maybe just 2 sets of solver configs that are tried before failing? It is fast after all, what would it hurt? With luck, this could remove the need to manual tune much, and the system could make the configuration that worked the first configuration for the next solve.

All the tuning could still be in an advanced tab, of course, but it would be nice to not have to worry about it if possible.

$.02

Jim

That's a great idea, Jim!
I presume more than two configurations could be specified, to be worked down consecutively until one succeeds.
That would be especially useful when using the scheduler unattended with a series of targets, where the schedule would start to hang if solving fails.
Jo

Now that's what I call a good idea!! Let's think about this one.

I get a build error:

CMake Error at CMakeLists.txt:212 (find_package):
By not providing "FindStellarSolver.cmake" in CMAKE_MODULE_PATH this
project has asked CMake to find a package configuration file provided by
"StellarSolver", but CMake did not find one.

Could not find a package configuration file provided by "StellarSolver"
with any of the following names:

StellarSolverConfig.cmake
stellarsolver-config.cmake

Add the installation prefix of "StellarSolver" to CMAKE_PREFIX_PATH or set
"StellarSolver_DIR" to a directory containing one of the above files. If
"StellarSolver" provides a separate development package or SDK, be sure it
has been installed.


-- Configuring incomplete, errors occurred!

I'm getting the same issue today...

Jasem, thank you.
The update to stellarsolver's CMakeLists.txt works on Kubuntu 20.04 and I'am able to build KStars again.

Yes, he changed both KStars and sent me a pull request for Stellarsolver today to change the way the package is installed and found. Apparently this change will fix a windows build issue.

Thanks. Removing both kstars and stellarsolver and starting from scratch appears to fixed my stellarsolver cmake issue.

I'm having definite stability issues with stellarsolver. Align seems to be working fine, but running a dummy sequence with the simulators is failing somewhere in the FITS processing post capture. This has been consistent over the last few days as I have been keeping up with the changes. The SEGV goes not always occur in the exact same place, but it always occurs when doing analysis. I turned off all of the HFR calculation options and WCS load options for FITS and Ekos, but it still seems some calls go out to stellarsolver.

I am also guiding (simulated) at the time with SEP multistar, so perhaps there is a race condition between SEP in guiding and SEP in FITS analysis. I'm not sure if any of the changes made it across to guiding yet. There are references to guiding in the backtrace, but I have no idea if that has any relevance or not.

The back trace from the core dump is attached.

J.

I might be reading this wrong, because it is fairly late in the evening for me, but it looks to me like this crash occurred in KStars during guiding, after StellarSolver returned the star list, but before the method to find the guide stars completed? Perhaps the list was still needed and it got deleted in KStars too soon? I will send this to Jasem and see if he agrees.

Right, I just pushed a possible protection against that. I guess under some circumstances, the fits data object can be destroyed while the extraction is still in process.

If there are still problems with star extraction you could consider the ASTAP v0.9.442 extraction option . For an other problem I have added the option to write the extracted stars to a comma separated csv file:

-extract snr_minimum

The snr_minimum is the minimum star snr value required. Default at 30 but for solving snr_minimum=10 should be used. The output file has the same name as the image but with extension .csv and is containing the comma separated data as shown below:

It is a development version compiled for Linux and Windows. Mac and Raspberry Pi are outstanding.

Han