Fixing ASTAP Path on OS X and Setting Autostar as default for PHD2 Guiding
ClosedPublic

Authored by lancaster on Oct 29 2019, 9:15 PM.

Details

Summary
  1. Fixing the default path for ASTAP on os x.
  2. Clearing the tracking box after a meridian flip because the guide star is no longer valid
  3. Moving the Meridian flip code that affects guiding to the guider where it makes more sense.

The changes were necessary because users reported that when using Ekos remotely controlling PHD2, but not using the autostar option,
after a meridian flip, the previously selected lock position is of course no longer valid, but Ekos still tries to make it use the previously selected star which moved.
So rather than trying to calculate the new star position based on a previously selected guide star, I believe it is better to clear the selected guide star.

Test Plan

Please test to make sure that this code does not cause any issue with doing the meridian flip whether the user is using PHD2 or the internal guider. Guiding should still start back up automatically as it did before.

And test that after a meridian flip when using PHD2, whether the user was using auto-star or not using auto-star, lock position that was previously selected is not selected any more.

This should now work for the internal guider as well.

Diff Detail

Repository
R321 KStars
Branch
master
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 18329
Build 18347: arc lint + arc unit
lancaster created this revision.Oct 29 2019, 9:15 PM
Restricted Application added a project: KDE Edu. · View Herald TranscriptOct 29 2019, 9:15 PM
Restricted Application added a subscriber: kde-edu. · View Herald Transcript
lancaster requested review of this revision.Oct 29 2019, 9:15 PM
lancaster edited the test plan for this revision. (Show Details)Oct 29 2019, 9:25 PM

Robert, Thanks. These changes do see to address my issue, and I believe would be an important improvement. However I have a couple questions/suggestions:

1- In the new method, Guide::guideAfterMeridianFlip(): Why would the issue be only related to PHD2? Wouldn't the internal guider also have the same issue? That is, after a meridian flip, the guide star's image position would change either when using PHD2 or with the native guider, so I would think you'd want to remove the "if(guiderType == GUIDE_PHD2)" test, and simply set autoStarCheck->setChecked(true); in either case.

2- I'm not sure the autoStarCheck->setChecked(true); inside of Guide::resizeEvent() is quite right. I would think we'd want to default this way if the user hasn't previously set a preference, but one he/she does express a preference, then the preference should be remembered across sessions. The way I read this is that it doesn't allow the user to keep his preference across sessions. So, I'd keep this as is, if the cross-session thing is complex, but would like the end-game to be restoring the user's preference.

Hy

Thanks Robert!

@wreissenberger Can you also take a look please?

1- In the new method, Guide::guideAfterMeridianFlip(): Why would the issue be only related to PHD2? Wouldn't the internal guider also have the same issue? That is, after a meridian flip, the guide star's image position would change either when using PHD2 or with the native guider, so I would think you'd want to remove the "if(guiderType == GUIDE_PHD2)" test, and simply set autoStarCheck->setChecked(true); in either case.

--I don't know the answer to this. I don't usually use the internal guider. Basically I put the check there because I didn't want to mess up any already existing behavior in the internal guider without asking first. Though if Jasem and others who use and wrote the internal guider thing that its fine, then no problem

2- I'm not sure the autoStarCheck->setChecked(true); inside of Guide::resizeEvent() is quite right. I would think we'd want to default this way if the user hasn't previously set a preference, but one he/she does express a preference, then the preference should be remembered across sessions. The way I read this is that it doesn't allow the user to keep his preference across sessions. So, I'd keep this as is, if the cross-session thing is complex, but would like the end-game to be restoring the user's preference.

--One note, this change is actually in the setStatus method. It runs when PHD2 is connected. it just looks like it is in the resizeEvent method due to the way it is displayed in Phabricator.

--So this is part of the currently existing behavior that you said was giving you trouble. Right now as far as I know, the auto-star checkbox selection should be remembered between sessions. I didn't write any code that would change that in my big PHD2 change, so that what you are saying is the current behavior to my knowledge.

--Also right now with the current behavior with Ekos and PHD2, if the user has auto-star unchecked but has not clicked on a star to force PHD2 to use that star for guiding, then it lets PHD2 select a star automatically and doesn't force it to use a different lock position. It is only if the user has auto-star unchecked and then the user selects a star to use for guiding in the guide image that it actually makes PHD2 use that star when guiding. So really you don't have to have auto star checked as long as you don't select a guide star it will still guide automatically.

--If in fact, you would prefer to keep the current behavior on this and not use my added line here that forces auto-star to get checked when you connect to PHD2, we can put it back to the current behavior. I added it because you said that autostar wasn't getting checked and you though it should be set that way each time for PHD2 when it starts up because it was giving you trouble

You said: --Also right now with the current behavior with Ekos and PHD2, if the user has auto-star unchecked but has not clicked on a star to force PHD2 to use that star for guiding, then it lets PHD2 select a star automatically and doesn't force it to use a different lock position. It is only if the user has auto-star unchecked and then the user selects a star to use for guiding in the guide image that it actually makes PHD2 use that star when guiding. So really you don't have to have auto star checked as long as you don't select a guide star it will still guide automatically.

Robert, I'm guessing the current behavior isn't quite as you describe. FWIW, when I was having my issues, I had auto-star unchecked, but I did NOT select a guide star manually, and yet EKOS was forcing PHD2 to use a particular guide star coordinate (after a meridian flip). Perhaps EKOS is determining PHD2's initial auto-star (pre-meridian-flip) the same as if the user had manually selected a star.

So Ekos uses the green tracking box as the coordinates that will be used to set PHD2's lock position. If the green tracking box has not been set, then PHD2 will automatically choose a star even if autostar isn't selected.

Oh but also it gets the information from PHD2 when it is guiding, so that when PHD2 starts guiding, if you are receiving the full guide frames, PHD2 gives its current lock position and then Ekos sets the green tracking box on the star it is guiding upon. So you are right, I guess PHD2 effectively ended up setting the lock position when it was guiding before and then later when it was told to guide again, the lock position that had been set was enforced. So you didn't click to track on the star, as I thought you must have, but effectively PHD2 did.

So yes you are right it wasn't exactly what I was thinking. But really if the user has unchecked autostar, that means they want to choose the star. The idea that it should default back to automatically choosing a star if the user didn't actually pick one is essentially a fail safe and it does work pretty well in that it does get a star even if the user didn't pick one. And I do believe that the change that I made in the other method should fix the issue you were having anyway, since it should let PHD2 pick a new star to guide upon if there is a meridian flip, which is when you had the issue anyway.

So if you would like I can remove that code I added for you because as you said, we do want to respect the user's wish to not have auto star selected between sessions.

The other question then is whether we should add a bit of code that says if the user has auto star unselected and is using PHD2, but then the user hits the guide button without having selected a star as they should, a dialog could pop up warning the user to select a star first to start guiding. Or should we just let PHD2 set the tracking star in Ekos as it does now?

@lancaster: I cannot reproduce the problem you described. With the latest KStars and latest PHD2, everything runs fine. After a meridian flip, in all cases I tried, PHD2 automatically selects a new star after the flip. Could you please give advise for a test case where PHD2 sticks to the old position?

@wreissenberger: I reported the issue to Rob. The issue comes up only if the "auto star" button is unchecked in the Guide tab. For me, 4 or 5 nights in a row last week I failed to guide after a meridian flip until I looked into the code and logs and discovered the root cause.

@rlancaste: I tested last night with your patch, and had no issues, even though "auto star" was unchecked. It worked!
Also, to address your comments:
1- I'm fine with your PR in general and would OK if it got submitted.
2- I agree that you should consider removing you change in setStatus(). what i meant to say was that *new installations* should default to having auto-star be checked.

All: In the guideAfterMeridianFlip() method, I would think that this same issue should affect the native guider, so I recommend looking into removing "if(guiderType == GUIDE_PHD2)" and would think that "autoStarCheck->setChecked(true);" should be applied to all guiders, but i haven't tested with other guiders, so can't say for sure.

Hy

I reported the issue to Rob. The issue comes up only if the "auto star" button is unchecked in the Guide tab. For me, 4 or 5 nights in a row last week I failed to guide after a meridian flip until I looked into the code and logs and discovered the root cause.

It would be great if you could share details, since I tried to reproduce the case without success. I had the "auto star" button unselected and checked it

  1. with a scheduler running - no success (I think the scheduler sets the button automatically)
  2. only with the Capture module running with pulse guiding - no success
  3. same, but ST4 guiding - no success

So either there is a magic option in EKOS/PHD2 or a newer version of PHD2 that makes the difference.

I replied to to Wolfgang's queston with a Reply-All email, since I was attaching a log and forwarding an email, but I see it went to everyone but Wolfgang.
Sorry about that. I'm now re-sending inside of phabricator and I'll try and make google drive links for the logs:

Here are the logs:

https://drive.google.com/file/d/1-4Yzdek2NP9UewZaO8XlYV5d4Pc0d2tZ/view?usp=sharing
https://drive.google.com/file/d/1smQr9hJ9DLj5HdR1eMH9tW01ePD_yPeI/view?usp=sharing

Here's the message:

Sure, here's the email I sent to Rob to start this off.
It should have most of the details, and I'm also attaching the two gzipped logs (KStars and PHD2) from that night and also below you can see my commentary about the logs.
Finally, I was not running the scheduler, and was running with pulse guiding. Auto-star was unchecked, and guiding with PHD2 failed after a meridian flip (because KStars insisted on a particular lock position which was not valid any more).
I was running head of the tree kstars from early last week. The issue results from the set_lock_position messages KStars was sending to PHD2.

Please let me know if there's something else I've forgotten to say,
Thanks,Hy


Rob,
Thanks for getting back to me. I wanted to describe an issue I had (and overcame) related to PHD2 and Ekos this past week.As I understand it, you're the one "in charge" of the KStars/PHD2 interface.
In short, all 5 times this week, my capture session aborted after an automated meridian flips failed late at night, where the reason for aborting was that PHD2 failed to settle after the flip. Upon a closer look at the log, I determined that the real reason it failed was that EKOS was sending PHD2 "set_lock_position" messages changing it's guide star position away from the coordinates on the guide image where it had selected a star, to the coordinates where the guide star used to be, pre meridian flip.  (Note--that set_lock_position message is not found in the log before the meridian flip).
Looking at the code, I saw that the "set_lock_position" message was conditioned on not having the "auto star" checkbox set, and sure enough I found that I had "auto star" unchecked in my guide tab. So, I fixed my issue by keeping the "auto star" EKOS checkbox checked, and my flip succeeded last night.
That said, I think the behavior of the system is probably wrong. E.g. Does not having "auto star" checked imply that one cannot do unsupervised meridian flips? Even if that was the case, sending the 'set_lock_position' to PHD2 with the pre-meridian-flip guide star coordinates is never the right thing to do--i.e. the image has inverted, so whatever star was in that position is not there anymore.  (Honestly, I wasn't even aware of that checkbox until I saw the reference in the code.)
I'm arguing that the 'auto star' checkbox is confusing, and perhaps should be 'greyed out and not used' when combined with PHD2. One can manually choose a guide star with PHD2's settings/UI if one wants. Having a 2nd control for that in EKOS makes things more complicated, and in this case probably does the wrong thing.
Since I'm sure you understand the code and various scenarios people use much better than I do, I didn't just send you a PR, but rather wanted to talk this through with you to make sure I'm not missing something.  However, if you agreed there was an issue, and preferred I send you a change for review, I'd be happy to do it. (I'd also be very happy to have you do it).
Let me know what you think, or if you have any further questions.Hy

In case you' want to see the details, I'm attaching my log where I diagnosed this issue. Note--I was running a branch of the master branch from last week--that code should be basically the head of the tree from around this past Monday, except that is also had a version of the change I just submitted related to fitsviewer and indiccd (see https://phabricator.kde.org/R321:c72edccbcdd475facd228718d0267b5c8d705ed7) which should be unrelated to PHD2 and guiding. There are some extra debug log messages in the log related to the capture of the GUIDE and NORMAL ccd images.
I gzip'd the log files. Here's my commentary about what happened.
Early in the log, PHD2 is running fine, and it's guide star coordinate is around 1207,43[2019-10-25T23:49:51.131 PDT DEBG ][     org.kde.kstars.ekos.guide] - PHD2: request: "{\"id\":27,\"jsonrpc\":\"2.0\",\"method\":\"get_lock_position\"}"
[2019-10-25T23:49:51.208 PDT DEBG ][     org.kde.kstars.ekos.guide] - PHD2: response: "{\"jsonrpc\":\"2.0\",\"result\":[1207.04,43.53],\"id\":27}\r\n"

This repeats many times, varying a little, I suppose because of dithering, and here's the last one before the meridian flip:[2019-10-26T01:42:52.398 PDT DEBG ][     org.kde.kstars.ekos.guide] - PHD2: request: "{\"id\":1783,\"jsonrpc\":\"2.0\",\"method\":\"get_lock_position\"}"
[2019-10-26T01:42:52.438 PDT DEBG ][     org.kde.kstars.ekos.guide] - PHD2: response: "{\"jsonrpc\":\"2.0\",\"result\":[1207.06,41.11],\"id\":1783}\r\n"

The meridian flip starts and guiding is stopped:[2019-10-26T01:47:08.565 PDT INFO ][     org.kde.kstars.ekos.mount] - Meridian flip: slewing to RA= "02h 31m 50s" DEC= " 61° 49' 54\""
[2019-10-26T01:47:08.566 PDT DEBG ][     org.kde.kstars.ekos.mount] - Setting meridian flip status to  4
[2019-10-26T01:47:08.566 PDT DEBG ][     org.kde.kstars.ekos.guide] - PHD2: request: "{\"id\":1786,\"jsonrpc\":\"2.0\",\"method\":\"stop_capture\"}"
[2019-10-26T01:47:08.567 PDT DEBG ][     org.kde.kstars.ekos.mount] - Slewing to RA= "02h 31m 50s" DEC= " 61° 49' 54\""
[2019-10-26T01:47:08.573 PDT DEBG ][           org.kde.kstars.indi] - ISD:Telescope sending coords RA: "02h 31m 50s" ( 2.53077 ) DE: " 61° 49' 54\"" ( 61.8319 )
[2019-10-26T01:47:08.596 PDT DEBG ][     org.kde.kstars.ekos.guide] - PHD2: response: "{\"jsonrpc\":\"2.0\",\"result\":0,\"id\":1786}\r\n"
[2019-10-26T01:47:08.597 PDT INFO ][     org.kde.kstars.ekos.guide] - "Autoguiding aborted."
...[2019-10-26T01:47:10.619 PDT DEBG ][     org.kde.kstars.ekos.guide] - PHD2: event: "{\"Event\":\"GuidingStopped\",\"Timestamp\":1572079630.577,\"Host\":\"raspberrypi\",\"Inst\":1}\r\n"
[2019-10-26T01:47:10.620 PDT INFO ][     org.kde.kstars.ekos.guide] - "PHD2: Guiding Stopped."
[2019-10-26T01:47:10.960 PDT DEBG ][     org.kde.kstars.ekos.guide] - PHD2: event: "{\"Event\":\"LoopingExposuresStopped\",\"Timestamp\":1572079630.960,\"Host\":\"raspberrypi\",\"Inst\":1}\r\n"
[2019-10-26T01:47:10.961 PDT INFO ][     org.kde.kstars.ekos.guide] - "PHD2: Looping Exposures Stopped."

The meridian flip slewing and alignment completes successfully, and EKOS restarts guiding[2019-10-26T01:49:03.067 PDT INFO ][     org.kde.kstars.ekos.align] - "Target is within acceptable range. Astrometric solver is successful."
[2019-10-26T01:49:03.072 PDT INFO ][   org.kde.kstars.ekos.capture] - "Post flip re-alignment completed successfully."
[2019-10-26T01:49:03.077 PDT INFO ][   org.kde.kstars.ekos.capture] - "Performing post flip re-calibration and guiding..."[2019-10-26T01:49:03.083 PDT DEBG ][     org.kde.kstars.ekos.guide] - PHD2: request: "{\"id\":1787,\"jsonrpc\":\"2.0\",\"method\":\"guide\",\"params\":[{\"pixels\":2,\"time\":10,\"timeout\":45},false]}"
[2019-10-26T01:49:03.102 PDT DEBG ][     org.kde.kstars.ekos.guide] - PHD2: event: "{\"Event\":\"LockPositionLost\",\"Timestamp\":1572079743.099,\"Host\":\"raspberrypi\",\"Inst\":1}\r\n"
[2019-10-26T01:49:03.103 PDT INFO ][     org.kde.kstars.ekos.guide] - "PHD2: Lock Position Lost."
[2019-10-26T01:49:03.112 PDT DEBG ][     org.kde.kstars.ekos.guide] - PHD2: response: "{\"jsonrpc\":\"2.0\",\"result\":0,\"id\":1787}\r\n"
[2019-10-26T01:49:03.145 PDT INFO ][           org.kde.kstars.indi] - ZWO CCD ASI1600MM Pro :  "[INFO] CCD FOV rotation updated to 5.81971 degrees. "
[2019-10-26T01:49:06.281 PDT DEBG ][           org.kde.kstars.indi] - processBLOB()
[2019-10-26T01:49:06.281 PDT DEBG ][           org.kde.kstars.indi] - processBLOB() mode  2
[2019-10-26T01:49:06.286 PDT INFO ][           org.kde.kstars.fits] - Reading FITS file buffer
[2019-10-26T01:49:06.361 PDT DEBG ][     org.kde.kstars.ekos.guide] - PHD2: event: "{\"Event\":\"LoopingExposures\",\"Timestamp\":1572079746.290,\"Host\":\"raspberrypi\",\"Inst\":1,\"Frame\":1}\r\n"
PHD2 eventually finds a guide star.
[2019-10-26T01:49:06.903 PDT DEBG ][     org.kde.kstars.ekos.guide] - PHD2: event: "{\"Event\":\"LockPositionSet\",\"Timestamp\":1572079746.903,\"Host\":\"raspberrypi\",\"Inst\":1,\"X\":706.572,\"Y\":664.507}\r\n"[2019-10-26T01:49:06.903 PDT INFO ][     org.kde.kstars.ekos.guide] - "PHD2: Lock Position Set."
[2019-10-26T01:49:06.915 PDT DEBG ][     org.kde.kstars.ekos.guide] - PHD2: event: "{\"Event\":\"LoopingExposures\",\"Timestamp\":1572079746.903,\"Host\":\"raspberrypi\",\"Inst\":1,\"Frame\":1}\r\n"
[2019-10-26T01:49:06.916 PDT DEBG ][     org.kde.kstars.ekos.guide] - PHD2: event: "{\"Event\":\"StarSelected\",\"Timestamp\":1572079746.905,\"Host\":\"raspberrypi\",\"Inst\":1,\"X\":706.572,\"Y\":664.507}\r\n"
[2019-10-26T01:49:06.916 PDT INFO ][     org.kde.kstars.ekos.guide] - "PHD2: Star Selected."
Looking at the PHD2 log, we see it was set to 706, 66401:49:06.903 00.000 3019972624 setting lock position to (706.57, 664.51)
...01:49:13.857 00.001 3019972624 Changing from state CALIBRATED to GUIDING
...01:49:13.886 00.000 3019972624 setting lock position to (705.90, 664.56)

But for some reason, EKOS asks PHD2 to change its lock position back to 1207, 41 (about where it was before the flip)[2019-10-26T01:49:17.577 PDT DEBG ][     org.kde.kstars.ekos.guide] - PHD2: request: "{\"id\":1791,\"jsonrpc\":\"2.0\",\"method\":\"set_lock_position\",\"params\":[1207.06005859375,41.11000061035156,false]}"

PHD2 receives this requests and changes it's pre-flip lock position01:49:17.766 00.211 3019972624 evsrv: cli 0x22a5480 request: {"id":1791,"jsonrpc":"2.0","method":"set_lock_position","params":[1207.06,41.11,false]}
01:49:17.766 00.000 3019972624 SetCurrentPosition(1207.06,41.11)

Settling eventually fails and the mission is aborted.[2019-10-26T01:51:08.093 PDT INFO ][     org.kde.kstars.ekos.guide] - "PHD2: Settling failed (Guiding stopped)."
[2019-10-26T01:51:08.095 PDT INFO ][     org.kde.kstars.ekos.guide] - "PHD2: Settling failed, aborted."

it restarts several times after, but always EKOS insists on the lock position from before the flip, and PHD2 always fails there.
I did get guiding running that night, by restarting PHD2 and KStars/EKOS (even though I didn't have the "auto star" checkbox checked).

Ok yes, so then I should remove that one line, I misinterpreted what you said in the first place to mean that you thought that every time it should default to having autostar checked when PHD2 is used as the guider unless the user disables it specifically. I don't think it should cause any issues except with the meridian flip and this patch will fix that anyway.

lancaster updated this revision to Diff 69079.Oct 30 2019, 9:29 PM

Taking the one line back out

lancaster edited the summary of this revision. (Show Details)Oct 30 2019, 9:31 PM
lancaster edited the test plan for this revision. (Show Details)

I took the one line back out.

I'm not sure if we should change the KStars/Ekos default for checking the autostar box. Currently the default is false, I just checked.

I'm not sure if we should change the KStars/Ekos default for checking the autostar box. Currently the default is false, I just checked.

I would warmly recommend changing the default behaviour to auto-star.

For me it's questionable if we should override the auto-star selection in case of a meridian flip. When somebody decides not to use an automatic star selection, why does he want's to be guided when a meridian flip happens? Simply select auto-star and everything is fine.

But I can live with it, if after a meridian flip the auto-star option is always set.

Regarding the internal guider, the situation is worse. Currently, even if auto-star is selected, the position does not change after slews. See this discussion here: this thread in the INDI forum.

Wolfgang,

Actually, I wouldn't be surprised if the thread you're pointing to is really talking about the problem that's being fixed in this PR.
I bet that if that person selected "auto star" his issues would be fixed, and/or if we removed the "if(guiderType == GUIDE_PHD2)" in this change.

Hy

I was not aware that the tracking star still being selected when guiding resumes after a meridian flip was affecting the internal guider as well? From the forum you posted, I'm not sure I'm clear if this is part of the problem or the whole problem they were having. Clearly though the one person at the start of the thread didn't have the clear mount calibration option set and that was causing issues with the internal guider. Is it also still trying to track the old guide star after it moves/flips?
Hmm. Maybe I will try this out when I get a chance.

I did think of another way we could solve Hy's problem without checking the auto star button if its preferable. We could just shut off / clear the tracking box position, so then it will be as if the tracking star had not been selected. I actually am thinking this makes more sense than turning on the autostar checkbox from a user's perspective because basically the old tracking star position is no longer valid so the box should just disappear.

Thoughts?

That sounds OK to me.

We could just shut off / clear the tracking box position, so then it will be as if the tracking star had not been selected. I actually am thinking this makes more sense than turning on the autostar checkbox from a user's perspective because basically the old tracking star position is no longer valid so the box should just disappear.

Very good idea, far better than setting the checkbox!

The problem in the thread I posted is, that the tracking box stays in place although the mount has moved. I simply haven't found a way to clear the tracking box position to resolve the problem. So if you can resolve it here, we could use the same method for the other problem. But let's keep it separated, since the other one might be tricky to separate dedicated slews from dithering.

lancaster updated this revision to Diff 69130.Oct 31 2019, 6:45 PM

Clearing the tracking box after the meridian flip rather than setting autostar.
Also doing it for both Internal Guider AND PHD2, instead of just PHD2.

Please see if this is any better. Also make sure it works!

lancaster edited the summary of this revision. (Show Details)Oct 31 2019, 6:50 PM
lancaster edited the test plan for this revision. (Show Details)

Hm, unfortunately, the CCD simulator does not turn the frame upside down after a meridian flip. So after a flip, the stars are exactly the same, what makes it difficult to test. Any ideas?

Wolfgang: Re testing, if you look at the log, WITHOUT this change, even if the stars didn't "flip" after the meridian flip, you should see Ekos sending a "set_lock_position" message to PHD2 at some point after the meridian flip (I'm not sure what happens with the internal guider). If the simulator's stars are in the same position post-flip, then set_lock_position won't hurt it, but the message would still be there. This message is what screwed things up in "real life".

With this fix, there should NOT be a "set_lock_position" command sent.

I'll also try and test it "live" tonight with the auto-star button unchecked.

wreissenberger requested changes to this revision.Oct 31 2019, 7:38 PM

At least for the internal guider, guideView->setTrackingBoxEnabled(false) is not sufficient. This method does not clear the guiding star position, the tracking box remains where it was.

This revision now requires changes to proceed.Oct 31 2019, 7:38 PM

It did work for PHD2. There must be something else for the internal guider.

lancaster updated this revision to Diff 69140.Oct 31 2019, 8:58 PM
lancaster edited the summary of this revision. (Show Details)

Clearing starCenter variable

Please see if clearing the starCenter helps.

Yepp, that's it. Well done, Robert!

wreissenberger accepted this revision.Oct 31 2019, 9:44 PM

Accepted.

This revision is now accepted and ready to land.Oct 31 2019, 9:44 PM

I'm glad, this is a better solution than just turning on auto star.

mutlaqja accepted this revision.Nov 2 2019, 7:04 AM

Great job Rob!

This revision was automatically updated to reflect the committed changes.