Bug 400265 - Schedule with single frame capture does not initiate meridian flip
Summary: Schedule with single frame capture does not initiate meridian flip
Status: RESOLVED FIXED
Alias: None
Product: kstars
Classification: Applications
Component: general (show other bugs)
Version: 3.0.1
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Jasem Mutlaq
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-10-24 21:13 UTC by Wolfgang Reissenberger
Modified: 2018-12-30 12:33 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Wolfgang Reissenberger 2018-10-24 21:13:53 UTC
SUMMARY
Meridian flips are not initiated if a sequence has only one single frame captured - no matter how often the schedule repeats the sequence.

STEPS TO REPRODUCE
1. Create a capture sequence with only one single light frame
2. Create a schedule with this sequence, select a star close before meridian and set the schedule to "repeat until terminated"
3. Start the schedule before the target crosses the meridian.

OBSERVED RESULT
Even if the target crosses the meridian, a meridian flip is never initiated.

EXPECTED RESULT
As soon as the star has crossed the meridian, the next new frame capture leads to a meridian flip before the frame capture is started.

SOFTWARE VERSIONS
2.9.8 as well as 3.0.0
KDE Frameworks Version: 5.28.0
Qt Version: 5.7.1

ADDITIONAL INFORMATION
This happens only for sequences contain one single frame.  As soon as the sequence contains more than one single frame (e.g. LRGB), the meridian flip is running fine.

The reason behind is, that in processJobCompletion() it is checked if getPendingJobCount() > 0 before checkMeridianFlip() is called. For a single capture this makes sense. In case that a sequence is contained in a schedule that repeats this schedule, this restriction does not make sense.
Comment 1 Jasem Mutlaq 2018-10-25 05:23:19 UTC
The capture module also has no way to know if there "future" captures pending. In its own little world, once all captures are done, we're done. I'm not sure which solution would be fitting for this issue.
Comment 2 Wolfgang Reissenberger 2018-10-25 05:52:46 UTC
What about shifting (or adding) this check to preparePreCaptureActions()?
Comment 3 Jasem Mutlaq 2018-10-25 05:58:21 UTC
Yeah I'd imagine that could work. Can you check it out? Make sure it doesn't cause any regressions?
Comment 4 Wolfgang Reissenberger 2018-10-25 06:17:39 UTC
Well, promising that it does not cause any regressions is challenging for the Capture module :-/

But sure, yes, I will give it a try.
Comment 5 Jasem Mutlaq 2018-10-25 06:28:02 UTC
One possible problem I see is that the capture module might do focusing or dithering and then on the next capture, it decides to do meridian flip. So all the focusing/dithering would be a waste of valuable observing time.

So maybe the check should exist in both places.
Comment 6 Wolfgang Reissenberger 2018-10-27 20:03:36 UTC
It looks like the Capture module cannot detect the necessity of a meridian flip upfront.

The Capture module records the initial hour angle. If the initial hour angle is already west of the meridian, the Capture module assumes that a meridian flip is no longer necessary. This makes sense when the Capture module is used standalone. In combination with the Scheduler, it gets more complicated.

The easiest way I see is to set the initial hour angle from outside. But this needs a change in the interface.

Does that make sense?
Comment 7 Wolfgang Reissenberger 2018-11-25 21:03:50 UTC
Bug fix diff submitted: https://phabricator.kde.org/D17159
Comment 8 Wolfgang Reissenberger 2018-12-30 12:33:03 UTC
Fixed with diff #D17159 (see https://phabricator.kde.org/D17159)