Multiplicity 4.01 Release Changelog (Released 02/26/2025)

02/26/2025

Version

• UI: 4.01

• MultiplicityConfig.exe: 4.0.1.0

Platforms

• Stardock

Changes

• This adds text to KVM and seamless display modes to indicate what IP addresses it tried when failed to connect

• Adds in black-out remote displays option to KVM (need MP Business/enterprise)

• Resolves some connection issues with setups with multiple adapters and multiple IPs

• Reduces idle bandwidth usage for KVM mode

• Enhances performance for KVM mode and reduces memory usage

• Resolves initial crash problem with KVM mode in some situations

• Ensures remote connections will disconnect if the client end closes unexpectedly

• This resolves an issue with the previous build that stopped Seamless display working at all

• Also puts in some of the performance enhancements that KVM had into Seamless display

• Machines using Modern standby will now still allow connections if the number of displays is > 1 even if the primary display is off (this was in yesterdays too)

• Added some new translations

• Included supported laguanges. Community support can be found on github.

***Reserved***

I went back to Multiplicty 3 a couple of months ago because couldn't get anything to work with 4.

Trying update today to 4.01.
Everything works this time except KVM mode takes about 8-seconds to move anything to correct position on primary display.
High resolution mode didn't work at all.  

Under Seamless Display Always use the IP address ( 1700::....)  doesn't work to configure any machine.
Please check the firewall settings on he secondary (shold not be set to Publc /Guest, the computer name, and the IP address and you have he same encryption key.

With version 3 the IPV4 addresses were used and they work.  
Is this a network card issue like needing to allow IPV6 or something like that?

Spoke too soon.  KVM mode went back to being very slow.

Wireless

I can't use ethernet in this configuration because ISP supplying a mesh network for wifi.

3 other machines worked with Multiplicty 3

Just got this message even though all machines are configured for KVM.

You currently have no cofigured computers, or no computers are currently ready for a KVM connection.
You can configure computers from the Multiplicity setup window.

Never see IPV4 address in the Always use IP address (which is the same for all machines.)
IPV4 always showed in version 3.

friedram,

Click KVM from the left side panel while in Multiplicity 4.01

KVM Connections
Right click on a computer then click Create shortcut on desktop

Thank you- this worked for me. It's odd because the computer that I can connect to is actually "on" but it would not show up without unchecking the "only show computers which are powered on"

I agree. This is a bug that was introduced in this build.

Following the most recent update I can no longer control computer #2 therefore I no longer need this software. Not amused

• Streaming audio works for a few minutes, then fails.  Sometimes it recovers after a 1-2 seconds, sometimes it doesn't and starts working again if I switch the secondary to a different audio device.
  • Related, it's cute that that audio is streamed without a new audio device, but it's annoyingly annoying when the audio is not working: it keeps muting the actual device, so I need to disable that to hear the actual audio, but when it starts working again, I hear both audios so I need to disable the muting again and "where exactly was that damn muting setting?".
    
    
• Seamless display lasts for a few minutes and then fails.  What follows is a mess when MP's UI shows that it's connected when it isn't.
  
  
• The "UI" for controlling seamless displays is ... not really convenient. AFAICT, double-clicking in the main app connects/disconnects unreliably, and the only other option is the right-click menu on the system tray icon.
  
  
• OTOH, KVM does have its own UI, but one that is broken.  It tells me that "You currently have no configured computers, or no computers are currently ready for a KVM connection." which is clearly a lie since double-clicking the secondary in the main settings app works fine.
  And speaking about the KVM "UI":
  
  • The KVM sidebar thing is more useful, mainly because it actually works and shows the secondary computers. But that whole thing is a weird UI which is opened from the main dialog only (not even from the tray icon menu, and no shortcut key) -- BUT ... closed from the right-click menu on it.
    • When there are multiple secondary machines, the label-thumb-label-thumb makes it confusing to know which is which.  Having some space between them, or overlaying the machine name over the thumb would make it much less confusing. (There IS a thin line, but it separates the label from the thumb under it, which makes it more confusing if anything.)
    • Would be nice to be able to drag thumbs around to reorganize them.
    • Would be nice if this had streamed audio to the viewing primary machine.  (Yes, the main audio streaming is doing that too, but even if I don't set that up, I'd expect a remote KVM window to stream audio.)
    • Would be nice to "undock" it so it can float around anywhere I want rather than sacrificing a thick area on the edge of my screen.  (No, auto-hiding is not as useful, since the thumbs are very nice to see since they're updated.)
  • The tab implementation is working in a weird way, like the green title when "merging" a tab.
  • There is no way to have a keyboard shortcut to open a kvm connection on a specific machine. Having one would be useful.
  • Setting a key to open the KVM window does what it promises: it opens a NEW one every time it's used.  If you'd hit it a bunch of times in frustration of expecting it to do something useful, you get punished with a bunch of windows that you need to close.
  • Trying to resize the window is an exercise in sheer frustration: looks like there's a 1-pixel width of area that can be used to resize it.  Makes the logitech DPI switch thing kind of useful beyond just headshots.  (But still much more difficult than getting a headshot.)
  • The ScrLk thing kinda works, when it feels generous.  Every other time I use it, it doesn't feel that way, and just blatantly ignores me.
  • The handling of the mouse can get ... weird.
    • If it's hidden on the remote machine, it's also hidden locally.  So far so good.
    • But then when I move it, it stays hidden instead of how it should work.  Worse, it's hidden also hidden on the KVM's titlebar, which means that it's impossible to right-click the title and enable the always-show-the-mouse hack.
    • If the remote pointer setting is for an inverted pointer with a non-default size, and the remote has a much higher DPI, and the always-show-mouse option is on, things can get ... amusing.  With the pointer size in win 11's setting on 6, the local mouse grew to about half of the screen(!!).  On other settings (4 or less, 8 or higher) made it "just huge".  (I'm guessing that a size 8 made it be bigger that the local screen which made it avoid THAT hugeness.)
      
      
• Oh, and just for sheets and geeggles: yes, this version still suffers from locking down my inputs if the remote loses connection / reboots / crashes.
  
  
• Finally, I'll repeat my meta comment: please PLEASE ***PLEASE*** consider using a proper bug report thing.  Of the 150 bugs I listed here, I think that around 75 are ones that I mentioned in the past.  But there's no proper bug reports, just these ephemeral "threads" which will be shoved into the digital void when the next version comes out and you'll start a new thread.  And this doesn't have to be private: you could use GH for posting issues, which would make them publicly visible, and give you a whole bunch of modern stuff that people are used to.
  
  If you HAD a proper bug system, I'd post these things as separate issues, I'd be able to track them independent of this post becoming old news, you'd be able to mark new issues as duplicates when they are.  Everybody wins.
  
  As it is, I suspected that these posts are as effective as sending out an email which gets swallowed in some busy inbox and therefore forgotten after a short period. After using it for a while, this is confirmed: I know that as soon as you do another update and start a new thread, this one will get tossed to the bin in the corner of the room.

"With the Multiplicity 4.01 release, we are creating this thread so that users can report any observed issues. "

We are all reporting in "this thread" as instructed.

Obviously -- but the two machines in each case have no network issues (I have an open terminal connected via ssh, and it never drops).  And a terminal connection should be much less tolerant of an occasional hiccup than streaming audio/video.  Like I said, the audio sometimes recovers after a short time, and sometimes fails.

As for opening a thread for each bug -- I'm dealing with this thing by keeping an open tab -- doing that for around 20 bugs is unmanageable.  I'd also argue the "most effective method" point, considering how this is a general basic (old) social tool, and things like GH/GitLab issues are specifically designed for bug reports.

Given that it's impractical to create that many threads, and given what is clear but you said "we try to focus on one reported issue at a time" -- it's now clear to me that the ~2h I spent describing all of these problems is unlikely to be helpful since it will disappear in the dead thread zone soon.  Not much of a motivation on my side, for something that should be very useful for your side...

(BTW, just to be clear, I'm not trying to be snarky or annoying anyone: the basic idea of this swiss-army-knife of computer connections is a very appealing concept, and I would love it if these issues would actually be fixed.)