I did set it back to small and we had clear skys last night; the results were much better.
I am still looking for the astap logs. Offline experimenting with astap indicate it needs on the order to 100 stars to solve. A few of the test cases had less than that and they failed. All the cases with 100 plus worked. When it fails it would sure help to have the log.

Thanks Jasem, I will check this out at the next clear night.

Ok if it is confirmed by more users, we might need to revert to small scale even though "Default" should cover most cases.

I can confirm this problem but would even consider it being a bug.
I lost one night as I was not able to narrow it down the problem after I triggered the update function and the Align process stopped to work reliably and I was not aware of this post. I could use a number of clear nights (first time this year we have some in a row) to check. Setting the Align profile back to Small Scale in the options switched it back to rock solid autonomous operation.

Why I consider it a bug and not just a matter that "Default" should cover most cases:
1. Platesolve worked for me with no problem for polar alignment where the profile was "Default" and not "Small Scale" as well at the same time with the same setup, same exposure time etc.
2. First solving in the Align tab always worked. After this it reportet "not enough stars" and switched to blind solve. Only here and there the solver worked and I could not get to the target. Clearing the mount model did not help. After one successful solving the next attempts did not succeed (or very rarely every 7-8 attempts, automated scripts already stopped before)
3. Quitting kstars and starting the app again led to the same effect: again for the first plate solving in the align tab worked, the rest failed

The fact that it works once with the setting default is for me an indication that it is not just a matter of the general setting "Default" or "Small Scale" for the Align Process. Maybe I'm wrong, but I could recreate that behavoious with my equipment.

Hope this is helpful.

One wish from my side: If a parameter in the options that exists before is actively being changed by an update, could we make this transparent as part of the update procedure (Changelog text file?) or instead recommend users to switch rather than just doing it? This would give back a bit control. Assuming best intention to "improve" things, as a user I feel rather blind to sort out what could possibly be wrong when something that never grabbed my attention suddenly faiis.

Thank you for the report. To recap:

1. Default solver: works once, then fails afterwards with the exact same settings. On restart, it behaves the same, solves once then fails for all subsequent attempts?
2. Small scale: works all the time.

Is there any way to reliably reproduce #1? Maybe share the images that failed to solve with #1 the 2nd time? I'll try then see what could be causing such behavior.

Hi Jasem,

I have at least various analyze files and will send them to you via PM. I hope it gives you some indication.

Kind regards,

Alex

Analyze files are nice to get a broad idea of the session, but log files with verbose logging enabled helps us debug.
See www.indilib.org/support/logs-submission.html
Check all the boxes in the modules section and make it verbose to file.
Compress and share the file via dropbox or google drive.

I followed the instructions in the video but no log file is being created in the log directory. I just confirmed that using a simulators profile.

So let's close this as not reproducible as I do not have enogh clear nights available for experiments I'm afraid. I know that for open source projects like Kstars/Ekos this is not too helpful but now I would even have to check why no logs are being created...

Runs for me at the moment by setting the paramater back so better don't touch. I hope others can contribute more evdence how the change of the value "Small Scale" to "Default" initiated by the update is leading to problems. Jasem confirmed in this chain that I'm not the only one affected.

Still I would think for future updates it would make sense for such an automatic override of values in the options or in case changes of the underlying code might change the effect of a setting, this information (changed from -> to) should be transparent to users quite prominently. In case something is broken after an update, there is at least a chance to follow up this route. The alternative is to not update at all as even playing with two SD cards bears the risk of losing a clear night when running the gear automatically which is for me a key factor in using Ekos..

I remember that the changes of the parameters of the internal guider in the past when they were aligned to PHD2 meanings was communicated in a transparent way and it was clear that users needed to take care of their settings after the update

Thanks!

Kind regards,

Alex

Alexander -

Thank you for your post. I am having similar issues with the Kstars 3.6.6 I ubuntu version. Essentially it performs one platesolve, syncs, and is incapable of solving another image. This applies to "default", "large scale", and "small scale".

Another issue is the "slew to target" function will slew once, sync, PRETEND to slew, sync again, PREYEND to slew sync, etc.

I'll try uninstalling and reinstalling and report back when I have clear skies.

This issue was discussed with the development team and I think we will adopt a train-specific dynamic StellarSolver profile in the next release. So if it fails given proposed default per train, then it will iterate with different settings until it finds a good solution and then use that as the train-specific default. There is no time to work on this for this release, but hopefully it will be in KStars 3.6.8

Michael, for me setting it back to "small scale" solved it, but I remember a problem that you might have as well. The options panel has several parameters that say more or less the same, I remember for alignment was not the first entry. Only when I realized there are more granular options than I expected the setting to "small scale" for the alignment (a bit futher down) did the job. Maybe this is helpful.

Good deal, Jasem. That sounds promising and could help narrow down any issues in the future.

Alex - I re-installed Ubuntu Kstars 3.6.6 last night and used the default settings. The first session went excellent (synced almost 100%) except my mount was slewing the opposite direction shown on the Kstars map.

I rotated/flipped the scope, restarted my equipment (and Kstars, of course), and the issue of syncing once and not being able to solve another image after the first re-appeared. I'll continue testing and see if I notice a pattern.

There are a few options I played with under the Stellarsolver Options tab. However, I did not change anything related to the solver profiles.

Thank you.