Mouse stuck / lost on disconnect

Lose mouse control, Hidden mouse, Mouse stuck

I am wondering if anyone else is having this problem.

Basically I will lose all control of the main/local computer if the remote computer is rebooted or otherwise disconnected. For some reason Multiplicity will not switch or revert back to my main PC when the remote is disconnected and I will literally lose all mouse control. When that happens I literally have to try to force log-off or restart my main PC just to fix this; which is entirely counter-productive. 

I am struggling to understand if this is normal operation or if this is an issue. Why would Multiplicity not "fall-back" to the local PC when the remote is lost? Developers??? >:(  

I am considering switching to a competitors product because of this. Hopefully someone can point me in the right direction to fix this.

Thanks.

9,722 views 9 replies
Reply #1 Top

Hello,

I have forwarded your problem to Stardock Support team for their assistance. Please keep an eye on this thread for any updates. We appreciate your feedback and patience.

 

Basj

Stardock Community Assistant.

 

Reply #2 Top

Sometimes I am fast enough on a reboot of the remote PC that I can quickly switch back over to my main, but sometimes there is no time. But if I miss that opportunity then SOL. So if you were controlling the remote PC at the point in time the connection is lost then you're stuck without controls for either PC. Multiplicity needs to be able to detect the connection loss event and switch back to the local PC. 

 

To be clear in my terminology, if not already obvious:

Local/Main PC: The PC with keyboard and mouse attached used for control.

Remote PC: The remote PC being controlled.

 

In very rare occasions it seems to work properly and switch back to main. 

+1 Loading…
Reply #4 Top

Yes I've had recent internet issues on the remote computer I use Multiplicity on. Every time the computer loses connectivity and I am on that system I do not get control of my main system back without reboot. It would be great to have a way to reconnect to the host when the remote system has connection issues.

Reply #5 Top

Hello,

I have forwarded your report to the Stardock support team for their review and recommendations.

Please keep an eye on this thread for any updates.

We really do appreciate your feedback, thanks.

 

AzDude
Stardock Community Assistant

Reply #6 Top

Has there been any update or progress on this?  I am experiencing the same issue where I will have to hard reset the primary computer.  I haven't seen anything on this besides this post so I'm curious to see.

I have done the purge and reinstall on both machines and this continues to occur.

Please advise on next steps...

Reply #7 Top

Quoting dwdh586, reply 6

Has there been any update or progress on this?  I am experiencing the same issue where I will have to hard reset the primary computer.  I haven't seen anything on this besides this post so I'm curious to see.

I have done the purge and reinstall on both machines and this continues to occur.

Please advise on next steps...
End of dwdh586's quote

Please review this guide : https://forums.stardock.com/486104/multiplicity-support-faq#mousestuck . Do let us know if you still need our assistance.

Thank you,

Basj,
Stardock Community Assistant

Reply #8 Top

Should a connection be lost the control is always returned to the primary.  As a test if you unplug the network cable from either machine this should happen.  A check is run every 6 seconds to ensure the other end is responding so it can take upto 6 seconds for this to happen.

It is possible to set a hotkey to return to the primary which would be processed locally so should instantly jump back.  The only reason I could possibly think for it not returning at all would be something on the secondary computer not allowing the mouse to actually reach the border of the screen, or the process responsible for processing input (rather than accepting it from the network) having crashed out on the secondary.

 

Reply #9 Top

The hotkey idea seems to be the most logical workaround for the time being, thanks Neil - that was a great idea!