You are very welcome. It's the least I can do to help out. If only I knew C++... Another year perhaps.
Agreed that it is probably an interface communication issue. It would probably be better to have the button as "Capture & Solve", "Load & Solve" with the Solver Action section giving options "Slew To Target", "Solve Only", and maybe a checkbox for "Sync" in cases where people want the slew and sync to happen. Probably outside of the scope of this topic though - I was sharing as an FYI.
Correct - The slew occurred and failed (because I'm using sims and don't have images set up I guess). The Load and Slew button stays greyed out - only the Capture button can be activated.
Nope - that first image has some "mystery stars" in them that are not present in other images of the same object. My guess is this is a residual bulk image problem that came with switching the camera's mode? Not sure though. I guess the point is that the solver performed well in spite of these mystery stars. I was surprised it didn't confuse the solver.
I'm using whatever default was selected when I built the software with SS included the first time. Looks to be 4-ParallelSmallScale. I find it interesting that some of the images of the same object with similar characteristics solve, but some do not. Maybe these images are right at the edge of some threshold.
Gotcha. Happens to be I have 32G in this PC and I had forgotten about that detail. It's working, and it's fast enough that by the time I switch back to the Ekos window after loading an image that it's already solved. I'll have to try this out on lower memory systems soon.

Thanks again for your work on this!

Greg

You found the solution!
I am able to solve M65 in 1.36 seconds with Auto DownSample checked -- you have a RC! But take your time, the weather here in Central Europe is really bad. My last imaging session was on September 22nd and the next two weeks will be ugly too.

I was having a rather unstable experience today after updating Stellarsolver and KStars on one system, but not another also up-to-date system. While the internal solver in KStars would solve, it frequently crashed on the next image or on the same load and slew afterwards.
The only real difference between the stable and unstable system experiences was that on the unstable one I did not update the SolverTester application. Once I did, the internal solver in KStars became rock solid.

What's that about?

Cerro Torre, sounds great! Yes, we are still working on improving things.

Ihoujin, I am confused by your question? When you say up to date, do you mean up to date by git pull and built from source or up to date in terms of libstellarsolver-dev? You said you updated the "tester application", but it is not separate, the tester application is from the stellarsolver repo, so if you updated that, you updated stellarsolver. So if I am understanding your situation, on the one computer, maybe you updated stellarsolver from libstellarsolver-dev and on the other you built from source?

If you are using the libstellarsolver-dev, it is entirely possible it is slightly out of date from master since it needs to be built by Jasem. We did put in a couple of fixes today and yesterday to build stability, so maybe you got that update on the one system, but the other was still using the older version?

I was testing with what I stated as a different system, but was really a clone of the SD card to an external SSD used as a new boot drive. So the systems were virtually identical.
On the SD card, I updated everything, self compiled. Specifically I ran AstroPi3 script to update KStars. And did a Git Pull for Stellarsolver and ran both Linux setup scripts for the solver and test application.
Later this same day, I did the same for the SSD system clone. Except I skipped updating the test application.

I was not aware that the test application itself is integral to the operation of the internal solver in KStars as it appeared to be to be its own entity.
I found that since it was less up-to-date that the solver and KStars, the internal solver became unstable.

So the tester application is definitely not required for stellarsolver to work, it is just a program that allows us to test the library.

You did a git pull for stellarsolver and installed on both machines using either the setup script or build and install commands? (not apt update)

If so then I don't understand what the issue could be since it should have been an identical library on each machine, unless you did this at a different time of the day, in which case the fix could have happened between the two?

They were done at different times of day. But the instability was resolved after getting around to recompiling the test application. But you are saying that it should not have had an effect. Odd.

In any case. it doesn't appear there is anything to fix. But I thought it might be important to report as it is a possible cause for crashes other's might encounter while testing.

Hey Jim,

I just pushed a possible fix for your build issue. Please see if it fixes the problem. If not, I will see what Jasem says.

Thanks,

Rob

Thanks Rob, I confirmed it was fixed yesterday, but failed to make it back here to let you know. Thanks!

Jim

Good to hear, thanks!!

Folks. Now I can say all the pieces are in place. I told Robert that I noticed a higher rate of failure using the internal solver than the prior astrometry.net, so let's start investigating all possible issues for such error. It's either in the extraction part or the solving part.

In addition to the StellarSolver changes, I also pushed a major update to the FITS Viewer which can now handle RAW files as well as jpg/pngs (added by Robert previously). So no need to open extra windows, all be handled within the FITS Viewer. Furthermore, lots of temporary files were used before between different kinds of operations. This is completely gone now, and we use buffers in RAM all the way to speed up everything. Finally, the same data can be shared between multiple views so now the Summary view will not longer consume more RAM when enabled since it uses the same data. It's not perfect yet since implicit data sharing is not yet truly complete but it's a start.