This does not work with multi-night setup. Suppose I have a scheduler list with Light + Calibration frames at the end. When I run it daily, I expect it to finish whatever is left. If only calibration frames are left what happens? It tracks and focus and guide on what? What if I only had dark frames left?

This does not work with multi-night setup. Suppose I have a scheduler list with Light + Calibration frames at the end. When I run it daily, I expect it to finish whatever is left. If only calibration frames are left what happens? It tracks and focus and guide on what? What if I only had dark frames left?

What type of setup do you have in mind? In case that there is a separate scheduler job for the calibration frames, it simply depends, whether guiding etc. is selected in the scheduler job. If it is not selected, no guiding will happen, right?

I usually have a single job with all frames (light + calibration) that can span multiple nights. If on the last night I run the scheduler in the morning or evening with only the calibration frames left, what will happen with this patch?

@mutlaqja If you want to mix lights with calibration, I wonder if that is really clearer that you need to remember the progress of jobs in that case. In that situation the scheduler will be able to determine what's left to do, and not redo lights if only calibration remain.
If not remembering, the minimal granularity of the work to do is the full job, which contains in your case lights and calibration.
This may push users to run lights and calibration frames as separate jobs just to be sure on what happens.
But in both cases starting the execution will still schedule the job for capture as if there were lights. There are two sides to this: scheduling and running. This differential is lacking work on scheduling, agreed.
You get a good point. Also a scheduler job with only calibration frames should issue a certain amount of warnings: twilight, altitude, etc. The current UI is not prepared for this...

Hm, seems like both changing it and leaving it have good arguments. What about if we freeze the scheduler, leave it currently as it is and concentrate on refactoring as begun in D20001? Doing both in parallel might be too much...

Agreed, this differential was here just to provide a code baseline. We've got more urgent stuff to do. Let's see if the forum thread gets traction.

Is this applicable anymore to the current code base?

Hm, indifferent. It does not seem like there is burning request for this feature. So never touch a running system?

Oh I totally forgot about this one. Actually, it's interesting in the sense it can be used to ensure a mean ADU over the frame. That is, calculate the ideal exposure duration. But there are things to fix, as seen in the comments. I keep this in my list and I'll have a look just because it's cool.