So after clarification of the expected behaviour, I think the only bug was that it didn't re-email the re-generated host code. I'm also assuming the Viewer displaying the online clients only upd ate Version string after connecting to it, not when it determined it was online.
The code is emailed only once. You can tell if the Host sent the email by looking at the Host log after installation. There should be a record about that.
And no, the upgraded host did not have single password checkbox enabled. As you said, that is expected if I select it to auto generate the host password. I might have confused code and host password. Actually, I don't think I want to generate a host password randomly, I want to set it to a known password so if I don't get the code emailed, I can still login if I know the ID and the password I se t.
There are Internet-ID code and Host access password (single password authorization). You can still get the ID emailed to you even if you do not enable "Automatically generate password" box and manually set the password in Host settings in the last step. In this case the email will be sent unencrypted because it will only contain the Internet-ID.
Are there any plans to implement a service to facilitate direct connections between hosts instead of connections relaying through your servers unless manually setting up port forwarding and using direct IP's?
I am not sure what service you can possibly mean. A connection can be either direct or mediated through a server - be it our public server or a self-hosted server. If our public servers don't work for you well, feel free to use the self-hosted server, this is one of the reasons why we offer it (for free).
If you mean peer-to-peer connectivity though, I am sorry but this is not the way to go for us. It might work for free and personal tools, but since we also sell to businesses they won't be happy to use a P2P application due to security concerns that such applications can bring.
I've frequently ran into performance issues through the various relays used by Remote Utilities. Way, way, too frequently. The latency is high and there is significant ping loss. I have a PC next to me that I'm connecting to that has more than 8 seconds of latency (it's varied fr om 4-18 seconds while I've been writing this). The re's the scenic login screen and then the computer boots up with Spotify open and the large pictures seem to bring it to a crawl even with 16 bits colour. I have it on HDMI output to a monitor on my right, and then connecting using Internet ID fr om my main PC next to it. At this moment, round trip ping time to your relay server in Montreal is 163ms (from west Canada. I normally get 78ms pings to Ontario, so this Montreal hub kinda sucks as you'll see below) with approx 18% packet loss.
A ping from your location to our server doesn't say anything about the quality of the server itself. Our servers can sustain far more load than now and are located in one of the largest datacenters in Canada.
I believe you also have a relay server in California, which is closer and lower latency, approximately 50ms with no ping loss so far. So I'm not sure how hosts pick the relay servers, whether its random, first to respond, round robin, or load balanced, etc. But there is very clear and poor performance using the relay server and I don't see a way for me to bounce it to a better relay server and I don't see anything happening on the server side to migrate me to the better performing server that is 1/3 latency and without packet loss.
We recommend that you use a self-hosted server or even direct connection where possible.
Sorry, I probably should have explained that I understand how a RU Server would benefit, but I was just testing for raw performance and a direct connection through a port forward would be the same as a local RU server with Internet-ID (please correct me if I am wrong).
With direct connection performance is better by definition. However, if RU Server is located very close to either side of connection (Viewer or Host) the difference should be unnoticeable.
As for improving the sound capture performance, we'll see what we can do and we can implement any improvements in this beta.
If it's a different network (subnet) then you should whitelist the IP address of the router in between , not the Viewer's. I assume that your router forwards packets between two local subnets in this scenario.
In my 184.108.40.206 viewer, one of my computers were in the "Offline/Unknown". I upgraded my side to 220.127.116.11 and still the same.
Here, do you mean you updated the Viewer? Ok.
I RDP'd into it and ran my one-click configurator exe. I watched in Task manager that the host was already running, and I could see when the one-click installer finished. On my side, the viewer now shows the computer online (however, still reporting 18.104.22.168 instead of 22.214.171.124), with a new Internet-ID (as I checked in the one-click configurator to generate and email), but I did not receive an email with the new generated password.
- Did you enable "Send via email option" and specified a correct email address? - Did you check your spam folder in case the email ended up there?
But now when I go to connect to it, I just get "At least one authorization method must be enabled on remote Host". When I was doing the one-click authorization, I only wanted to use single password but it was greyed out and I couldn't select it.
This is because you enabled the "Automatically generate Host password" in the 3rd step. These two options are mutually exclusive. If you enable the "Automatically generate ..." box it is supposed that the program will generate a unique password for each Host. On the other hand, if you clear this check box you can manually set your password when configure settings at the last step. However, in this case the password will be identical for all your Hosts.
Still, it is strange that your settings didn't apply. Could you open the Host settings and check if the Single password check box is enabled at all (Settings for Host -> Authorization) ?