Many thanks for the feedback, I will issue an update the next days.

I found some minor things while playing around, but nothing serious:

Please visit https://phabricator.kde.org/D18020. This diff should fix the case.

OK, I already started to create the fix. But it is not that easy, unfortunately.

The initialHA is set incorrect in case that the initial HA is east of meridian. See inline comments above.

Ah, good point, that makes sense. Nevertheless, the current implementation relies on the fact that captures take place.

• Memory handling for mountInterface corrected
• Code cleanup, D-Bus method name harmonized

D-Bus excluded for KStars Lite

OK, I will put the wrapping #ifdef in SkyPoint.h and SkyPoint.cpp.

Meridian flip check executed before capture started (Update)

Commit range corrected

Exception handling added

Go ahead and post, I can integrate it to this differential.

et voilà...

I think I found the problem with the selection bug. The function reorderJobs() seems to be buggy and it does not look like a new bug.

With the option "Sort Jobs per Altitude and Priority" enabled, re-sorting in the edit mode leads to a wrong selection in the queue table.

There are some things that do not work correctly:

1. Select "Sort jobs by Altitude and Priority" and load a schedule with several jobs with priority 10. Now select a sequence for editing and change the priority of a sequence, e.g. first from 10 to 1. In my case, the job jumps on position 1. Up to here everything is fine. If you change it now to 15, it moves down, but the selection does not follow to the new position. In my case, the first line remains highlighted.
2. Change the option "Sort jobs by Altitude and Priority". No matter in which direction, the Scheduler tab is not updated. If the option is set, the jobs remain unsorted. If the option is not set, the position buttons are disabled.

From I simplicity point of view, I would recommend not introducing this flag, as long as we have the reset buttons. It's meaning might be misinterpreted.
... and it's behavior is different depending on whether the sequence has been freshly loaded or not.

I would agree, but as stated by Jasem, we would lose the use case "Anytime I Press Start, I Want All Jobs Processed" if we don't keep some sort of Remember Job Progress for the Capture module.
And we do see that the option is now different from the one used in the Scheduler.

OK, that's right. But in this case I would make this option directly accessible (and visible) in the Capture tab. All options in the Options tab bear the risk of being forgotten.

... and it's behavior is different depending on whether the sequence has been freshly loaded or not.

From a Capture perspective this sounds reasonable and very comfortable.

Sorry for the late response, looks good. One tiny thing: when changing list positions, evaluate... is multiply called. In all other situations I tested, it’s called only once.

Sorry for the distraction :-)
I meanwhile use the scheduler excessively and I have a lot of features in mind... But let's concentrate on making it stable as fast as possible.

I agree with @TallFurryMan, Capture and Scheduler should not overlap in terms of control logics. We should keep Capture as simple as possible and leave all history stuff to Scheduler.

Sorry, Eric, but arc patch complains about missing commit a651bd7ee7ba7ebba7e40f5b263021d534db14b6. It is neither in your repository nor in the main one (at least I cannot find it).

Just an idea: is it possible, that the correct name is parkingStatus?

Looks good, my tests succeeded. Excellent, this feature is very helpful!!

In D14942#335937, @TallFurryMan wrote:

In D14942#335844, @wreissenberger wrote:

Hi Eric,
I get an error message from arc patch

arc patch D14942
Created and checked out branch arcpatch-D14942.

    This diff is against commit 018f6986f3887648a6f31f0597de063a53a92675, but
    the commit is nowhere in the working copy. Try to apply it against the
    current working copy state? (40d75559189dabe735a9f9e55c0641ba86a58ef7)

Should I continue or otherwise where could I get the missing commit? It does not seem to exist in the GIT master

I'm sorry I have no idea... Is it that you should fetch the remote server before patching?

Hi Eric,
I get an error message from arc patch

arc patch D14942
Created and checked out branch arcpatch-D14942.

Same situation with the RollOff Simulator. The INDI Control panel shows:

2018-10-03T08:19:51: [INFO] Dome is unparked. 
2018-10-03T08:19:51: [INFO] Roof is open. 
2018-10-03T08:19:41: [INFO] Roll off is unparking... 
2018-10-03T08:19:18: [INFO] Dome is parked.

But the log in the scheduler shows as last entry

2018-10-03T10:19:41 Unparking dome...

OK, re-checked with the latest INDI version. No change.

I use the DomeSimulator working on arcpatch-D15837.

Hm, my differential does not work properly. There are several things:

1. Simply checking "unpack dome" after cancelling a scheduled job does not help. I need to double click on a job so that the change is recognized.
2. If I do it like this, the dome simulator unparks the dome and opens the shutter, but the scheduler does not continue. It looks "Checking INDI State 4".

KAuth::Action.setTimeout() requires KF5 Version 5.29. On my Raspberry, I only have 5.28 - resulting into a failed compile.

Ok, checked. I could reproduce it on master and with the patch the message disappeared.

Makes sense, DBUS should have priority.

I’ve seen the messages in my own logfile last night. I ca Test it late this afternoon.

Could you please be a little more specific with the test case? I cannot reproduce it yet.

The pros are that (a) the change is smaller and (b) there is no need to change an API. The cons are that (a) it makes the code more difficult to read and (b) we are talking of three occurrences, only inside of capture.cpp, where two are touched by this diff.

Functionally OK, but it is difficult to read. Wouldn't it be better to add a flag to resetStatus() which indicates whether the count should be kept or not?

Looks good, I could reproduce the problem and checked it being fixed against simulators.

Thanks for your rebasing, Eric!

In D15230#319940, @TallFurryMan wrote:

In D15230#319479, @wreissenberger wrote:

Looks good, my test cases with the duplicated schedule are running now. Two minor things that I found, but they are not critical:

• Having two jobs with the same signature both with FINISH_REPEATand the second to run has less cycles than the first one, the second is started and finishes after one iteration. But I think this not a behavior introduced with this fix. Just to be mentioned...

Ah, yes. Probably a regression or a side-effect of an older change. This use case is a bit weird (but possible of course), perhaps we should order duplicates per repeat count?
Also, I'm weighting the possibility to reorder the jobs in the list per startup order, so that it's clearer for the end-user which one will start before the other.

This happens also if you have two identical cycle numbers. The second one starts once and detects after one cycle that it is completed. It seems like there is no check that jobs once scheduled might get completed without a single run.

• When creating newFramesCountthere is no check whether it already contains the signature to be evaluated. This leads to duplicated calls to getCompletedFiles(). Functionally this is OK, but it makes the check slower.

Agreed. Perhaps I can add a check right now.

OK, checked, working.

OK - already done :-)

Looks good, my test cases with the duplicated schedule are running now. Two minor things that I found, but they are not critical:

• Having two jobs with the same signature both with FINISH_REPEATand the second to run has less cycles than the first one, the second is started and finishes after one iteration. But I think this not a behavior introduced with this fix. Just to be mentioned...
• When creating newFramesCountthere is no check whether it already contains the signature to be evaluated. This leads to duplicated calls to getCompletedFiles(). Functionally this is OK, but it makes the check slower.

Well, indeed, the feature name is not so self explanatory. But currently, the flag is not used inside of updateCompletedJobsCount(), right? As far as I understand, it is only used to estimate the duration. Looks like both methods could share a lot of code... OK, it looks like as there is room for improvement Capture.

Do we really to consider what happens on the storage? I would simply count a frame if it has been stored successfully. If it disappears at a later stage, why should we care?

OK, got the point, you are right. But parallel asynchronous jobs - hm. That also adds complexity.

Hm, I think the reason is the strategy how the cache is updated and not a pure invalid cache problem.

In D14942#317072, @wreissenberger wrote:

I did some tests, looks good. There is one test that already failed in D14684 and is still present. It might be exotic, but it leads to continuous looping.

The setup is the following: create a schedule with two jobs for the same target with the same sequence job (say 1xLum for example). The first job starts and captures the first frame.

And here is where the problem occurs: now calling Scheduler::updateCompletedJobsCount() detects the one frame, but when evaluating the second job (which did not run yet), the value in the captured frames map is overwritten. This leads to an endless loop of the first job.

Give this test case a try:

Another small thing: I observed that the counting update happens only after a single sequence is finished and not after each capture. I guess that's by intention...

Agreed, no, this issue should not block. If it's OK for you, I can try to fix it. I know the place where it goes wrong...

I did some tests, looks good. There is one test that already failed in D14684 and is still present. It might be exotic, but it leads to continuous looping.

Agreed. The issues I found are not that critical. The only thing that may happen is that a connection loss during shutdown leads to unfinished shutdown of the observatory. This can be fixed in a separate diff.

OK, now the scheduler does not crash any more, if the INDI server is not available during parking. But the scheduler module does not recognize that the job has finished. The "Stop"-button is still active and the spinning wheel on the right side is still running - although the text says "No job running".

OK, I squashed the two commits.

Bugfix for #397650 flat creation failed (Update)
Retry to submit the correct files.

I did a first check using a remote INDI server:

• Running a single scheduled job: works fine.
• Interrupting temporarily the INDI server during slewing and capturing: works fine, EKOS recovers.
• Interrupting temporarily the INDI server during parking: segmentation fault in Scheduler::manageConnectionLoss() in stopGuiding(). currentJob is NULL which leads to a runtime exception.

The only changes I made were in capture.cpp - in addition to the new test case. The diff of my changes is attached.

Oops, that was not the intention! I did a rebase in advance, so this small change includes a bunch of other changes. The only relevant change is that to capture.cpp.

Bugfix for #397650 flat creation failed (Update)
Separation of pure preview job from flat calibration preview now by calibration stage

Q_FALLTHROUGH() was introduced in Qt 5.8, but kstars supports Qt >= 5.4.0. Building on Raspbian Stretch (Debian 9) fails.

Captured frames map not handed over for FINISH_LOOP and FINISH_AT
Additionally, switch statement used instead of a simple if clause.

Aaaa, it seems like my changes now made it into the Phabricator.
I simply leave the captured frames map empty for SchedulerJob::FINISH_LOOP. The Capture module remains untouched. The behavior in the capture module is quite simple: since it does not find the signature in the captured frames map, it assumes that there are no frames - i.e. it simply executes the entire set - as desired. Quite simple...

Hm, it seems like my code changes did not find their way to this differential. Here is what I did:

Scheduler does not set captured frames map for SchedulerJob::FINISH_LOOP jobs.

OK, makes sense. My thought was that ignoreJobProgress was set via ignoreSequenceHistory() from Scheduler for infinite looping jobs, but never used in Capture.
I'll revert the change and shift this as proposed to Scheduler.

@TallFurryMan: OK, if you re-tested it, let's assume that I am making some mistake in obtaining the same codebase. Since I am very new in using the Phabricator, I wouldn't be surprised.

Hm, strange. I checked out the latest version of D14684, compile it and run the test. When I run it, the first of the two jobs loops endlessly instead of terminating after three runs. See the attached log file.

@TallFurryMan: I did not run the entire test set yet, but my problem mentioned on Fri, Aug 10, 2:19 PM still exists. The attached test case illustrate the wrong behavior.

In D14684#306156, @wreissenberger wrote:

Not sure whether the problem still exists after your changes, but I found a situation where the scheduler loops endlessly.

If you have two jobs with the same capture file signature (path + filter etc.) and the second has less repeats than the first, the first job will repeat endlessly.

The problem is that Scheduler::updateCompletedJobsCount() overwrites the map entry such that a later evaluation thinks that it has less captures than requested.

Please find included a test illustrating it. Place it under /tmp/kstars_tests

-Wolfgang

tests.tar.gz1 KBDownload

In D14684#306178, @TallFurryMan wrote:

Check https://secure.phabricator.com/book/phabricator/article/arcanist_diff/

Not sure whether the problem still exists after your changes, but I found a situation where the scheduler loops endlessly.

Sorry folks for the stupid question - but how can I get access to these changes? I cannot find the mentioned branch on GitHub.

I made a small correction in the log output: https://phabricator.kde.org/D14605

It seems like this patch is not in the current master of 2.9.7. The code I found in capture.cpp looks like https://phabricator.kde.org/D14280 and not the corrected version from https://phabricator.kde.org/D14309.

kstars/ekos/ekoslive/message.cpp has the same problem.

Yes, there is an update. I made all changes that Eric suggested and submitted a new version here: