Yes that makes sense. At the same time a check is done for the job progress and I think the way I plan my subs for each filter is a problem as well. Or rather, Ekos is not designed for that way. I do series of 9 x L, 1 x R, 1 x G and 1 x B and repeat those all the time until I have enough data. So when the job progress is checked first a check is done for 9 x L, which are found because there are more than 9 x L. Then 1 x R (found as well), 1 x G (found as well) and finally 1 x B (found as well). Then is simply takes the next job which is ... 9 x L and it starts there. But actually this is a restart since the scheduler already passed that point. Just now, for instance, it was supposed to take G sub #3 but it restarted at the second 9 x L.

In any case, I have attached the sequence file and the scheduler file of tonight. Thanks once more for looking into this!


Wouter

For the yesterday's session I think I found the explanation. It seems like the meridian flip exactly occurs between two schedule jobs. At 22:46:17, the scheduler job for NGC2841 is completed. At the same time, the meridian flip is necessary and is triggered as soon as the last frame has been captured.

This is a bug in the meridian flip mechanism of EKOS. The good news: It only occurs when the meridian flip is necessary exactly during the last frame of a job is taken and a second job is waiting for execution.

I will try to fix it asap.

Wolfgang

Here an update, I can reproduce it now. The situation that you experience happens, when the meridian flip limit has been reached when a) a capturing sequence takes the last frame in the sequence and b) there are capturing sequences waiting to be executed. It is independent whether you have one or more scheduler jobs. I think I can fix it the next days, so please have a little bit of patience...

Wolfgang

OK, a bug fix is submitted: phabricator.kde.org/D20150

I've posted a new differential that fixes this: phabricator.kde.org/D20151