I think I found a way to correct the counting of frames for the case that remembering is ticked off.

https://bugs.kde.org/show_bug.cgi?id=405901 related?

As mentioned above, right, this is an existing problem, but this diff neither addresses it nor makes it worse. Should be fixed separately.

Well, filling the map in any cases will not help, because the intention of not ticking "Remember progress" is exactly, that we start counting from zero - no matter how many are in the file system.

Your comment about capture_completed is right, I'm trying to fix it. The problem is, that captures_completed = schedJob->getCompletedCount() is called for each sequence job entry and added to totalCompletedCount, i.e. the total amount of the entire capture run is added multiply.

@TallFurryMan: Absolutely not, that's the nature of discussion. And I appreciate the ambition of making a sports car out of it :-)

OK, @TallFurryMan , I give up :-) Here is the alternative with the score calculations shifted to SchedulerJob: D20068.

OK, agreed.

Removal of table dis-/enabling completed.

Active job selected, enabling/disabling queue tables removed.

By the way: I found out that the null pointer exception occurs also when there is only one scheduler entry. So I think it's quite urgent that we at least fix this issue...

Better than the rather arbitrary limit of 15. But why -15 and not -90? And what about changing the maximum to 90 instead of 89.9?

Currently I am reluctant interfering directly since I am not really familiar with style sheets. I understand that it follows the CSS syntax, but I do not want to override a single place with fixed values.

Now rows might only be selected when capture or scheduler are idle.

Job table disabled when capture or scheduler are running

Please check my comments, from my point of view everything should be fine.

Right, that's what I first thought. But does it really make sense that a scheduler job rates its own score? Shouldn't be the rating of a job something that we would like to keep outside of a single job? That's why I came up with the idea to shift it to a separate class being associated with the Scheduler keeping the scoring logic.

Hm, seems like both changing it and leaving it have good arguments. What about if we freeze the scheduler, leave it currently as it is and concentrate on refactoring as begun in D20001? Doing both in parallel might be too much...

Ouch, that's embarrassing to admit, but I simply forgot to test this case :(
I'm afraid, scheduler and capture take the values at least partially directly from the UI and not from the model.

I have done both. But relocating the functionality to SchedulerJob has the problem, that calculations for weather and darkness are not specific to a scheduler job. In fact, weather and darkness are properties of the entire schedule, not of the single scheduler job.
And yes, the idea points exactly in that direction that we may have several ones. In fact we have two: one where the sequence is set manually and one where the sequence is sorted by altitude. But both use the same scoring strategy. See ScheduleStrategy as base class.

This does not work with multi-night setup. Suppose I have a scheduler list with Light + Calibration frames at the end. When I run it daily, I expect it to finish whatever is left. If only calibration frames are left what happens? It tracks and focus and guide on what? What if I only had dark frames left?

What type of setup do you have in mind? In case that there is a separate scheduler job for the calibration frames, it simply depends, whether guiding etc. is selected in the scheduler job. If it is not selected, no guiding will happen, right?

Rebased on the current head. From my perspective, it is mature enough to be merged into master.

Makes sense, it's more obvious this way. If somebody enforces guiding while capturing flats etc - he should know what he is doing.

This diff contains a severe bug. Please apply D19840 to resolve it.

At any rate, is this good to go now and reliable?

From my perspective, yes.

Value changes to meridian flip setup exposed to D-Bus

Now the activation of buttons should prevent moving list entries when the scheduler is running. But in both the scheduler and in the capture module, enabling/disabling buttons is distributed. Should be cleaned up somewhen...

• Moving sequences enabled only if state is idle
• Typo in job selection corrected

OK, understood. I will change the signal handling such that they are using the D-Bus.

Good point, I will check enabling/disabling for capture and scheduler. At least I did not change anything intentionally, so I would expect it has been before. But nevertheless, let's clean it up here.

Hello, could we get this D19528 and then D19393 merged? We'll continue from that baseline, which is factually better than the trunk state. Thanks!

Whom do you mean with we? Generally spoken, yes, makes sense.

Bugfix for emptying queues in scheduler and capture

Created an index violation in clearSequenceQueue() - needs to be corrected.

setMeridianFlipValues is not a DBus function? doesn't need to be added to the Mount.xml file?

No, I changed based the implementation on slots and signals. Changing a value in either capture or mount sends out a signal and the other side receives it and sets the values accordingly. This seems to me a more elegant way than using calls via DBus.

Shall I give it a try?

Sure, and I have suggestions :) let's do this really step by step. At the extreme, because the source is so complex, I'd say let's go function by function, ensuring that they match features.

Fully agreed! Wouldn't it better if we lead this discussion in a separate thread or on the kstars forum?

Weather check GUI update shifted to syncGUIToJob

Well, horrible is such a strong word :-P Fully agree! Remember, the idea was making the scheduler job more intelligent. Shall I give it a try?

Looks good, both restarting aborted jobs and the cutoff limit work fine. If I am the only one who doubts the necessity of a cutoff for the altitude limit, let's go. Maybe a hint in the hover help about the existence of the parameter might be helpful.

Hm, I am not so sure whether such a cut-off makes it better. At the end we have two parameters that describe the same limit. For me it was confusing, because I was not aware of the additional cut-off parameter.
Regarding re-sorting completed/error/invalid jobs, I would vote against. We have two modes for the scheduler: either manual sequence or automatically sorted. In the manual sort, I would prefer no change of the order at all. With the automatic sort, that's another story, there it makes sense.

I would have expected abort of the first job and continuing the second one. What type of restriction do you use?

I tested it with the first job with an Alt restriction of 15deg, but it seems not to work. The scheduler changes to sleeping mode when Alt reaches approx. 18deg. Bug or feature?

Restricted to handling aborted guiding.

I think I could easily separate restarting of aborted jobs from the rest quite easily. Just give me 1-2 h to check it...

I propose you keep your differential focused on restoring functionality after a guiding failure, even if the aborted job isn't managed that well afterwards (that means not bypassing of aborted jobs at the beginning of evaluation).
I will rebase D19393 on yours, and add a fix to the block removing jobs that are not to be evaluated, so that aborted jobs are kept in place and not touched until they are the only ones remaining.
In this context, I will tackle both the re-evaluation without order change and possible state instabilities like the altitude restriction causing the job to repeatedly abort and reschedule.

What do you think?

Agreed. James should keep in mind, that your fix should be landed shortly after mine is merged. Without fixing handling of aborted jobs, capture first tries to restart guiding five times, then aborts the job and as a next step restarts it again. That's not nice, but we can live with if for a short timeframe.

In D19528#424942, @TallFurryMan wrote:

Oh wow, so you investigated that too? I have the same observation about aborted jobs! Did you have a look at D19393? Coincidence :)

Nope. Maybe you should add me as a reviewer? :-)

I need some time to examine the part about guiding : we need the suspension feature to be usable both with and without scheduler, and reading this I don't readily understand if that's OK.

Suspending works in both modes. If used with the scheduler, the scheduler thinks simply that capturing is running although capturing is suspended. Restarting a suspended guiding is handled by the capture module.

About aborted jobs set for restart, the approach here is slightly different from D19393. D19393 is not trying to restart aborted jobs, only making sure they don't interfere with other jobs, specifically when the scheduler is running. I needed to include the scheduler running/not running part, but I don't recall why now (I'm in business trip).

Ah, interesting, I have to take a closer look at it.

So that's cool, but needs careful tests. I'll try to do that beginning of this week with the simulators.

Fully agreed! One thing with aborted jobs is not so nice currently: They are put at the end of the list, i.e. sorting of targets is changed, when aborted jobs get restarted.

In D19528#424928, @mutlaqja wrote:

That's great! A few users reported issues regarding this problem.

Good to know that I'm not alone :-)

What about when internal guider loses a star and reacquires it? I don't believe that's registered as an aborted guiding, right?

I haven't found a way hot to test lost guiding star directly. As far as I know at least PHD2 tries to re-aquire a guiding star. If this fails within a certain amount of time, it aborts.

Updated to latest master version.

Posted the remaining in D19456.

In D19429#422370, @mutlaqja wrote:

I've already included the changes in the committed version.

Side effects removed.

In D19426#422069, @TallFurryMan wrote:

Good point! Would you care to make the whole line selected too in an additional diff? Right now the selection is per cell, which is confusing.

In D18235#403245, @alainz wrote:

Selecting checkbox in the Capture tab alone is not sufficient, the Mount Tab checkbox must be selected too, Right?

At the end, the values on the Mount tab count. But when you start an imaging session from the Capture tab, the values from the Capture tab are forwarded to the Mount tab and overwrite the settings there.

The fact that we have two places whith meridian cflip checkbox and setpoint is a bit confusing to me and will probably raise many questions by other users later on, but this is a cosmetic thing, the code works!

Agreed. I would prefer shifting it from the Capture tab to the Scheduler tab, since the Scheduler contains data of other tabs as well. But I do not want to make the steps too big.

I did not see the meridian flip beeing forwarded from capture to mount tab, I still had one value in capture tab and another in mount tab, and the value in mount tab is the one that triggered the flip. Is my interpretation correct?

The value from the Capture tab is not forwarded immediately when changing the values on the Capture tab but they change, when you press the "Start" button on the Capture tab.

In D18235#403009, @alainz wrote:

I just checked the changes and confirm it is running as expected (tests 1 to 4)

Great, many thanks!

I noticed that the capture.ui still contains "Meridian Flip if HA" input field and interfers with the field in the mount tab when capture sequence is started.

That's left there intentionally so that imaging sequences can hold meridian flip parameters. As soon as an imaging sequence is started, its meridian flip setup is forwarded to the Mount tab.

In D18235#402892, @TallFurryMan wrote:

D18627 requires attention. Is it compatible/complementary/unnecessary with this diff?

I think we come close to a version that could be integrated into the master.

• Postponing meridian flip added when mount is not tracking
• Cosmetic change: meridian flip text message box spans two columns

Bug fix for post meridian flip alignment. Hopefully now it's working.

In D18235#402013, @mutlaqja wrote:

Thanks I just tested this in my observatory. The flip was started, but it got stuck on post-flip alignment. The alignment actually finished OK, but it seems no signal was sent to capture module regarding this. Please check.

Problem confirmed, I'll work on it.

Next iteration, now with improved handling of stopped tracking during waiting for meridian flip. It's not perfect since capturing is waiting until the meridian flip takes place, but at least worth testing.

Currently, there are problems when you stop tracking. After restarting tracking, the meridian flip is not executed.

Meridian limits set when capture starts and not when the imaging sequence is loaded. Nevertheless, the user may change the limits at any time manually. But each time the imaging sequence is started, it is set to the value of the imaging sequence.

In D18235#400606, @mutlaqja wrote:

Is the Meridian control in the mount tab synchronized with the one in the capture type? It seems when I activated (checked) the meridian control in capture, nothing happen to the control in the mount tab.

Not yet to the full extend. Currently it is only propagated from Capture to Mount when a sequence file is loaded.

In D18235#400589, @mutlaqja wrote:

mount.cpp and mount.ui still fail to patch :(
meridianFlipTimeBox is not in the ui file.

Should be corrected now, I chose the wrong commit base for the diff update.

• Manual rebasing through cherry picking
• Status text for planning pause added

In D18235#400029, @mutlaqja wrote:

Can you please rebase again? I can't apply the patch now to test.

In D18235#398781, @TallFurryMan wrote:

There's something I'd like clarified.
First, if the mount is set east of the meridian at an original position, and is not tracking, and we wait long enough that if it was tracking, it would flip. What happens if we then start tracking from that eastern position? Do we get an unneeded and ineffective flip request?

No, we don't. If we stop tracking, the meridian flip state is set back to "none" and nothing happens. As soon as we turn on tracking, a new target position is set. When this target position crosses the meridian, a flip is requested and executed.

Second, if a capture overlaps the meridian flip, I don't readily understand whether the capture is aborted, the flip executed, and the capture restarted, or if the capture continues and delays the flip, potentially for very long.

Nope, that’s why I introduced the request-accept mechanism. The mount requests to execute a flip, as soon as the meridian has been crossed by the given distance. If a capture is ongoing, capture answers with „wait“. As soon as the capture is completed, capture interrupts the sequence and sends an „accept“ to mount. Now mount executes the flip. As soon as the flip is completed, capture continues.

• Meridian flip timeout corrected to 2 minutes

In D18235#398264, @mutlaqja wrote:

Ok looks like it's clear tonight, so I'm ready to test it. Do you think you can add the non-tracking case as well today?

diff span corrected

• Meridian flip only executed when mount is tracking

In D18235#398264, @mutlaqja wrote:

Ok looks like it's clear tonight, so I'm ready to test it. Do you think you can add the non-tracking case as well today?

I had it running during the lunar eclipse on Monday and it ran fine. So for normal operations, it should be stable enough to test it in reality.

• Meridian flip during paused imaging sequence corrected
• Meridian flip during capturing sequence corrected

OK, I could reproduce the case. The problems occur when tracking is stopped while Mount is in the state FLIP_WAITING. In this case, things get out of order.

In D18235#396775, @mutlaqja wrote:

I also don't think meridian flip should be done when the mount is NOT tracking.

In D18235#396579, @mutlaqja wrote:

Does this also check if the mount is parked? Because now I'm getting meridian flip attempts with the mount parked! I didn't apply the above patch yet, but under the live system it behaves this way.

Meridian flip during paused imaging sequence enabled

I haven't tested this case yet, but no, there is no check yet. Will be fixed soon...

• Mount control of meridian flip for schedules added

• Error handling for failed slew for meridian flip added
• Mount meridian flip stati renamed to FLIP_... to avoid confusion with Capture flip stages
• Mount no longer exposes initialHA and currentTarget via D-Bus