However, this specific "bug" was just something we overlooked on the building stage rather than a bug in the program itself (related to its functionality, that is). So we decided to keep it the same number.
Yeah, that is very bad practice. The build output from one version of the compiler and build system can vary with the same source code. The building stage is essentially part of the "application" along with the source code. It should be tracked just as the same the code. Some companies have policies that even prevent the release system from ever generating different builds using the same release number to prevent this scenario. Not only do you have your own code issues handling this issue internally, now you have two different "viewer6.12.b2.exe" files that you had posted for almost two weeks on the Internet.
No updated release date, no reference in the release notes about the correction. So the release notes loses credibility as being inaccurate when bugs were fixed and when new updates appear. Some people may not be willing to try a beta build to fix various bugs that was JUST released but think, "hey, it's been out two weeks, it's worth a try" but it's now actually only got ~1 day of public testing. Beta release notes should be verbose, more so than stable release notes, IMO.
On top of that, it received zero QA before it was posted for open beta testing. Now, it is expected to have MAJOR bugs in beta builds and the user accepts that. Happens to Microsoft ALL.THE.TIME. But they also have automated checks in place that (should) prevent showstopper bugs before they get into a public beta and quickly pull facepalm builds that fail even the most basic mandatory function.
Right now, my PC has two files names "viewer6.12.b2.exe" with different file sizes. One has a digital signature signing date of May 13, and another one says May 18. The release date is May 6. The server's beta 2 has a signing time of May 5, which is what I'd expect with a May 6 release. But May 13 and May 18th? This implies that you didn't just have TWO different "viewer6.12.b2.exe" with different hashes, but (AT LEAST) THREE. Can you comment on that?
Can you see how confusing this is by reusing release numbers and release dates? How do we know if the beta2 from May 6 was busted or if the May 13 stealth update introduced the epic fail? Like I mentioned before, this version reusing and non-release note update practice has lost so much credibility in beta testing for me. I've always had my issues with your development style, but this one will be the one that takes the cake.
tl;dr I scream internally reading your response. I need to go take a chill pill now.
May 6 signed build: SHA-1: ??? May ??? signed build: SHA-1: ??? May 13 signed build: SHA-1: 384B5BF7DB12D10EE637F0F317CDC8737F6F12DA May 18 signed build: SHA-1: 5EB2C20CBB11C68EBBB40E0EDB5508D7D0CD8CCB
We've managed to reproduce the issue and implemented a quick fix for it. We apologize for the caused inconvenience.
An updated build of version 6.12 Beta 2 is available on this page . Please try updating your Viewer and see if the issue persists.
Please let us know if you have more questions.
The newest version updated and address books and registration worked.
But I would strongly suggest letting your developer know that they should increment the version string instead of re-releasing under same version. That is just a no-no. We always had a saying, "numbers are free".
Over the past couple of days I have tried using using version 6.12 Beta 2 Viewer. It has not been a happy process! Having installed the viewer on an XP pro machine which had version 6.1010.0 working fine, I found that my address book and so forth had not been carried over to the new version (and nor had my licence). I turns out that 6.12 stores these settings in the user's application data in a folder Remote Manipulator Files whereas 6.10 uses Remote Utilities Files. After copying the data across, I had the address book back, but a side effect was that the free trial period had expired. On trying to install my licence code, I got a message "Attention Invalid registration key" The key worked fine on a different machine which still had version 126.96.36.199. So I uninstalled 6.12. The uninstall progress window showed gibberish symbols instead of text! I Reinstalled 188.8.131.52, and fortunately all was back to how it had been previously. I then tried installing the beta on a Windows 7 machine which had not halready had the viewer installed. This too would not accept the licence key. So for me, version 6.12 beta 2 is completely unusable as it stands.
Went to upgrade from 6.12b1 to 6.12b2 and lost registration and address books as well. Went to put in registration and also got invalid registration key error. Uninstalled (I didn't have any gibberish) and reinstalled previous 6.12b1 to get registration and address books (address book sync still broken on this machine so I'm giving up on RUT now).
I thought that after nearly two weeks after the b2 was posted, this SHOWSTOPPER bug would have been found and the b2 pulled by now, so pretty annoyed to have run into it myself today.
What are your issues with their current instructions that a video would help? It's quicker to just say, "when I get to step X, I don't know what to click" or whatever.
But I'm not sure if you understand the feature, since self-hosted server is just your own RELAY instead of RUT's public ones, and still doesn't "connect directly". For that, it's actually outside of RUT's scope so that will depend on your router and network connection, and that's WAY too broad to have a useful video. That needs some basic technical experience to configure direct connect (unless you have IPv6).
The infrastructure was expanded just recently. It may take some time for the load to spread evenly across the servers. I recommend that you try in a few hours to see if there are still any issues and let us know.
Will do. Thanks again.
Next time you experience lag, use a program like mtr (winMtr, https://sourceforge.net/projects/winmtr/) to check the loss between you and the RUT relay server. After connecting to the host, grab the IP fr om the "IP address/DNS" column in the viewer and enter that into winmtr and click start. That will tell you wh ere the bottleneck is actually happening.
A couple of years ago, I was really frustrated by the lag and RU said their servers were barely being utilized. This made sense because the problem wasn't their server itself, the problem was the connection to the datacenter their server was hosted in was bottle necked and dropping 80% packets. There are several connections into major data centers, so not everyone would experience this issue. So when RU checks the stats of their server, they'll see it running perfectly fine with lots of capacity available, but the issue is that they have zero insight into network issues outside of the server. The client doesn't do any failover or checking to see which RU server is closer or anything complex like that. RU setting up multiple remote ping monitors will help catch when this happens, but even when it does happen, that would just confirm outages and wouldn't do anything smart to route around the problem.
tl;dr If most of your clients are local, setting up a local relay server would make a huge difference. Also, if you have access to clients router and can configure port forwards, direct access is 10X better than using relay whether its yours or RU's server.
Could you please let us know if you have tried adjusting the touchpad settings or updating the mouse software on the Viewer's side? Unfortunately, we cannot reproduce the issue which means that it only manifests itself in certain circumstances.
This is on a desktop PC to other Desktop PC's, no touchpad controls. Mouse is a Logitech M705. I'll let you know if I can reproduce on other PC's.
So then this pop up happens some time later
Could you please clarify if you mean the First connection warning window? If this is the case, then we are considering the revamp of the First connection warning window along with some other features. However, unfortunately, we cannot provide any specific ETA on this yet.
Yes, that one. I will stop using this feature.
I'm checking the host version (because its not shown in the Viewer, for example)
Actually, it's also possible to check the Host version in the Viewer if you switch to the Details view style:
Yes, that is my preferred view I use all the time but a lot of the hosts have blank boxes or out of date. I'm in the process of migrating to a new computer and have my new and old PC side by side. They are using same synchronized address books. Some don't show the same versions for the same hosts. Some don't show any version for some hosts in one viewer and not the other. It's not a reliable place to confirm actual versions. Right now, my new PC has yellow exclamation marks next to 5/7 cloud address books and the old PC, also running viewer 6.12.1, has no yellow exclamation marks on any of the address books.
Install RUT using a silent installer made against 6.10.3. When I went to add the code in 6.12.1, it said I needed to use the same Viewer version as what was used to generate it! Jeepers, that is another strike against the silent installer feature. If I had installed the silent installer, got home and then got this message without an opportunity to manually se t a new password so I could manually add to the Viewer, I probably would just give up on RUT right then and there and move to another solution. Try and only break backwards compatibility on major versions, not on minor versions, I beg you!
I apologize for the inconvenience. We try to maintain as much backward compatibility as possible with each update because we understand that our customers might not be able to update remote Hosts all at once. Besides, we even advise updating remote Hosts in small increments and first test the update procedure on a small sample. There is backward compatibility, however, it's always better to upgrade both Viewer and Host and avoid relying on it.
As for the issue itself - could you please clarify if the issue occurred on another Viewer machine instead of the one where the installation package was configured? If this is the case, you simply need to copy the keys.dat file which is an encryption key to the Viewer machine where you want to use the Add using code feature. This file is located in the C:\Users\user_name\AppData\Roaming\Remote Utilities Files\ folder on the computer where you originally configured the installation package. Please try copying this file and pasting it to the same C:\Users\user_name\AppData\Roaming\Remote Utilities Files\ folder on the Viewer PC where you want to use the Add using code feature. Here's a related KB article .
Looking forward to your reply.
Now that you mention this, I somewhat recall this limitation when making the silent installer - it's just been so long ago that I last generated it that I forgot. I knew to migrate relay server settings, but on the Viewer side I was only thinking of synchronized address books and that didn't need to be backed up/restored when migrating Viewer PC's. And now that I know that was the issue, the message pretty much says that, and I just didn't clue in. doh. Only thing to add to that help page, was that after I pasted over the keys.dat file, I had to close and reopen the Viewer to get the Add Code box to appear again. It was appearing before I pasted the keys.dat file but wouldn't appear again until I restarted the Viewer. Then I could add the code.
1. Unfortunately, we could not reproduce the mouse pointer issue. Could you please confirm that you have both - Viewer and remote Host upd ated to the latest 6.12 beta version and the issue still persists in this case? In addition, please try disabling the touchpad or altering its sensitivity in the Windows settings. Also please double-check if the mouse software is upd ated to the latest version which might be downloaded fr om the manufacturer's website.
2. As for the time it takes to establish a connection to remote Host - the Authorization method se t to Auto does not affect it. Could you please check if it takes the same amount of time to establish a connection to a remote Host in case if our public Internet-ID server is used as an intermediary instead of the self-hosted RU Server?
Looking forward to your reply.
1. Can confirm this happens with Viewer 6.12.1 with hosts 6.10.10 and 6.12.1. Ran into this again today. I installed the 6.10.3 using the silent installer made last year. It failed to upgrade to 6.12.1 through advanced install. I upgraded it to 6.10.10 through simple install and then 6.12.1 through advanced install. A reboot might have been necessary for it to successfully upgrade to 6.12.1. Then I was trying to copy/paste username/password from my PC to the viewer session, getting the offset mouse problem EVERY TIME. It was really frustrating.
Generally, I'll install the silent installer on site when a new PC or new employee starts. The code gets emailed to me, but because there is no usable Android viewer that can take that code, I can't do a remote access and click on the pop up while I'm there in person. So then this pop up happens some time later, after an upgrade, or when I'm checking the host version (because its not shown in the Viewer, for example). And then the pop up stays on the persons screen until they come in the next morning and freak the F out.
The silent installer is useful for ensuring the proper settings are consistently set and no typo's due to Internet ID's, passwords, IP's, etc. But the hard pop up that can't be moved and has a scary worded message makes that feature completely useless unless I'm setting up the computer at my home.
2. I would only have 1-2 hosts still left on public servers, but I won't login to them for fear of the stupid pop up message that blocks the right side taskbar until the user at the host clicks OK to warn the user someone is remote accessing their machine. I don't have a record of every time I've installed a host and took care of that. I can tell you at least 4 times wh ere this pop up has caused panic and alarm or just outright prevented me from doing maintenance due to blocking the taskbar. I thought from previous feedback on how poorly users think of this feature that something was going to change in future versions... I think you guys are more working on linux and mac support than fixing the issues that have bugging me for a long time. *sigh*
One of these times I'll record the process of what it goes through compared to other services in terms of initial connection time.
New issue. Install RUT using a silent installer made against 6.10.3. When I went to add the code in 6.12.1, it said I needed to use the same Viewer version as what was used to generate it! Jeepers, that is another strike against the silent installer feature. If I had installed the silent installer, got home and then got this message without an opportunity to manually se t a new password so I could manually add to the Viewer, I probably would just give up on RUT right then and there and move to another solution. Try and only break backwards compatibility on major versions, not on minor versions, I beg you!
I figured out why I thought I upgraded a bunch of hosts but wasn't reporting 6.12.1. It actually failed and I just didn't realize. I'd suggest making the failure more noticeable, like red text instead of the same blue.
***** Start of log ***** Date: 3/5/2020 12:48:35 AM Action: install/upgrade. Checking files of the Host. ---------- Action for: User () Auth try to the host... Authorization completed. Installation process has already begun. Wait for completion. Unable to complete action. ***** End of log *****