Hi Wolfgang, thank you for your efforts in sorting this situation out.
The 3.6.8 release indeed addressed some of the issues I experienced with 3.6.7 and reported here, most notably the gain and offset values are now used correctly even when "--" is not overridden in the text fields.

However, the frame counting problems continue. although not entirely in the same manner. First of all, the Scheduler now counts the frames correctly, but not all of them.

• It may be expected, but it is not counting images stored on the remote computer which is running the INDI server, so only "Save locally" works.
• A more serious problem is that when I had both light and flat frames in the same sequence, the Scheduler counted lights correctly but did not count flats at all. The progress number of acquired frames would just stop increasing after the lights were done, even though the Capture module was continuing to shoot flats.

But here is the most problematic scenario, which, similar to my previous report here , has do to with the interaction between the Scheduler and the Capture module.
This is the sequence file I started with, you will see the file naming pattern for all 3 tasks was the same:
I see the Type, Filter, Exposure and Temperature defined for each task, but Gain and Offset are not. And while they are applied correctly to the file names, I wonder if their missing from task definitions is what causes the Capture module to not see the files when the Scheduler reloads the sequence upon guiding failure. So,

1. Start a Scheduler job with the sequence file provided here
2. While guiding is fine, both Scheduler and Capture show correct capture counts
3. When guiding fails (star lost), the Scheduler restarts it and also does something that makes the Capture module reset its capture counts to 0. It very well could be just reloading the sequence file, using which the Capture module fails to count the files on the disk because of missing explicit Gain and Offset definitions. Possibly expected, but wanted to also note that the Setup tab is following the Capture module and showing its incorrect counts.
4. I had to adjust the sequence file to subtract target capture counts and restart the Scheduler with the updated sequences.

After a few iterations (my guide camera is really outdated), I was down to just one task in the Capture module, and when this scenario happened again, I decided to see if the correct capture counts in Scheduler will help it stop the job. They did not: even after scheduler was showing 100% of captures done, the job did not stop and continued shooting (I suspect because it waits for completion of the Capture module, which in this case has incorrect counts).
Importantly, in my Capture settings, "Always reset sequence when starting" is not checked, and in Scheduler "Remember job progress" is.

The full log is quite large, so I will attached its version stripped from mount and camera output. Searching for "sees" shows that the Scheduler indeed "saw" correct number of captures, but I do not see anything indicative of a problem in the Capture module, although its logging was switched on.

I have just confirmed my guess in a simulator-driven test.

Indeed, the problem is that gain and offset, when not manually specified in the text fields, are not written into the sequence file.
And when the sequence file is loaded/reloaded in the Capture module, that is what causing it to not see the files already on the disk.

The test is simple: just start the scheduler with some sequence that has %G and %O in its file names and keep both gain and offset as "--".
After a few captures are done, just stop the Scheduler job. And then start it again.
It will cause the Capture module to reload the sequence and show 0 for capture count.

Now stop everything, edit the sequence to explicitly specify gain and offset (override the "--" with numbers), save the sequence.
Start the Scheduler with the updated sequence again, and the capture count will be correct in both places (all three, including the Setup tab).

This should be an easy fix.

Kyrill, this placeholder matching drives me crazy!

Thanks for your report, I'll take a look into it.

- Wolfgang

Wolfgang,

Is there some documentation as to the meaning of the placeholders? I've deciphered many of them; was able to deduce that %B represents binning.

Thanks,
Bob

Move the mouse over the Format field and you will get a popup showing all placeholders.

Thank you. Like, duh, all I had to do was move the mouse a little to the left and there was key.

Bob

Kyrill,
I've created MR!1072 that should fix the counting issue you reported for light frames.

Regarding the counting problem with flats: could you please be more specific, I could not reproduce it (or the new change fixes it as well).

Are you able to test it directly by compiling from sources?

- Wolfgang

Hi Wolfgang, I was finally able to download a fresh nightly build and I confirm that the issue indeed looks solved.

With %T_%F_%e_Gain_%G_Offset_%O_Temp_%C file name template:

In 3.6.8 stable the counts were done correctly in both Scheduler and Capture module only when
- Force temperature checkbox was checked
- Both gain and offset values were specified explicitly in the text fields

In the last nightly build neither of these seem required. So without checking force temperature and without overriding gain or offset, the counts look good in all 3 places (Scheduler, Capture, Setup).

Importantly, when the schedule job is aborted midway (in the test I manually clicked the stop button) and then restarted, the capture counts resume where left off, so everything is as I expect it to work.

Thank you once again!

Regarding my report of flats not being counted when lights are, I will need to get back to that as I did not make a record of when exactly that happened.
Will pay attention during my next session and let you know.

Update. I have just had a non-simulated session and I again confirm the fixes worked well. When the clouds rolled in, the scheduler was restarting the job and the counts did not reset in any of the modules.