You are certainly right, there is no longer a need for astrometry.cfg. But we might not be finished removing all references to it. I will do a search for astrometry.cfg. There is probably a check somewhere to make sure you have it on your system . .. but of course its not needed.

So I have to add astrometry.cfg because without this file it does not solve. Will try this tomorrow evening.

Hopefully by then you shouldn't need it because we hopefully have it fixed by then so you don't need it, but just in case, sure

I understand. ThankYou

My best guess ad midnight? the light frame is copied to the /tmp folder but it is not removed during the lifespan of the kstars session. Perhaps this is an obstacle. After deleting the temporary light frames from the /tmp folder M57 was solved with Internal SEP | StellarSolver | 4-ParallelSmallScale settings again.

When you say you deleted temporary files, by any chance did any of the files have the extension .solved or .cancel? Astrometry uses those files to cancel a solve or not start it to begin with. One of the problems I found yesterday was that my random numbers I was using for the temp file name were NOT as random as I hoped. So I changed how they are numbered. I also added a check to see if those 2 files exist (and if so delete them!!) before it starts, because of course if they exist that makes astrometry not run at all.

Rob, there were a bunch of files with the text "cancel" and now there are some new files "internalSextractorSolver_2.solved" and "internalSextractorSolver_3.solved" which are 0 B in size.
I turned off "use position" because the fields reflected the exact position of M57 (for better or not).
The light frame of the Iris Nebula was not solved. It is a frame from a Canon EOS 600 D taken with EKOS which does not confirm to the Fits Standard (stated by PixInsight). The Fits Header contains the name of the target, values for RA and DEC. But this data is obviously not used. Instead the StellarSolver set to SEP and 4-Parallel-Small-Scale worked for 6000 seconds (= 10 minutes) without figuring out what it was. But it was a good memory test. All 8 cores of my sweet little nuc were nearly at 100 %. Of course they died one after the other. But, I think you should throttle the threads. Because bad memory will definitely crash the app.
One more thng: The light frame of the Iris Nebula is very noisy.

I set a breakpoint in align.cpp 3271 at m_StellarSolver->start()
First I tried to solve the Iris Nebula with Internal SEP | StellarSolver | 1-FastSolving ---- I cancelled the search.
Then I switched to Internal SEP | Local Astrometry | 1-FastSolving and kstars crashed. Here is the stack:

KCrash::defaultCrashHandler(int) 0x00007f77bc2f88d0
<signal handler called> 0x00007f77b998b210
__GI_raise 0x00007f77b998b18b
__GI_abort 0x00007f77b996a859
qt_message_fatal 0x00007f77baae6c39
QMessageLogger::fatal 0x00007f77baae6c39
QThread::~QThread 0x00007f77baae74ea
InternalSextractorSolver::~InternalSextractorSolver internalsextractorsolver.cpp:41
QObjectPrivate::deleteChildren 0x00007f77bad2ebae
QObject::~QObject 0x00007f77bad395d6
StellarSolver::~StellarSolver atomic_base.h:326
StellarSolver::~StellarSolver stellarsolver.h:53
std::default_delete<StellarSolver>::operator() unique_ptr.h:81
std::unique_ptr<StellarSolver, std::default_delete<StellarSolver> >::reset unique_ptr.h:402
Ekos::Align::startSolving align.cpp:3199
QtPrivate::FunctorCall<QtPrivate::IndexesList<>, QtPrivate::List<>, void, void (Ekos::Align::*)()>::call(void (Ekos::Align::*)(), Ekos::Align*, void**) qobjectdefs_impl.h:152
QtPrivate::FunctionPointer<void (Ekos::Align::*)()>::call<QtPrivate::List<>, void>(void (Ekos::Align::*)(), Ekos::Align*, void**) qobjectdefs_impl.h:185
QtPrivate::QSlotObject<void (Ekos::Align::*)(), QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase*, QObject*, void**, bool*) qobjectdefs_impl.h:418
QtPrivate::QSlotObjectBase::call 0x00007f77bad3b5ae
doActivate<false> 0x00007f77bad3b5ae
FITSView::loaded moc_fitsview.cpp:368
FITSView::loadInFrame fitsview.cpp:438
QtPrivate::FunctorCall<QtPrivate::IndexesList<>, QtPrivate::List<>, void, void (FITSView::*)()>::call(void (FITSView::*)(), FITSView*, void**) qobjectdefs_impl.h:152
QtPrivate::FunctionPointer<void (FITSView::*)()>::call<QtPrivate::List<>, void>(void (FITSView::*)(), FITSView*, void**) qobjectdefs_impl.h:185
QtPrivate::QSlotObject<void (FITSView::*)(), QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase*, QObject*, void**, bool*) qobjectdefs_impl.h:418
QtPrivate::QSlotObjectBase::call 0x00007f77bad3b5ae
doActivate<false> 0x00007f77bad3b5ae
QMetaObject::activate 0x00007f77bad34977
QFutureWatcherBase::event 0x00007f77bab2c4e5
QApplicationPrivate::notify_helper 0x00007f77bb8dacc3
QApplication::notify 0x00007f77bb8e3c70
QCoreApplication::notifyInternal2 0x00007f77bad046aa
QCoreApplicationPrivate::sendPostedEvents 0x00007f77bad06fa1
postEventSourceDispatch 0x00007f77bad5f837
g_main_context_dispatch 0x00007f77b9326fbd
<unknown> 0x00007f77b9327240
g_main_context_iteration 0x00007f77b93272e3
QEventDispatcherGlib::processEvents 0x00007f77bad5ee92
QEventLoop::exec 0x00007f77bad031bb
QCoreApplication::exec 0x00007f77bad0b354
main main.cpp:348
__libc_start_main 0x00007f77b996c0b3
_start 0x0000560c952ab4ee

I noticed that the parallel extractor spawns multiple threads that do the same thing and allocate full-frame memory, so this doesn't make sense to me. It's either a bug or I'm missing something.

I've tried to compile the current master branch of KStars on a Raspberry PI4 running Raspbian buster and I was unable because there is no libstellarsolver-dev version available. Are there any spacial procedure to try the new internal solver on RP4?

Nope Jasem, that is not a bug, that is how stellarsolver solves images so quickly. Note it is not that the sextractor spawns different threads, but that the solver spawns different threads whether it uses the internal solver or the external astrometry solver. That takes advantage of our modern multi-core processors to plate solve using either different scales or different depths simultaneously. You can choose to not use a parallel algorithm to solve using a profile like "Fast Solving" but if you do so, it is basically like using classic astrometry.net and will probably take a long time to solve. Solving in parallel can reduce the time to solve from several minutes to several seconds, but your computer needs to be able to handle it of course.

Ok so that's the way it is supposed to work, but I can check later today and make sure I didn't make some kind of mistake that makes it sextract multiple times. It should really just sextract once, and then solve in parallel.