With regards to using a private network, this is purely a case of the default firewall rules being set to only allow traffic when on private/work networks.  It would be unwise at best for a product to open the firewall for incoming connections to ports when on a public network too by default! as public networks should always be considered untrusted.  Obviously you can alter the rules to open them but the product doesn't have a way to do this right now for you.  There is some logic in saying we offer a setting to do so however for those who are comfortable with this.

The thing is that (at least with everything I've ever seen on windows) it was always not a concrete indication for having an actual public/private connection.  In fact, I vaguely remember running into cases where I needed to make it public for whatever reason.

In any case, if it's only a matter of politeness before opening my ports, it would be much better to just ask me for permission and allow me to say that it's OK.  That would have been a trivial decision on my part (since I know that I'm on my home LAN anyway), compared with the ~2hrs I spent on figuring out how to change my network setup (see in the other thread: I didn't have a way to change the private/public, and with more windows stuff using hyper-v becoming popular, this will happen more frequently).

Another indicative sidenote: it's obviously not the first time I'm fiddling with the windows firewall -- and I did check it yesterday for the ports.  But what I didn't think about is to ensure that they apply to both private/public, since I almost never see rules that are added to only one.  (Again, when I'm on my home lan, behind my router's firewall, the whole thing becomes mostly a moot point.)

If a connection is lost within 6 seconds you should have control returned to the primary automatically.  Multiplicity has always worked like this so I am surprised it didn't do this for you.  I will get this checked.

I've probably had enough things broken because I just resolved the network thing, that recreating this is probably hopeless...  (Which is IMO yet another argument for getting my permission regardless of a public network

Seamless display does not alter the resolution on the secondary (it has no logic for that), the resolution options on the primary would control the resolution exposed to the primary but the remote end will always use the native resolution.  So assuming you mean the laptop itself changed I cannot explain how your laptop changed resolution. 

To be more precise, it's not the actual resolution that changed, but the scale factor: it's normally set to (the recommended) 250%, and it somehow changed to a 100%.  I didn't look more into it since I got into a "unbreak stuff asap" mode...

You can use the right click menu and pick Disconnect all.  This should only be greyed out if there are no open connections.  Likewise the submenu for Seamless display should have a tick next to the connection that is active.  You can also double click on the connection name in Multiplicity config seamless displays page if it says connected by it.

Actually, something else that change in all of the network mess is that my laptop decided (for unrelated reasons) to change its name -- which I used in Multiplicity.  So as I was playing with things, I switched from the name to the IP address.  So perhaps there's some bug in keeping track of connections when that's done -- like maybe thinking that the by-name connection is still alive along with the actual IP connection--?

You can also move the mouse on the laptop (using its physical mouse only) and move to the top of the screen and click X in the right corner, or turning off the laptop will stop it.

Finally killing Multiplv64.exe on the primary would achieve this (though not an ideal way   )

Ah, thanks -- I'll remember that next time I try it...

And yes, killing it was me exhausting all other options to release myself...

I suspect given the greyed out disconnect all option that something is interfering with how the tray menu knows that an active seamless display connection is in use.  This could potentially be linked to some sort of security software being silly as we use a globalatom for this so perhaps something is preventing access.

I explicitly don't have any kind of extra security stuffs beyond the standard windows defender.  Maybe that's also due to the network tweaks and/or the fact that I restarted / unloaded it a few times?

However, 'clicking it' (not sure what that means exactly) is not required.  Sound exchange should 'start' the moment the setting are correct.

As a test, if you swap what is the sender and receiver (Primary \ Secondary is irrelevant for this), and have the proper credentials, does it just work?

Yes, "clicking it" = "right-clicking the audio tray icon".

I did have the proper credentials + IP entered -- but it sounds likely that all of this was a byproduct of me fighting with the network issues...

No one and nothing is 'skipped'.  Its just after a release, there lots going on.

Yes, older hardware could experience KVM rendering issues with older hardware. 

There should have been a check for that, where it would fall back to the 32-bit version.  We will look into this straight away and post something about it in a future release. 

That was a lot of work on your part and we appreciate the find and time, tsukasa198.

Sean Drohan
Stardock Product Lifecycle Manager 

In other words, with v3, I only needed 1 license to install on multiple computers and I assumed it was the same for v4. Is this not the case?

Its very likely that, during the MP4 installation, you accidentally clicked that you wanted it to be a Primary.  If you kill the activation window,, MP4 should ask you if you instead want to make it a Secondary - do so.

Sean Drohan
Stardock Product Lifecycle Manager

Hello there,

I got my copy of Multiplicity 3 on Steam. 

Saw this beta today and installed on my two main PC's. 

But when I try to flip my primary pc to primary, it says "Unable to activate this computer".

I then tested it on my secondary, same thing. 

Might be a good thing to put somewhere on the page that says "Multiplicity 4 Beta" and then right below it "Try it Free".

This is not a good introduction for a new product. 

Super frustrating.

It should be available to download as a trial.  The Try it free button should take you here : https://www.stardock.com/products/multiplicity/download-trial

This should download the build, though be careful you don't have any ad blockers which might interfere with it.

This is what I did, I uninstalled Multiplicity 3 on both computers. Then I downloaded from https://www.stardock.com/products/multiplicity/download-trial.

Installed on both PC's. 

I'll try again with your instructions. My response was based on basj's reply.

Is this error being seen when connecting to a Secondary with an older CPU, one that does not support AVX2?

You can use this link to find out if that processor supports AVX2:

https://www.avx2checker.com/

Sean Drohan
Stardock Product Lifecycle Manager

Quoting bnash01,

reply 43

Yep! You nailed it. Nice work. The secondary computer is an Intel Core i7 4960X CPU circa 2013. Guess it's time for an upgrade. Thanks for the info. 

 

The next build should fallback to the 32 bit version if your computer lacks newer instruction set support so it will run though slower.

Hi All,

I recently purchased the upgrade to Multiplicity 4 KVM Pro.  Installed on my Primary PC over the top of Multiplicity 3.60.  All good so far.  I then installed on my Windows 10 Secondary machine, and again, after configuration, everything seemed good and I could KVM to that secondary.

Then came the issues.  I installed Multiplicity 4 on my Windows 7 x64 system.  This machine is important in my network as it has an old SVHS Video Capture card that only has working drivers for Windows 7.  To my horror Windows 7 is no longer supported by Multiplicity.  You get a warning during installation, but the install can continue, and Multiplicity 4 seems to be functional on the Windows 7 Secondary system. The troubles start when attempting to enable Audio transfer to the Primary system, and Multiplicity complains that it cannot find the named Primary system.  But ignoring the Audio problem, the Primary system cannot KVM to the Windows 7 Secondary, saying that the secondary is not the same version, even though they are both version 4.

After a lot of trial and error, I had to give up.  I uninstalled Multiplicity 4 KVM Pro from each machine and went back to version 3.60 which works perfectly on all my systems.

What a shame that you have dropped support for Windows 7, although I do understand that it is very much 'Legacy' software.  What might be nice would be if it was possible for a version 4 Primary to be able to connect to a version 3.60 Secondary, so that support for older hardware/systems could be retained.

I paid my money and took my chance, but this time I lost.