D14684: Fixes for the Scheduler and Capture modules

[Eric Dejouhanet]

TallFurryMan planned changes to this revision.
TallFurryMan added a comment.


  Thanks a million for this test, I had a good time interpreting your results, until I found the prefix issue :)
  First thing with complex_jobs is that the warning indicating a duplicated job doesn't trigger for the second job because that warning is testing for the sequence file, not for the storage of the sequence file. That will have to be fixed.
  
  Second thing is: I could reproduce your progress bar at 100% at the beginning of a capture. I located the regression.
  
  Third thing is: I did not spot that specificity in the LRGB sequence first ; the prefix "EasternVeil" makes it store its captures to "/var/tmp/EasternVeil/EasternVeil/Light/*/EasternVeil_*" when run from the Capture or Scheduler modules.
  The LSOH_SO sequence will stores its captures to "/var/tmp/EasternVeil/Light/*" if ran from the Capture module, and to "/var/tmp/EasternVeil/EasternVeil/Light/*" if ran from the Scheduler.
  The name of the capture will be "EasternVeil_*" for the LRGB sequence, and "Light_*" for the LSOH_SO.
  Yes the code is not the same in scheduler.cpp and capture.cpp. Ah, duplicated code when investigating duplicated jobs...
  But this makes a mess of interpretation.
  
  This said, it's important to remember that in schedule complex_job, all sequence jobs store their capture in the same folder.
  
  In D14684#306578 <https://phabricator.kde.org/D14684#306578>, @mutlaqja wrote:
  
  > Thanks for the updates. Just tested again now with complex_job.esl and I already captured before, it is is perfect opportunity to test. It evaluated those the 3 jobs:
  >
  > 1. LRGB 20/20 --> Correct, it's done already
  > 2. LSOH 9/72 ---> Incorrect. It is 10/72. Since 6x L + 4x SII were captured for this job.
  > 3. LRGB 20/20 --> Incorrect since the job didn't even begin
  
  
  
  
  1. OK, fine, that means storage contains at (least) 5xL 5xR 5xG 5xB. This is the final count because of the prefix bug.
  2. 5xL is counted from the first job's, not 6. That the L captured by LSOH_SO are not counted is a direct consequence of the prefix bug.
  3. No that's correct, the second LRGB job has no repeats, so it's completed at the same time as the first LRGB.
  
  A schedule with jobs using the same storage (same target name, same FITSDirectory) only capture a frame type up to the maximum count amongst jobs, not to the sum of counts of jobs. Assuming, of course, that Remember Job Progress is enabled.
  
  I removed my comments for the second test you did, because the prefix bug is causing much headache :)

REPOSITORY
  R321 KStars

REVISION DETAIL
  https://phabricator.kde.org/D14684

To: TallFurryMan, mutlaqja, wreissenberger
Cc: kde-edu, narvaez, apol
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-edu/attachments/20180811/2e6dec25/attachment-0001.html>