I am running a small home set up (less than 10 computers) with my own RU server for security, and this has been worked just fine. Until recently, when all of a sudden I cannot connect to and remote control one specific computer. I have tried just about "everything", including uninstalling the host and deleting all settings to start over a few times, but that makes no difference. I'm running the latest versions of all the RU software (host 188.8.131.52, viewer 184.108.40.206, and RU server 220.127.116.11), and I'm using "Custom Server Security" for all the computers. They are all configured exactly the same way and on the same physical LAN.
For the PC that Remote Utilities no longer can control the viewer will just show the usual message "Connecting to <computername>. Please, wait...
WHen I look at the log on the "host" computer, it looks like connections are established and ended normally, but the whole time the "viewer" window is just stuck with the "Connection to" message.
I can "Log on" to the computer in the "viewer" windows just fine so I see a miniature screen under "Logged on", I just cannot connect to it.
I didn't really think this could be a "missing display problem" as I havea few Intel NUC boxes with no display or display cable connected, and I can control them just fine. But not this relatively new AMD system with RTX 3070 graphics card, as soon as I unplug the HDMI cable I can no longer connect to it with Remote Utilities.
Now the whole purpose of using RU is to connect to such computers that are just left doing their things, with no need for an attached display.
Am I missing something here? RU is supposed to work even with no display connected to the "host", right?
How do I fix this issue so I can connect to the computer without having to have a display connected?
I did order a few of these "dummy HDMI plugs" that tricks the display card into believing that a display is attached, the kind that are usually used for "Mining rigs". But should that really be necessary?
Yes, when using Remote Utilities you should be able to connect even to a headless remote machine. Perhaps, the issue might have been caused by how the screen capture is processed inside the system with or without the physical monitor plugged in. Please try enabling the Use legacy capture mode checkbox in the Host Settings -> Other tab and see if this helps to resolve the issue. After enabling the checkbox please make sure to restart Host in order for the changes to be applied. Please note that it's also possible to enable the feature remotely via the Remote Settings feature.
Thanks, Pauline, enabling the "Use legacy capture mode" indeed solved the issue with this specific computer. Seems like it's necessary for some but not all "headless" computers to enable this option then, good to know, thanks!
Seems like it's necessary for some but not all "headless" computers to enable this option then, good to know, thanks!
Yes, such issues might be occurring only on some machines, depending on the graphics card used, OS (e.g. Windows 10 vs Windows 7) or some other parts of the machine's configuration. However, enabling the Legacy capture mode feature usually helps to resolve the majority of similar issues.
I understand this thread is old, but I'm having a similar problem with the remote host with three HDMI displays attached, but power is physically removed from the monitors using a smart outlet. Remote Utilities works fine when the monitors are powered, but I can only view/interact with the primary display when power is removed. Turn the power back on, and everything is like it should be.
I've tried updating the host and viewer and selected the legacy capture mode without luck.
Are there other suggestions you have that might help in this situation?
Would a headless adapter with a passthrough on the two monitors that drop out when power is physically removed from all the monitors help?
Yes, according to the messages from Christer above, this looks like a workaround that should work. However, in the meantime, I’ll forward the issue to our developers for a review, to see if we’re able to reproduce it in our environment and, if yes, to implement a fix for this issue.