How to do file transfer

[hhspiny]

I think I understand how it works. remotly_boot.exe runs in background at boot, but gets replaced once remotly.exe actual runs. but many features are implemented only in remotly.exe only, hence the problems I have faced.

did you by any chance test out this following? which might also result from the remotly_boot.exe vs. remotly.exe difference.

delete all devices from "authorized devices" list, but keep the "require device authorization" on. reboot. still can connect to the login screen and login. open remotly app, get disconnected, reconnect, now, it asks for "waiting for device authorization".
remotly_boot.exe does not enforce device authorization?

 

[hhspiny]

I can confirm that the method you listed above for use under normal user account works well. HW encoding is enabled now.

also did a comparison to Parsec, and performance is similar for 3D benchmark. the only difference been that Parsec seems to handle network jittering somewhat differently. Parsec seems to reduce framerates but keeps picture smooth. Remotly seems to maintain framerate but pixelate the picture/drop frame.

 

[mirillis]

I can confirm that the method you listed above for use under normal user account works well. HW encoding is enabled now.

also did a comparison to Parsec, and performance is similar for 3D benchmark. the only difference been that Parsec seems to handle network jittering somewhat differently. Parsec seems to reduce framerates but keeps picture smooth. Remotly seems to maintain framerate but pixelate the picture/drop frame.

Pleae check the "P2P with error correction" option. It's the last position on Settings-General list (you might need to scroll this list down to find it).

With this option you can control if you prefer video glitching/pixelating (useful for gaming) or frame dropping (useful for work).

Please play with it and let me know if this works for you as it should.

 

[hhspiny]

the P2P with error correction indeed prevented pixelation. but the picture would completely freeze for 1-3 seconds. while Parsec only slows the framerate down. tested on the same host/client/network/app between remotely vs. Parsec.

 

[hhspiny]

well, running remotly.exe in normal user account has a problem -- UAC dialog box is not accessible (the one asks for admin credentials for app install etc). I figure remotly.exe runs in user's context, hence can't access UAC dialog box.

The solution right now is to a), in normal user account's remotly GUI, turn off "start with windows" b). reboot, login with normal user, then run remotly.exe as administrator. this way, hardware acceleration is still active, and UAC dialog box can be accessed.

Parsec does not have such problem.

maybe it is a good idea to implement a full functional remotly_boot.exe. It might not be a viable assumption (at least for a product) to assume always admin account.

 

[mirillis]

Hi hhspiny,

We have finally prepared a pre-release 1.15.0 version for PC: https://downloads.mirillis.com/files/beta/remotly_pc_1_15_0_setup.exe

There are a lot of changes (most of them address issues and problems reported by you last week):

1. Fixes for booter (session switching etc.)
2. After installing Remotly on the admin account and enabling "start with pc/system" you can now enter a normal user account and after starting Remotly.exe from the admin installation folder you will be able to access UAC popups and logon/lock screen remotely. CTRL + ALT + DEL also works but it is blocked in the client window menu so it is impossible to call CTRL + ALT+ DEL from PC client (works from mobile/Android client). This will be fixed in the final v1.15.0 installer.
3. Sending files works in normal account but only using the context "Send to" sub menu. Drag and drop does not work and after trying to drag and drop a file on a normal account/non-admin remote machine it will block sending files even using "Send to" context menu (bug that needs fixing).
4. Ultra fast network jitter recovery for P2P (for all GPU vendors Intel/AMD/Nvidia). The "P2P with error resilience" option has no effect as of this version and is always ON.
5. Device authorization possible in logon screens even if there is no user signed in. When booter is running and the authorization popup shows you will have 30 seconds to allow connection (and additionally add the device to trusted list). After 30 seconds another popup is shown, the machine is again ready for connection and you can connect with another device that is already trusted to add the previous unauthorized device to the authorized list.

We recommend to install the mobile Android app on your phone and make sure this device is added to the trusted list on all your remote machines. This way you can use this mobile device to grant other devices remote access (either once or add to trusted list).

In version 1.16.0 we will add hardware TPM 2.0 support for RSA4096. Since the private RSA key in TPM 2.0 is not readable it will make the asymmetric encryption part unbreakable.

A lot has changed. We hope only for the better.

Looking forward to hearing from you in case of any problems or suggestions.

 

[mirillis]

The uploaded version contained the old remotly_boot.exe :/ I have replaced it with the new one so please download the installer once again (from the same location as above).

 

[hhspiny]

thanks for the quick fixes.
did a clean install to test the new version:
install in admin account, run, login to remotely account, add authorization, set start with windows. reboot.
login to normal user account, run remotly.exe, need to login to remotely again, add authorization, set start with windows. reboot

first to report a likely bug
-- after reboot before login, can't connect at all. need to login, either admin or normal user account to connect. (1.14 allows connect without login)

after reboot, login to normal user account at host, remotly automatically runs and all seem to work well
1. file transfer, UAC, and GPU acceleration.
2. logout and login to other account; switch between accounts.
3. add authorization using an already trusted client
4. network jittering seems to be better, but with a new router, the old version was good already.

a couple of suggestions
1. switching account entails disconnect -- maybe give a warning, or just keep the window open and wait for reconnect?
2. settings. esp. device authorization are defined per user (remotly_boot uses the same as admin?). this might or might not be ideal. For example, admin might want to set authorization (or even maybe remotely account) for the computer, instead of each user uses separate account and authorization list.
3. allows pre-authorization of clients (or some of them) that are already added to the remotly account?
4. create remotly.exe shortcut in start menu for all users, no need to hunt down remotly.exe

 

[mirillis]

A new pre-release installer will be ready soon. There were still some problems with remote access after reboot in some cases.

 

[mirillis]

Hi hhspiny,

It took some time since we had to make bigger changes in Remotly's core architecture for multi-account scenarios.
Under the same link as before:
https://downloads.mirillis.com/files/beta/remotly_pc_1_15_0_setup.exe

I have uploaded another pre-release update.

From this version if you install with admin rights on the admin account the Remotly desktop shortcut will also be visible on other accounts (uses Users\Public folder for desktop shortcut and start menu).

After enabling "Start with windows" you should be able to switch between accounts during connection and reboot to admin and normal accounts.
There is a ton of test cases and we hope most of them will work in this update.

Please let us know if you find anything problematic.

 

[hhspiny]

some observation, not sure what is supposed to work like this, what is not.

1. can connect now after reboot without login
2. connect to login screen, login to regular or admin, remotly auto-starts. this disconnect though.
3. when sign-out from account, or switch user back to sign-in screen, it does not disconnect anymore, just freezes for a bit, then screen comes back -- which I remember is an improvement from previous version which disconnects
4. switching account works fine if each time an account was logged out (not just switch user).
5. switching account without logging out is still problematic -- login to normal user account, then switching (w/o logout) to admin account works fine (but each time remotly auto-start within the account means disconnect). however, after switch back to normal user, remotly is gone, and runs on remotly_boot (as GPU not used anymore). this also happens if logout admin before switching back to normal user.
Now, in normal user account, run remotly manually to get it back.
a). if admin account was logged out before switching back to normal user account, remotly would then come back and runs normally
b). if admin account was NOT logout out before switching back to normal user account, remotly won't be able to login to remotly account anymore (login fails) -- likely in conflict with the instance of remotly still running in admin account.

not sure if 5). above is what you even consider as a use case at this stage.

 

[mirillis]

I'm back. We have officially uploaded the new update.

Remotly PC 1.15.0 is now available!

We have just uploaded a new update that includes many changes and improvements. Please note that from this versions all default device names are in a new notation: COMPUTERNAME/USERNAME. You can of course create aliases for this names in your admin panel. Moreover all devices have new...

community.remotly.com

 

[hhspiny]

seems like a good approach of creating computer/user instances

observations/potential problems
1. only computer/administrator shows up in "connect to a remote computer" drop down list. need to find computer/user in "Devices" tab
2. remotly.exe does not auto-run in admin account, only in normal user account

it works fine for me, but I suspect it might not be easy for average user to follow
.
it might be easier to switch the instance available for connection in background, and expose a single name to client. if the computer is currently in login/lock screen, the "computer/administrator" (or better a dedicated instance) is used; if the computer has user logged in (either administrator or user), computer/user instance is used. all happens automatically. I believe at any given time, only one computer/user (besides admin) instance is active anyway -- even with remote desktop session. if the client/server can work together to make the transition without user noticing, it would be even better.

 

[mirillis]

Hi hhspiny!

"1. only computer/administrator shows up in "connect to a remote computer" drop down list. need to find computer/user in "Devices" tab"

We don't see this problem on our side. Both normal user accounts and admin accounts are visible from the drop down as soon as they sign in for the first time to the Remotly account.

"2. remotly.exe does not auto-run in admin account, only in normal user account"

This is more of a "security" nuance. We are still not sure if it is ok to run the booter every time the full version is closed. If someone forgets about this (has the start with system option on) then this machine stays "online" via the booter all the time. Since the booter is not accessible using the Connection ID code it is not much of a problem (having the require authorization always on for all connections).
But still we cannot decide weather this should be done this way or not.

I will reply to the rest of your message soon as we need to release an urgent hotfix for Win7/Win8 systems.