Sure, many thanks for your help!
 

Same scheduler file incremented by one day. 
 

I was thinking I was being overly too agressive with immediate retry and 30s wait last week but forgot about it. I'll be changing that to 300s.

It looks like the problem starts at 04:50:31.395. Here focusing and aligning both try to access the camera. What I do not understand is, why the focus module gets active while alignment is running.

Do you have the autofocus option set on the Lum filter that it should focus on filter set? Because focusing starts directly before align reports "Changing filter to Lum..."

Yes I have autofocus checked for each filter. Also I remember checking "focus on filter change" somewhere, but couldn't find the option in current version.

Alignement is set to run using Lum filter and that night I was shooting Ha frames.

Hm, OK, there might be the source of the problem. I guess you also use the focus step in the scheduler job, right? If yes, which filter is set on the focuser tab?

Yes indeed I have focus checked for all targets/sequences but the flat one.
I am not sure I get your question, initially I have Lum set in the focuser tab, but it changes according to my sequence filter.

It looks like we have a concurrency issue here somewhere with autofocus on filter change and alignment. It looks like the filter change for alignment triggers a refocus, which from my perspective does not make sense.

But that’s speculation, one run of a similar scenario got stuck, the next run went smoothly.

I think your hypothesis is strong.

I have noticed that during alignment it switches filter sometimes. Sometimes before alignement, sometimes after, sometimes it focuses the "previous target" filter sometimes the Lum filter.

I think I found one reproductible case: Right after meridian flip is completed, it will do an alignment, followed by one focus on Lum and then a focus on target filter.
Another case I saw, when it doesn't manage to do focus, it seems to revert to focusing Lum filter at some point.

Perhaps this together with a concurrency lock could cause the issue I have.

I went through a few analysis files and could find one, with filter changing behavior:
 
 

and one with reverting to lum filter:
 
 

I think I found the explanation.

The problem happens around 04:46:59. When your job IC_1805-Part2 reaches its end time, capturing was suspended due to guiding problems. And just after the scheduler aborts capturing and guiding, the guider reports at 04:46:59.644 a guiding deviation below the limit. Since a guide deviation also leads also to an ABORT state in Capture, the Capture module restarts the aborted job - that's not good! You can see this in the entry at 04:47:00.730 where capture reports capturing a 300s Ha image.

After this, I guess the capture module remains in the wrong state and will behave in an unexpected manner.

In such a situation, I'm afraid the only solution is restarting KStars.

Many thanks for your help, yes that makes so much sense.

I think, at least I hope  , this is linked to my aggressive 30 sec wait before retry aborted job.
Increasing it should help if not solve. I have set it to 300s, waiting for some clear, but not too much , skies to test it 

The problem should be fixed now. If you want to use it immediately, please build from sources. Otherwise, please wait for version 3.5.7 to come in a couple of weeks.

Jeez thank you so much!

Well heavy snow is forecast today and tomorrow, followed by two weeks of disgusting weather ^^ It is almost like when buying new gear 

But if weather does cooperate I will compile it and provide you with feedback, is it best to comment the pull-request or report here?