<table><tr><td style="">TallFurryMan created this revision.<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/D12396">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<br />
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<br />
capture path when there is no filter wheel, but still gets included in the<br />
signature (workaround: use a filter wheel sim).<br />
FIXME on finishedFramesCount variable, which is part of an unfinished mechanism<br />
and should be removed.<br />
FIXME on files counted in signature path, because all files are counted, not<br />
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<br />
altitude is properly either allowing startup, or causing effective abort (3<br />
degrees sidereal delay).</p></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/D12396">https://phabricator.kde.org/D12396</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<br /><strong>Cc: </strong>KDE Edu, narvaez, apol<br /></div>