<table><tr><td style="">TallFurryMan added a comment.
</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/D14684">View Revision</a></tr></table><br /><div><div><p>From the code perspective, it can't because it uses the same storage space as the first job. It is evaluated independently from the first job, and arrives at the same conclusion.</p>

<p>From the user perspective, the main objective of the scheduler is to ensure N captures are made, translating to X hours of imaging. One solution is to setup one single job with enough captures for say 60 hours of imaging, which will get partitioned over multiple nights. If you want to fit another job in-between, you can use START_AT/FINISH_AT fixed-time jobs, and still keep track of the number of captures.</p>

<p>There is still work to do on priorities, and interrupting jobs, which will make this feature clearer: jobs which update their priority at the end of a batch to let others run, or jobs which interrupt others when they are ready to start.</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/D14684">https://phabricator.kde.org/D14684</a></div></div><br /><div><strong>To: </strong>TallFurryMan, mutlaqja, wreissenberger<br /><strong>Cc: </strong>kde-edu, narvaez, apol<br /></div>