There must be something special with your situation. In my session last night no image got lost.

As a fast workaround I would recommend selecting the time stamp option for the filename. This way the older one with the same number does not get overwritten.

Fur further investigation I need a log on the verbose level.

One thought: are the other files in the directory besides the image files?

Hmm, yes indeed there's other files, for each FITS there's a .wcs file, from my Live Stacking. But IIRC for the first case reported in the other thread I didn't have that running, then it would have been only the files of the running sequence.
The other difference between the two cases reported here was that the second one had no target name, i.e., only "Light_<number>.fits".
I'll try to get a verbose log tonight and figure out which of those conditions causes the problem....

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.