Bug fix in Scheduler for pausing after capturing sequence
ClosedPublic

Authored by wreissenberger on Jun 2 2019, 7:37 AM.

Details

Summary

Pressing the "Pause" button of the Scheduler module did not work properly when a capturing session was running. The scheduler paused the scheduler job after the capture sequence was completed, but pressing "Start" afterwards did not continue the execution.
In addition, the "Pause" button turns checked as soon as the scheduler pauses.

Test Plan

Start a Scheduler Job and press the "Pause" button at any stage of the scheduler.

Diff Detail

Repository
R321 KStars
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
wreissenberger created this revision.Jun 2 2019, 7:37 AM
Restricted Application added a project: KDE Edu. · View Herald TranscriptJun 2 2019, 7:37 AM
Restricted Application added a subscriber: kde-edu. · View Herald Transcript
wreissenberger requested review of this revision.Jun 2 2019, 7:37 AM

Would it be possible to state a sentence describing the use case for that change? Like "I want to...", eventually multiple sentences. I don't disagree obviously, but this would help progressively gathering a list of specifications.

I guess you do not mean the bug fix part. For this the use case is very simple: "I want it working :-)"

In addition, I want it being visible when the pausing state is reached. In fact, we have two stages: "pausing" and "paused". By pressing the pause button, we enter the stage "pausing". This is especially visible in the case that the pausing button has been pressed during a capture sequence. In this case, the Scheduler waits until the capturing sequence is completed. As soon as the capturing sequence is completed, the Scheduler reaches the state "paused".

To visualize this, during the "pausing" stage the pause button is inactive. As soon as the "paused" stage has been reached, the pause button gets checked and obtains a red background.

My intention for this diff is delivering a minimal set so that pausing the Sequencer works properly. Having this in place, I could continue the Observatory diff D21291 and add a communication from the Observatory that pauses the Scheduler in case of warnings and stops it in alert case.

From a mid term perspective I would like to go further:

  • Should pausing of the Scheduler trigger pausing of Capture? Currently it waits until sequence completion.
  • Is it really necessary having both sleeping and pausing capabilities in parallel? Sleeping is invoked when Scheduler wants to wait for the current job's starting time to be reached. Pausing does more or less the same without having a defined end.
  • The status messages of the SchedulerJob are slightly misleading when the Scheduler is paused.

Does that answer your question?

First I need to say I haven't built your differential, so my comment is from code and explanations only. So I'm not sure I understand the diff properly.

Originally, the pause button was aborting the capture, but kept guiding running. I don't know precisely what the historical implementation wanted, but I assumed the idea was to stop the scheduler, fix things in the observatory manually, then continue. Examples would be adjusting focus, restarting a capture that would be thrown away or simply fixing cable mess before it would interfere. Your differential now has the scheduler finish the capture before pausing. To me this is a drastic change in behavior which requires clarification. I can't confirm the examples I gave are still manageable with the change you provide.

Second concern is about Scheduler being paused or aborted by the Observatory module: this is not what we agreed on. We wanted Scheduler to remain the orchestrator of the observation. As such, Observatory had to notify states, and Scheduler had to manage those states. Unless there was a safety issue, in which case Observatory still notified the emergency but took action directly in its own domain.

More on this later on when I have time :(

Eric, please be so kind and test the pause button on the current master without this diff. There you will see that after pressing the button a) the Scheduler waits for a capture sequence to complete and b) when you press the "Start/Resume" button after the sequence completion, nothing happens.

So from my perspective, this diff brings back the originally intended functionality and nothing else. If we agree with this, I would like to go further step by step as mentioned above. Especially utilising the pause function of the Capture module seems quite natural when pressing pause in the Scheduler.

Regarding the Observatory module and the interaction, let's discuss this in D21291.

Oh don't get me wrong, I completely agree the current state is bugged, and I could reproduce the issue with the pause button, no issue there. So this diff is obviously important! I should have made this clearer in my post, sorry.

My point was about the effect of the pause button. I was asking for a use case in order to consolidate the feature the pause button is offering. What does it pause, and what can be done during this "pause".
I understand you restore a previous behavior, and while I'm not entirely clear on what that previous behavior was and what use case it was supporting, I completely agree with you.

Now if we can't find a suitable use case, my suggestion would be to drop the feature.

Testing now.

Hi Eric,
no problem, I not made out of sugar :-)
Indeed, I think this feature makes sense - exactly as you described it. Pausing - for example arranging cabling or testing a better guiding setup - makes sense. My typical setup is shooting LLLRGB sequences. When I have the ability to pause in order to fix something and capturing continues exactly the place where I paused, this would be nice to have (but maybe not more).

Restarting is a heavier exercise, since it executes slewing, plate solving etc. Having this in mind, I would opt for keeping this feature.

My suggestion: let's get it back working and add the capture pausing feature afterwards. I would take over implementing this.

OK?

Testing with a random target with only tracking got me an assertion abort on the dark sky score in the first 30 seconds I manipulated... What regression is this... Twilight isn't functional anymore?

TallFurryMan accepted this revision.Jun 3 2019, 7:46 PM

That's a real bug actually: we are in the period where dusk and dawn are on the same day! So observation time is later than both dawn and dusk...

Well, anyway, back to the pause button, from my few tests:

  • Pause is functional
  • When pausing while slewing, slew does not finish and pause does not settle
  • When pausing while capturing, sequence finishes

There are many things we can discuss. OK.

This revision is now accepted and ready to land.Jun 3 2019, 7:46 PM
mutlaqja accepted this revision.Jun 11 2019, 9:54 AM
This revision was automatically updated to reflect the committed changes.