So it's linked to guiding somehow. I just ran two MFs. First one guided (PHD2) inclusive dithering. It overwrote one file again. Second one was done without guiding/dithering (and also had no target name defined). This time, frame number was advanced, no overwrite occured.
The log is attached, with verbose dbg. However, there's not really much more info in it seems. Have I enabled the wrong debug? I did 'capture', 'alignment' and 'fits'.
Do you need other modules?

OK, at least the log confirms that it overwrites the same file. Could you please turn on the debugging for all EKOS modules, at least including guiding and scheduler?

Btw: are you using the scheduler?

No, this is without scheduler, just starting from the capture module.

So, here's one with full debug enabled. Guiding is extremely verbose though...
Also, it didn't do an alignment this time after the flip - likely because I didn't align before? Is that intended behavior?

Thanks for the logs, I'll take a look tomorrow.Yepp, it only aligns after a meridian flip if an alignment has happened after the last slew.

I think I found the place where it happens. Do you have a limit set for guiding deviations?

No, the box is not checked. Only focus, via Temperature and a timer. Should I do a run with some limit in place? Would be tomorrow though, as I've now started regular observations (with timestamps enabled ;^>)

OK, I think that explains the behavior. Nevertheless, I would recommend selecting the box for guiding deviations, if guiding is used. If set, it avoids wasted frames in case that wind or clouds cause deviations.

Hm, why would that explain it? And why has it changed? I have never used the deviation limit, and have not seen overwritten frames until recently, and now it's always doing this.
And checking that box would abort the sequence in case of hitting the limit, no?

The function that creates the new index has the following step:Since the meridianFlipStage is MF_GUIDING (which is > MF_ALIGNING), the index is not incremented.I haven't reproduced it 100%, but it might be a side effect of a code cleanup we did some weeks ago. Testing all situations that might happen between a capture is completed and the next one could start isn't that easy, since there are incredibly many variants. And I suspect that your case simply slipped through.In case that this happens, the currently running capture is aborted and restarted. This is a very neat feature for example in windy nights.

Even better is it if you use the scheduler. In case that guiding aborts, the scheduler restarts the capture sequence (as long as it is configured to restart). If the scheduler is not used, aborted guiding leads to aborting the capture sequence, so a single cloud and the session aborts.

Thanks for the explanation! Indeed sounds like a horribly complex thing...
Ah, I'll give it a try then.I mostly run only the capture part, doing the initial setup manually, and go to bed once things run fine. Clouds are usually not an issue here at 2400m.

But last night it would have been helpful, as guiding aborted after the MF. Still have to find out what happened, as PHD2 was happily guiding, but EKOS had it showing idle mode, I needed to manually "start" guiding again... It's the first time I saw it, so it might have to do with the way I started things (I had killed kstars, which left INDI on the remote compute running without disconnecting, so that when restarting kstars and ekos it would have all devices connected and running. Likely PHD2 didn't like that.... But that's in doubt another thread; sort-of hijacking this one once is enough
Thanks again!

I think I could fix for the problem. It would be great if you could test it. It is available as branch bugfix_mf_overwrite_frame on my kstars clone: invent.kde.org/wreissenberger/kstars.git

If you need support how to download and compile it, feel free to send me a PN.