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

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

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

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.

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).

And when I extended D19393 to reinclude aborted jobs when all went aborted (same idea as yours) I got state instabilities when the altitude restriction kicked in. The altitude restriction has a cutoff when scheduling, and not when running, to cater with preliminary steps requiring time before capture empirically.

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

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.

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.

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? :-)

That patch was unfinished, but my obs setup accepts a list of differentials to apply when updating itself so I pushed it without reviewers. I like the fact that we both found the same issue at that location :)

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.

Agreed, that's really cool.

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).

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.

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?

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.

Agreed.
It seems the situation is still better than before with your patch. I should be able to push a diff tonight, based on yours. I can rework the part where you bypass the aborted job, and eventually rebase if you change your diff. No problem.

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

Thanks, I'll start from here.

Is this good to go or better wait until D19393 is complete?

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!

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.

That was a "we" for both authors, but the incentive is of course for Jasem to merge if he accepts :)

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