The Greedy Scheduler
I've recently submitted an Ekos change that will allow you to choose a new scheme for scheduling jobs. (In the nightly release) there should now be a scheduling algorithm choice. If you set it to "Classic" (the default), nothing has changed. If you set it to "Greedy" you will see the changes described below. Note: these changes concern scheduling--deciding which jobs run and when. They do not affect the job management aspects of the scheduler which remain unchanged.
In both the Classic and Greedy schedulers, jobs are listed as "earlier on the job list means higher priority". With the Classic scheduler, priority** is of the highest importance. It will not schedule a lower priority job until the higher priority job is done, even if that job takes several nights, and even if the higher-priority job cannot run at the current time, e.g. due to altitude/terrain/etc. In contrast to this, the Greedy scheduler attempts to keep Ekos busy as much as possible. Although it gives priority to earlier-listed-jobs, it will run later-listed ones if the earlier one can't run. Of course, the lower priority job will get preempted when the high-priority job can finally start to run.
**In this discussion, "lower priority" means "further down on the job list". and similarly, higher priority is higher/earlier on the job list. We will be phasing out the priority number that can be assigned to jobs on the Classic scheduler.
If you start the scheduler with only one job, there is no difference between Classic and Greedy scheduling. However, if you have more than one job, depending on your setup, there is a good chance that the Greedy scheduler will schedule more imaging time than Classic.
Here's a recommended way to try this out. Let's assume you have a main target for which you want to collect as many images as possible. Set that target up as first on the scheduler list, have it start ASAP and set its completion condition as "Repeat Until Terminated". It should be scheduled to image whenever possible (even across multiple nights) until you turn off the scheduler or Ekos. Add several other targets as well, ones that you might also be interested in, and that can be imaged in other parts of the night. Make sure those are listed below the primary target on the jobs list. Set those the same way (ASAP/RepeatUntilTerminated). They will be scheduled to run whenever the primary target can't be imaged. Of course, make sure the twilight restriction is set for all your targets. Altitude and terrain restrictions are important as well--if Ekos doesn't know that there's a tree or house blocking your target, it can't be smart about scheduling it.
Since jobs will be preempted/restarted more often with Greedy than with Classic, the "Remember Job Progress" option is now more important. You can find this setting in the KStars Setting Menu --> Ekos --> Scheduler --> "Remember job progress". This option only works if you are storing images on the same machine where the scheduler is running. You should enable "Remember Job Progress" with this scheduler to get the most benefit, assuming your capture sequences use multiple/different filters. If your capture sequences are just used with one type of filter/or OSC then it probably doesn't matter. (RememberJobProgress has also be updated a bit, and should now do a better job of picking up where the last attempt finished.)
Here is a screenshot of the scheduler running with this new scheme. Note that there are 4 jobs, and they are listed in order of precedence. You can see the next start times for each of the jobs on the scheduler table, and the highlighted (4th) job is the one currently running. A schedule for the next 48 hours is also printed in the log window at the bottom.
The scheduler is (minimally) integrated with Analyze. During testing I let the Greedy Scheduler run for 3 days. Here's a screenshot of the Analyze timeline for the 3 days. (Note some timelines didn't display well because of screen resolution.) The top line is the new scheduler timeline in Analyze. The different colors correspond to different jobs that were run, each one keeping its same color on different stars (yes, red is an unfortunate choice of colors and I've already submitted code that changes the color scheme for that line). You can see the different jobs ran as expected each night.
Please test this (currently in the nightly release) and let me know how it goes.
Hy