Aaaah, I see, you are right! OK, next attempt...

I am glad to have found this thread as I was having this very issue, albeit on a Mac. Double happy that the cause has been identified and the fix is in the pipeline. Thank you all involved very much!

I would just like to highlight a couple of seemingly related effects that I experienced last night. They may or may not be due to the same issue, but please consider.

First of all, it was not only the Scheduler that was failing to count written files. The Capture module was also failing to do so, although in a slightly different setting, as follows:

1. Create a sequence file with subframe file name patterns containing gain and offset placeholders (that we now know confuse the Scheduler), save it and start Scheduler with that sequence
2. As the job is executed, the Capture module actually shows the number of captured frames correctly, but the Scheduler is showing 0 progress (this much I believe has already been discussed in this thread)
3. (But here comes the new part) In my case it was guiding failures that made the Scheduler restart (I think it only restarted the Guider, because it certainly did not re-run alignment or autofocus), but whatever it was, the Scheduler reloaded the sequence file in the Capture module, and from this point the number of captured frames there was also reset to 0

In effect, when this happened after 24 out of 25 frames in the first job were already taken, the Capture module started shooting the first job all the way from 0, but on the disk I would end up having 49 subframes for the first job (with correct numbering, because even though the Capture module showed its status incorrectly, the file names were generated with correct numbering).

"Remember job progress" in Ekos Scheduler options is checked.

Hopefully the fix that is already in the pipeline will help not only the Scheduler, but also the Capture module in this case.

And one more issue that seems somewhat related, but may as well not be.
In the Capture module, where it displays the current Gain and Offset values for the camera, there are text input fields to override those values for the current job, by default those fields are populated with double dashes ("--").
If I use gain and offset placeholders in my filename pattern in this situation, the files will have -1 instead of the actual gain and offset, just as in the preview pop-up on the following screenshot (confirmed with the actual written file name, so it is not just the name preview pop-up that has the issue):

So even if I don't need to override the current values, I still need to populate those text fields in order to get them reflected in file names.

Thanks for reporting this, Kyrill.

Hopefully, MR!1056 solved all issues. It will be part of 3.6.8, which will be released in the next days.

Hi Wolfgang

The issue is reproduced when %C and %P are specified for Format as follows
\%Type\%Filter\SomeFreeText_SomeFreeText_%Type_%Filter_c%C_G%G-O%O_%e_%Datetime_p%P

Version of KStars is 3.6.8 Stable for WIndows.

Hi Wolfgang

The attached figure shows the contents of the Local variables in Line 4167 of Scheduler::getCopletedFile.
The regular expression of %C set in the variable "path" is -1, so it does not match the "fileName".

Hi Kyrill,
problem confirmed :-/ I thought I fixed it recently, but obviously not. I'll check what is still causing problems...
- Wolfgang

OK, problem found, there was still a weakness for temperature handling. The special thing that you are doing is using the temperature parameter without explicitly setting a target temperature in the .esq file. If you set it or remove the placeholder for the temperature, counting should work.

Hi Wolfgang

The .esq temperature settings and PlaceholderFormat used are as follows.
The temperature setting appears to be explicitly specified.
I'm not sure what the "force" attribute means; if it should be 'true', please point it out.

I was seeing the same behavior with 3.6.7 Stable on Ubuntu. I was indeed using the %C parameter. Initially I thought it had to do with XISF versus FITS: indilib.org/forum/ekos/14088-fits-vs-xis...eduler-progress.html. Did the latest fix make it into 3.6.8 Stable, or do I need to pull latest?

If force is set to false, then Capture will not control the camera temperature. In case you are using a DSLR, this setting is correct, since the camera has no cooler.

The fix is backported to stable-3.6.8 meanwhile.

I hope that counting is working correctly now.

Thanks for the advice.
I checked the behavior of the scheduler when cooler is enabled and format contains %C.
The scheduler counted up the files taken with no issues.

Glad to hear! Meanwhile, with the latest version from today it shouldn't be necessary any more.