<table><tr><td style="">TallFurryMan created this revision.<br />TallFurryMan added a reviewer: mutlaqja.<br />Restricted Application added a subscriber: KDE Edu.<br />Restricted Application added a project: KDE Edu.<br />TallFurryMan requested review of this revision.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D12398">View Revision</a></tr></table><br /><div><strong>REVISION SUMMARY</strong><div><p>Homogeneized scheduler log strings for clarity when reviewing test<br />
results. Warning, all these logs are using i18n, so those changes<br />
obviously have an impact on translation, if they are indeed translated.</p>

<p>Reworked job estimation to check the number of light frames for each<br />
sequence job in the schedule, in order to consolidate the total number<br />
of frames effectively captured without dropping a sequence job by<br />
mistake.</p>

<p>Reworked job time estimation to properly account for progress when using<br />
repeats. Now repeats-required field is expectedly 1 by default.</p>

<p>Reworked capture count algorithm to rely on the state of the job to execute the<br />
search, and reuse previous results whenever possible. This reduces the<br />
directory parsing to storages of job which actually changed. Also, this does<br />
not handle the duplicate scheduler job situation, only the duplicate sequence<br />
job. But possibly we don't care about the duplicate scheduler job situation,<br />
that's completely acceptable and so much simpler for the end-user to have two<br />
duplicated jobs update to an identical status. BUT the case that is not covered<br />
is the situation where the end-user would like to capture a target multiple<br />
times, at different times. I believe the option "Remember Job Progress" might<br />
provide a solution there, but this is to be tested.</p>

<p>There is still work to be done as jobs won't update their capture count in all<br />
situations. This should be fixed with better control of the job's state, not in<br />
this function.</p>

<p>I believe this is still quite slow, less than before but still slow. Perhaps<br />
remove all logs from getCompletedFiles.</p>

<p>This change also re-evaluates job in different situations, to get a more reactive<br />
and always up-to-date interface. The objective is to never use the "evaluate"<br />
button except for really resetting jobs.</p>

<p>Also, added mitigation in the case findNextJob can't decide which job to<br />
select.</p>

<p>This change also works around issue with job definitely abandoned although they<br />
could be rescheduled later, eventually on another night. This also mitigates<br />
the issue with altitude cutoff, which apparently can't reliably determine when<br />
the target is rising instead of falling.</p>

<p>Also, removed scattered return instructions to clarify the algorithm. When a<br />
capture says "Complete", changed the state to "Evaluation" so that job properly<br />
recounts its captures and properly considers the work left to be done.</p>

<p>Fixed a few uses of QString::arg(). One call to QString::arg will replace all<br />
"%X" in the string. Next call to QString::arg will replace all "%X+1", etc.</p>

<p>A few additional fixes for scheduler jobs logs to use job's date format.</p>

<p>FIXME on attempting to request the local server (vs. client) for the number of captures.<br />
FIXME on refactoring the signature path, which is duplicated at several places.<br />
FIXME on fixing an issue with filter name, which doesn't get included in the capture path when there is no filter wheel, but still gets included in the signature (workaround: use a filter wheel sim).<br />
FIXME on finishedFramesCount variable, which is part of an unfinished mechanism and should be removed.<br />
FIXME on files counted in signature path, because all files are counted, not just captures.<br />
FIXME on duplicate scheduler jobs vs. duplicate sequence jobs.<br />
FIXME on altitude cutoff, which might cause jobs to loop over themselves until altitude is properly either allowing startup, or causing effective abort (3 degrees sidereal delay).</p></div></div><br /><div><strong>TEST PLAN</strong><div><ul class="remarkup-list">
<li class="remarkup-list-item">Logs: most of scheduler logs are now homogeneized to start with "Job 'xx'", for ease of reading. However, while they help on understanding what the scheduler is doing, there are probably too many of them.</li>
<li class="remarkup-list-item">Counting captures: sequences containing multiple jobs with the same signature should properly count their captures ; e.g. 2xLPR, 3xR, 4xLPR with 3xLPR done should properly count 3xR+1xLPR remaining.</li>
<li class="remarkup-list-item">Repeated scheduler jobs: capture count should display properly, accounting for the number of repeats, even if the job is set to run to sequence completion only for instance ; also, completion should check repeats too.</li>
<li class="remarkup-list-item">Capture enumeration: jobs should properly count the number of captures for a complex sequence, BUT ONLY if there is a filter wheel available, else will never find any capture.</li>
<li class="remarkup-list-item">Duplicate scheduler jobs: while duplicate sequence jobs are now behaving properly, duplicate scheduler jobs are clones and evaluate as if they were one single job ; that's not a change/regression, it's just clearer now.</li>
<li class="remarkup-list-item">Job evaluation: evaluation will now occur in various situations, adding a job for instance ; evaluation is still not stable (in the sense "same user visible input" => "same output"), but better than before.</li>
<li class="remarkup-list-item">Aborting jobs: aborted jobs will now be often re-evaluated, so that transitory errors are discarded to retry the job ; does not work as well as it could.</li>
</ul></div></div><br /><div><strong>REPOSITORY</strong><div><div>R321 KStars</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D12398">https://phabricator.kde.org/D12398</a></div></div><br /><div><strong>AFFECTED FILES</strong><div><div>kstars/ekos/scheduler/scheduler.cpp<br />
kstars/ekos/scheduler/scheduler.ui<br />
kstars/ekos/scheduler/schedulerjob.cpp<br />
kstars/ekos/scheduler/schedulerjob.h</div></div></div><br /><div><strong>To: </strong>TallFurryMan, mutlaqja<br /><strong>Cc: </strong>KDE Edu, narvaez, apol<br /></div>