Multiplicity Pro 4.0.0.4/NordVPN mouse issue

Mouse cursor becomes extremely slow/unresponsive in KVM mode the instant it enters the secondary PC. Once you're able to finally get the mouse cursor back to the primary PC, the mouse cursor movement returns to normal on the primary until you move it back to the secondary. This only happens at power on and on resume from hibernate on the primary PC. There is no problem on resume from sleep.

I have isolated this unwanted behavior to occur whenever NordVPN was shown running in Task Manager (it is set to autorun at startup but not to auto-connect to VPN). So now, at every power on/resume from hibernate, in order to get the mouse cursor to move normally within the secondary PC, I have to use the following workaround (this only has to be done on the primary PC):

[Click 'Quit App' from the NordVPN system tray icon then select 'End task' on 'NordVPN' in Task Manager.]

The mouse cursor then immediately moves correctly within the secondary PC. I can now run NordVPN if I choose to and the mouse continues to function properly across the primary and secondary PCs until I restart the computer or resume from hibernate (at which point I have to perform the steps above again.)

NordVPN has a lot of security settings, and I have tried it with all features on and all features off to no avail. Even with its option selected to not allow background processes, at program exit from the system tray, the cursor is still problematic in the secondary PC. I do not have this problem with Multiplicity 3 KVM Pro.

2,915 views 5 replies
Reply #1 Top

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

Do note that Stardock currently on Holidays, Support might be slow. We appreciate your patience.

Thank you,

Basj,
Stardock Community Assistant

Reply #3 Top

If Nord were set to a manual startup (or 'delayed' that can be set if its a service - which I suspect it is), and you make the KVM connection, is all fine then as well?

Is so, I am not certain how we can help here as it seems to be a 'race' (in the chaotic process that is a wake \ startup) that MP is somehow getting put to the back of the bus (so to speak).

In any event, it would be interesting to know the results of the test.

Sean Drohan
Stardock Product Lifecycle Manager

Reply #4 Top

The purge fix was short-lived. The cursor problem returned yesterday after several power on/off, restarts, and wake from hibernate cycles. Sean, I also tried your suggestion and changed Nord from auto-start to delay/manual start but the results were inconsistent between the power/restart/wake sessions whenever I ran Nord. Wake from hibernate results were all over the place. I even started getting 7-15 second delays at the start of each KVM session before the mouse would respond correctly. Eventually, each test ended up failing.

So, I went back to my original startup setup. I then selected the 'Always use the IP address (192.168.x.x)' option in the Primary PC KVM settings. I have been testing this setting since last night. So far, every single power on/off, restart, wake from sleep, and wake from hibernate cycle test, with Nord set to auto-start and auto-connect to VPN, has resulted in the correct (and instant) mouse movement within the secondary PC. 

Hoping this indeed resolves the issue and is not also short-lived. I'll update the post either way.

Reply #5 Top

Quoting OutpostDEaD, reply 4

So, I went back to my original startup setup. I then selected the 'Always use the IP address (192.168.x.x)' option in the Primary PC KVM settings. I have been testing this setting since last night. So far, every single power on/off, restart, wake from sleep, and wake from hibernate cycle test, with Nord set to auto-start and auto-connect to VPN, has resulted in the correct (and instant) mouse movement within the secondary PC. 
End of OutpostDEaD's quote

That is interesting and makes a bit of sense.  Remember, you can add connections that way as well, it does not have to be hostname

Thanks for the update.

Sean Drohan
Stardock Product Lifecycle Manager