SharpCap Forums

Hi Robin,

Lately, I’ve been having recurring issues connecting the mount via the sequencer. I use GreenSwampServer (GSS).

I usually connect to it using the following sequence steps:
If GSS crashes while the sequence is running, I am generally forced to reload the same sequence, which generates a new instance of GSS.
On this second attempt, the SharpCap sequence seems unable to establish a proper connection to this new instance (#2). However, no error is displayed.

It is only when a step like is reached that the entire sequence terminates with the error message "RPC-Server not available. (0x800706BA)."
Could it be that a reference to the original instance (#1) still persists?

The error can easily be reproduced with a minimal sequence:
Once the sequence has finished running, you can disconnect, close, and restart GSS via its own GUI.

If you then run the sequence above again, the problem occurs.

If you don't start GSS yourself but let the sequence handle it, no new instance is created at all.

The only workaround I’ve found so far is to restart SharpCap as well.
Regards,
StarFlea

Hi,

what happens if you try a 'MOUNT DISCONNECT' (or use the SharpCap UI to untick the 'Connected' check box) after the error has occurred? I think that would clear out the previous (now broken since it was connecting to the dead GSServer.exe) COM proxy in SharpCap, allowing a new one to be created when you try to connect again.

On my side, I am going to revisit the code that handles reporting the connected state of the mount - at the moment it is too trusting that the state will remain connected once it has been set to connected, which masks the issue of the GS Server application having crashed from lots of things in SharpCap until you try to actually do something with the mount.

cheers,

Robin

Yes, I’ve actually tried that already. Everything works again after a DISCONNECT.

The problem, of course, is that you don't know when the server might drop the connection during a sequence. If the DISCONNECT is scheduled for the end, it won't even be reached if the server crashes.

Does it make sense to include a blanket DISCONNECT at the very beginning of the sequence—before the CONNECT—something like this:
?

Hi,

it certainly wouldn't hurt as it would ensure that a new connection is made if necessary - you could also put a disconnect into any error handling blocks in the sequence.

Have you reported the issue with the GSServer crashing to the GSServer developer(s)? While looking at this has turned up an anomaly in how SharpCap deals with the problem, once other software starts crashing you are likely to end up in a situation where full recovery may not be possible, so it's best for the crash not to happen in the first place!

By the way, for the next update of SharpCap 4.2 I have changed the behaviour around how SharpCap deals with this sort of situation. Instead of assuming the mount stays properly connected once it has connected, SharpCap will check the mount for connection a couple of times per second (as it checks the current RA/Dec/Alt/Az co-ordinates regularly). If the mount driver starts to give errors (rather than a valid yes/no answer) on the connection check, SharpCap will assume it has disconnected (or at least failed in some way), show an error notification and update UI to show the mount as no longer connected. This will clean up the lingering broken COM connection to the mount so that a reconnect will work if the original issue has been resolved.

As a relatively significant change, we will have to see if this works out OK or if it surfaces more issues that have been lurking without being reported.

cheers,

Robin

Hi,

I’m actually not sure if I can reproduce the issue with the GSS. The GSS had originally hung—possibly a deadlock—and I had to restart it manually. That’s when I noticed the problem with the sequencer...

You’ve certainly put a lot of work into this!
How would SharpCap react if the connection to the original instance could be restored (e.g., after a temporary disconnection)? Is that possible, or would it explicitly require a new instance?

In any case, this will make SharpCap a bit more robust, even though such incidents can never be completely avoided! Thanks!

Hi,

I think that SharpCap would happily reconnect to the original instance if it suddenly came back to life (at least if you disconnect then reconnect). This is all a byproduct of the GSServer.exe being an out-of-process COM singleton server for the ASCOM driver, so as long as it is still running and alive, other applications requesting to talk to that COM object should get routed to it. The funny thing is that this sort of COM stuff was all rapidly becoming 'legacy' technology when I started doing Windows development back around 2000, yet we still use it...

I am thinking that I may allow one or two retries (ie that the connection check has to fail 3 times in a row over a second or two) before flagging the mount connection as lost - that should reduce the chance of false positives if something fails to respond once.

cheers,

Robin

Hi Robin!

I've thoroughly tested your changes, and as far as I can see, everything works perfectly, even when I manually close GSS occasionally.

Thanks a lot!

Cheers!

Flo
(StarFlea)

Hi,

glad to hear that worked - I will give it some time to get settled in and have some wider testing to see if any new issues arise due to this change. If that all works well then I will make some changes to make sure that all the other hardware devices follow a similar pattern of checking the connection status.

cheers,

Robin