Depends on how you have set up your install script. If you specify 'sudo make install' then it will install and overwrite the previous installation. If you just compile, you can run that version by calling up kstars in the build directory while leaving your (old, stable, nightly,....) installation untouched.

Hi
I've several versions installed for testing. I always run these from the build directory.
I'll check I have the latest version.
Cheers

*+EDIT: OK, found it. Wrong cmake foider. DUH! Sorry for the noise.
It's in git master now anyway.

Hi everyone
So the branch was committed to master but then reverted.
Dunno how or what to test.
Anyone?
Cheers,
Steve

My fault, folks. The merge request contained a serious bug, that't why this feature has been withdrawn. Please wait until it gets fixed.

Wolfgang

Hi Wolfgang
NP.
Is this it?

commit 5918f0b48c559e83a3de77d84a47de541b3351c7 (HEAD -> feature_realign_after_guiding_failure, origin/feature_realign_after_guiding_failure)
Author: Wolfgang Reissenberger <This email address is being protected from spambots. You need JavaScript enabled to view it.>
Date: Thu Aug 20 15:55:06 2020 +0200

Bug fix for correct handling of job stage when the guiding state has been reached

Cheers,
Steve

Hopefully, and it does not create regressions.

I will have a test run this night. @Steve: it would be great if you test it as well.

Wolfgang

Hi Wolfgang, everyone

OK. Not much success I'm afraid. Even when I cover the guidescope, the guiding continues without any stars (sic). I managed one abort. log attached.
This may have something to do with hot pixels but I thought SEP looked after that. Subtracting a single dark frame doesn't help either. I think it introduces more noise. Maybe we need a dark library of averaged dark frames as in PHD2 or a minimum hfd for star choice to prevent guiding on hot pixels. Or WHY.

Cheers and thanks for your work,
Steve

Hi Wolfgang
Here's the latest test.
Problem: The scheduler does not move to the next job. There are three batches of ngc6888 followed by 8 batches og m31. The scheduler fails after the change of target.

log, esl etc:
drive.google.com/drive/folders/1z_s1cQ6w...IngF7-4P?usp=sharing

Cheers,
Steve

Thanks for testing. The change looked rather trivial - that's why I was too relaxed with testing.

Poo, it looks like it is awfully more complicated than I thought. One problem that I see is that it might happen that an aborted guiding is provoked by the scheduler - e.g. by a meridian flip. OK, we could discuss whether it is a good idea that the mount simply starts to slew as long as no capture is running - and leading subsequently to an aborted guiding. But that's how it is currently.

Conclusion: We at least need to carefully think about this feature. So sorry, it seems like a longer way...

Wolfgang

Hi Wolfgang
is this perhaps why the scheduler failed in my test last night?
Just trying to organise time for tonight as I have other stuff to test too but of course I'll persist here if I can be of assistance.
Cheers

I haven’t checked your logs yet, but I wouldn’t be surprised.