Thank you very much.
This is the right solution.
I tested it last night and it worked well.
Thanks again.

Good you managed to work around it.

Could you nevertheless specify what version of KStars/EKOS you use? The developers think it was an issue of an older version, so it is important to know if it happens with recent versions, too.

Sorrry for my latet reply.
I use the v3.5.8 version of Kstars/EKOS.
I didn't found the version of Indi.
I hope this information will be useful.

Yes, I do hope they resolve this soon, it has been over 12 months since I first reported it and it continues to be a major source of frustration.

indilib.org/forum/ekos/9913-image-counte...ages-to-be-lost.html

Paul

Well, 3.5.8 is also quite old, so the first thing would be to try a recent version before claiming it's not fixed, is it?

Peter,

I can guarantee it is happening with a version I built around 3 weeks ago, which is running 64 bit Buster.

I haven't yet got a fully working version on Bullseye, but believe I am close to succeeding.

Paul

I will try the last version. May be next week, or next one.
I will comeback here to tell you if the problem is ok, or not.

Could you please provide the logs from such a session where the problem occurs?

You can download it with the link in the first message of this topic.
If you have a problem tell me it and I send you just the log file.

It looks like we have a problem with file handles:At least we have now an indication that could cause the problem.

Today I updated Kstars/Ekos/Indi. Now I will use v3.5.9 of this software solution.
I made a test last hour. I ran a sequence with 700 files (without the TS "Append Time stamp to the prefix"). But I had only 494 image saved. So on 3.5.9 version, we have yet this problem.
I use Astroberry Server. I updated it. But it's only 3.5.9 version. Not 3.6.0 version yet. May be later...

I think it is likely that it started the run by overwriting the same file and then after midnight the sequence started incrementing correctly.

Some additional clues that might help track this down.

I am unable to duplicate it with the simulators.
I have not seen it happen with darks or flats and they never start a sequence with 000 only 001.
I cannot be certain that it has anything to do with the 000 numbering, but it started at the same time, back early last year.
It happens with and without using the scheduler.
It seems to correct itself when midnight occurs.
If it is happening and you stop and start the capture sequence it seems to fix it for the current run.

Paul