I've seen this behaviour a few times. I think I've found a clue as to what causes it.
Probably affects me more than most people as I regularly load the scheduler with 30 or 40 short jobs for a single night.
The behaviour I see is that some 'valid' jobs get pushed out to the next night. Even though they could/should be scheduled right now.
I have 2 screenshots which explain the problem and also show how I work around it. Screen shot 1:
This screenshot was taken on the night of Jan 16. However some jobs (example rows 2 & 3) are at a good elevation and moon distance right now but get pushed out to tomorrow (17th Jan)
NOTE: Take note of the first row with a <0 score. Deleting this job and clicking the refresh/reschedule button fixes it (see screenshot2)
Screen shot 2:
This screenshot shows the exact same schedule except I deleted the first job which had a score <0 (also deleted other <0 jobs) and clicked the reschedule button above the grid.
All the good jobs immediately change date to the 16th (now) and can be ran.
I'm not sure how to further debug this but I think when there is a score of <0 it messes up the next jobs in the list.
Thanks, here's a zip of the schedule from screenshot 1 above. I just tried loading it now (5:20PM local time) and its actually fine..... Will try play with date-time settings to try to reproduce.
I think I'm able to reproduce with that file
I manually set the time in Kstars to Jan 16th 22:15 and loaded it. (my location set to Cork, Munster, Ireland)
The first job is scheduled for the next day (17th) but if I delete the first row and click the 'reset and reevaluate' button they all get corrected to the 16th
Thanks Wolfgang, that makes sense for the first target. But I think there is still a problem. All subsequent targets (which are far from the moon) get pushed out to the next night. Even though they can be observed this same night.
For example, above, KR_Aur is too close to the moon and is invalid. However the second entry (CH UMa) is actually in a good position (far from moon and 54 deg altitude). The problem is this target gets pushed to the next night.
I would expect the scheduler to skip the invalid entry for KR_Aur and start observing CH_Uma next but it will not.
If I delete KR_Aur, then then CH UMA will flip back to tonight and can be scheduled as expected.
Sure, that sounds very logical, but the scheduler does not have this flexibility built in yet. Currently, the scheduler always keeps the defined sequence with the consequence that targets get pushed to the next night.
We have already discussed such situations. Currently, we are in a refactoring phase and reluctant adding new features. After the refactoring we will have a much more modular architecture which will give us the opportunity to add such advanced features. But before, we need to do some code cleanup so that we do not get stuck in complexity.
TSA-120 + FSQ-85 + ONTC 10"F4 Newton (+ epsilon-160 on Japan trip) | Avalon Linear + M-zero | ASI 1600mm pro + 6200mm pro | KStars/INDI on Raspberry Pi 4/Intel NUC