I have seen this twice in a row and was wondering if anyone else is having similar issues. It only started on the most recent update KStar 3.57. I do not have any logs, I am going to have another go tonight on the same target to see if it happens again.
All operating fine till after MF.
EKOS tries alignment from attempts 15 to 115 it is all over the place but grouped around a small area.
 
On attempt 116 alignment attempt it moves significantly closer.
On number 117 it is spot on. 
 
Many Many attempts prior make strange movements that I do not understand. From the final image, the location of the attempts 15 to 115 does not move much.
 

Ignore the fact that it is so far off, that is an issue I have had for over 2 years and gotten used to it, Never cause this problem before. If it happens again I hope to get some logs.
Actually, I mentioned it in a post but no resolution.


The images show the visual details. I am usually in bed when this happens.

I have same issue. I pointed scope do align just fine. Then after meridian flip it try to align again but it just sit there. What I found that helps is clearing mount model in Mount tab. After that it straight jump into correct position.

I will see if there is a setting to do this, I think there is. Still shouldn't happen though.

I've had this a couple of times (not after a MF though). Resetting the mount model sometimes fixed it although once I had to reboot everything. I've been trying this setting...
 

I can't say whether its made any difference though as I've had bad weather for a while now.

The other setting you could try is:
 

Cheers, My system crashed after Meridian Flip last night so I am trying tonight without checking the box. Tomorrow will try again.

Well, it crashed again at almost exactly the same point in the logs, if not the same. I think there is a memory leak because there is a section of the log that request whether there is enough memory to carry out a task.

[2022-02-25T02:36:19.340 ACDT WARN ][   org.kde.kstars.ekos.capture] - "{Device: Canon DSLR EOS 450D (PTP mode) Property: CCD1 Element: CCD1 Chip: 0}" Ignoring Received FITS as meridian flip stage is 7
[2022-02-25T02:36:19.341 ACDT INFO ][     org.kde.kstars.ekos.align] - "Image received."
[2022-02-25T02:36:19.346 ACDT INFO ][     org.kde.kstars.ekos.align] - "Automatically downsampling the image by 3"
[2022-02-25T02:36:19.743 ACDT INFO ][     org.kde.kstars.ekos.align] - "Evaluating Installed RAM for inParallel Option.  Total Size of Index files: 1.54431 GB, Installed RAM: 7.66278 GB, Free RAM: 2.53497 GB"
[2022-02-25T02:36:19.744 ACDT INFO ][     org.kde.kstars.ekos.align] - "There should be enough RAM to load the indexes in parallel."

I might be wrong but, I have an 8G RAM RPi, so I think it is a bit weird that it would request this, but I have no coding experience in OS so I would have a clue why this appears. It did the same thing the night before.

It also appears that I have the option already selected for clearing the mount after Meridian flip anyway.

 

I am lucky I am pointing to an object that starts low because in the morning when I awake it is still tracking but fortunately nowhere near the limits.

I am going the deselect logging of INDI, as it appears that that may not be the issue, the logs are quite comprehensive, so I wish to reduce the logging as it may cause part of the problem. (Maybe)

One thing I do is to setup Watchdog...
indilib.org/aux/watchdog.html

It can establish a heartbeat with Kstars/EKOS. If the heartbeat is lost (e.g. Kstars crashed) then it can take some action like parking the mount. This will, of course, knock tracking off which is a good thing. If you have an observatory then I believe it can take more sophisticated actions.

Interesting, I deselected logging INDI, but it still logged it.

I will update further as it crashed again, also with the same messages apparent before it crashed

Thanks for the info, although concerning that at client like this was added. seems to say something concerning. I also see a lot of Meridian Flip failures on this forum too, which is concerning.

Also, this issue has only started recently as have been working well with MF for a long time.

Hopefully will have a resolution by the next clear weather session.

I unchecked the Auto Bebayer option in EKOS with nothing to do with Meridian Flip.

I ran it last night with 1 hour of capture, this time I watched the screen and for a very very short instance I saw a dialog box appear that was not entirely clear but could make out "Debayer Error"

I found the only option "Auto Debayer" and unchecked it. It lasted through the night but weather crept it so I did get a full capture afterwards. I will try and confirm this on the next clear night.

Since my last post, I concentrated on areas surrounding the DeBayer error. I ended up disabling the FITS Viewer and now I have no issues at all. No crashes. Every time I had the FITS Viewer open it would crash.

This actually fits my previous situation before upgrading to the latest. On version 3.56 the FITS Viewer I turned off, but still worked during previews. This was the best method, as I never ran the FITS viewer during imaging and during those times didn't crash hardly at all. Version 3.57 no longer worked the same way. To view preview images I had to activate the FITS Viewer, turning it on and off was annoying, so I left it on. Now I simply switch it off now.

I will keep monitoring but last night had an almost perfect imaging night with no crashes and flawless meridian flip.