How to do file transfer
- Thread starter hhspiny
- Start date
Hi hhspiny and welcome to our forum!
There are several methods to transfer files to and from the remote machine.
1. Drag and drop - drag a file or folder on the machine where the connection is made from and drop it on the video area where you see the remote machine. Please note that drag and drop is only possible on the client machine.
2. Using context menu (both sides) - right click on a file or folder and you should see something like this:
You can also press show more options to use the old style menu:
Or you can enter the "Send to" sub menu:
3. Ctrl+C Ctrl+V. Select a file(s)/folder(s) and press Ctrl+C then make the other side active and Ctrl+V. If the file(s) are big you should see a standard "Copying files..." dialog.
All files are first packed and encrypted with a symmetric AES256 key. Next they are transferred using TLS1.3.
Please let us know if you have any problems.
There are several methods to transfer files to and from the remote machine.
1. Drag and drop - drag a file or folder on the machine where the connection is made from and drop it on the video area where you see the remote machine. Please note that drag and drop is only possible on the client machine.
2. Using context menu (both sides) - right click on a file or folder and you should see something like this:
You can also press show more options to use the old style menu:
Or you can enter the "Send to" sub menu:
3. Ctrl+C Ctrl+V. Select a file(s)/folder(s) and press Ctrl+C then make the other side active and Ctrl+V. If the file(s) are big you should see a standard "Copying files..." dialog.
All files are first packed and encrypted with a symmetric AES256 key. Next they are transferred using TLS1.3.
Please let us know if you have any problems.
Last edited:
That is strange. none of these options shows up in host sides. the host has remotly installed as admin and start with windows as service
Host -- installed as admin and start as service
client -- portable
connect via connect anywhere.
screen shot from host side. windows 11
client side, portable. windows 10. while "-> remotly" shows up in "send to" it does nothing
On the host side, remotly was installed in administrator account, starts with windows. then computer was rebooted, and the user right now is a normal user. remotly does not even shows up in this user's program menu. but client can connect to host without problem.
Host -- installed as admin and start as service
client -- portable
connect via connect anywhere.
screen shot from host side. windows 11
client side, portable. windows 10. while "-> remotly" shows up in "send to" it does nothing
On the host side, remotly was installed in administrator account, starts with windows. then computer was rebooted, and the user right now is a normal user. remotly does not even shows up in this user's program menu. but client can connect to host without problem.
Attachments
Looks like I found the reason
after computer reboot, if log into administrator account in host (remotly originally installed under), the file transfer works fine. if after reboot, log into normal user account, file transfer option does not show up.
in normal user account, remotly does not show up at all.
after computer reboot, if log into administrator account in host (remotly originally installed under), the file transfer works fine. if after reboot, log into normal user account, file transfer option does not show up.
in normal user account, remotly does not show up at all.
another problem I am having is that --
after rebooting, connect to host, log in as normal user. then, choose to "switch user", remotly would just be blank, and then show "no signal, waiting for signal" and "try again, disconnect"...
Parsec has same problem, but Parsec normally recovers after a minute or two, and allows connection to the login screen again. remotly does not seem to be able to recover
after rebooting, connect to host, log in as normal user. then, choose to "switch user", remotly would just be blank, and then show "no signal, waiting for signal" and "try again, disconnect"...
Parsec has same problem, but Parsec normally recovers after a minute or two, and allows connection to the login screen again. remotly does not seem to be able to recover
We will check this asap. We have tested switching users - it should work. I remember that on some AMD GPU there was a similar problem (stuck at a blank screen). Do you have an AMD GPU in this system?
As for the missing context menu I think it will not work for the other account where Remotly is not installed (only accessed using the multi-account service). But we will try to fix it. The account where Remotly is installed with admin rights should be able to add some entries to other accounts register. Thanks for reporting this!
As for the missing context menu I think it will not work for the other account where Remotly is not installed (only accessed using the multi-account service). But we will try to fix it. The account where Remotly is installed with admin rights should be able to add some entries to other accounts register. Thanks for reporting this!
BTW. Can you try to enable the "use compatibility mode" in Settings->General and then test account switching and let us know if it works (without the no-signal message).
Remotly has 3 different modes in which it accesess GPU video memory:
1. Advanced low level access to GPU (only works with admin rights). Best performance and synchronized with each vsync of the display.
2. Output duplication (parsec like mode)
3. Compatibility mode - slow/software mode but should always work (used for virtual machines etc.)
Remotly has 3 different modes in which it accesess GPU video memory:
1. Advanced low level access to GPU (only works with admin rights). Best performance and synchronized with each vsync of the display.
2. Output duplication (parsec like mode)
3. Compatibility mode - slow/software mode but should always work (used for virtual machines etc.)
AMD 5950x (no iGPU), Nvidia 4060 GPU.
turned on compatibility mode both on host and client.
reboot -> remote connect to log in screen -> login with normal user -> switch user -> blank screen. repeated multiple times
I was able to get it to work by not switching user, but instead, sign out. this would make the connection drop for a moment, but get back to login screen quickly.
I think I have had similar behavior in Parsec.
turned on compatibility mode both on host and client.
reboot -> remote connect to log in screen -> login with normal user -> switch user -> blank screen. repeated multiple times
I was able to get it to work by not switching user, but instead, sign out. this would make the connection drop for a moment, but get back to login screen quickly.
I think I have had similar behavior in Parsec.
Last edited:
We must fix it. I cannot reproduce this problem on my side. Works in all cases switch/sign out etc. Do you have more than one normal/guest account (admin + more than one other account). Do these accounts work in same display resolution?
Trying to figure out why it works for us...
Please make sure to disable compatibility mode if it is not needed (doesn't help) since it uses SW encoding that hogs CPU. For virtual machines they are detected and compatibility mode is used when needed.
OK. It's a bug. The black screen/freeze happens when the the account where Remotly is installed is not signed in and we try to switch to this account from another normal/guest user account. If you first login to the main/admin account the switch should always work.
We will fix it today and it will be available in 1.14.1 tomorrow (it was scheduled for today but we will fix this first).
We will fix it today and it will be available in 1.14.1 tomorrow (it was scheduled for today but we will fix this first).
thanks for the tremendously fast response. appreciate that. will test out on weekend.
on separate question, not sure remotly is using GPU. GPU video encode utilization is always zero, but 3D utilization is not.
Turned compatibility mode off in both host and client. in host, turned on hardware acceleration (encoding) to NVIDIA NVENC HEVC (RTX 4060 Ti) and max bitrate 45 Mbps
Tried to run Furmark, which runs very well over home network with Parsec...
Full screen benchmark did not run, showing a static image
Windowed benchmark ran, but slower, jittering, and more blurry than Parsec.
Is there any way to check the utilization of GPU encoding, codec, and bandwidth utilization etc like in Parsec?
quite excited finding this product, Parsec + Teamviewer, can't wait for ironing out all the bugs and get into commercial phase (and hope priced right).
on separate question, not sure remotly is using GPU. GPU video encode utilization is always zero, but 3D utilization is not.
Turned compatibility mode off in both host and client. in host, turned on hardware acceleration (encoding) to NVIDIA NVENC HEVC (RTX 4060 Ti) and max bitrate 45 Mbps
Tried to run Furmark, which runs very well over home network with Parsec...
Full screen benchmark did not run, showing a static image
Windowed benchmark ran, but slower, jittering, and more blurry than Parsec.
Is there any way to check the utilization of GPU encoding, codec, and bandwidth utilization etc like in Parsec?
quite excited finding this product, Parsec + Teamviewer, can't wait for ironing out all the bugs and get into commercial phase (and hope priced right).
Last edited:
Hi hhspiny,
Thank you so much for your feedback.
"on separate question, not sure remotly is using GPU. GPU video encode utilization is always zero, but 3D utilization is not.
Turned compatibility mode off in both host and client. in host, turned on hardware acceleration (encoding) to NVIDIA NVENC HEVC (RTX 4060 Ti) and max bitrate 45 Mbps"
Please let me know what is the CPU load during connection. It should stay around 0-2% in Task Manager->Details for Remotly on recent machines. Are you checking GPU utilization in Task Manager? If yes, then sometimes you need to select Video Decode instead of Video Encode to see the GPU encoder load (windows bug).
I hope that compatibility mode is disabled since it will not work well.
"Tried to run Furmark, which runs very well over home network with Parsec...
Full screen benchmark did not run, showing a static image
Windowed benchmark ran, but slower, jittering, and more blurry than Parsec."
It this a full screen exclusive mode or just borderless full screen windowed mode (will make the same test before 1.14.1 release)?
Please make sure to use Direct Connection for home network to remove any bandwidth limits and set the bitrate at some high level (depending if it's HD or 4K).
Make sure that the host has a big bandwidth cap (this is used to override client's requested bitrate to not allow connections with too high bitrate):
On the client side for the connection to a specific host please make sure Connect Anywhere is not used for home/local network.
You can have different settings for different machines/hosts depending on their network etc.
If you are connecting from a device that has 1080p to a 4K device we recommend to also set Video Size to the display of the client.
We will try to make this automatic soon (no need to stream 4K to a 1080p display).
I'm sure the video is blurry or jittery because of too low bitrate/bandwidth (or Connect Anywhere is used :/).
"Is there any way to check the utilization of GPU encoding, codec, and bandwidth utilization etc. like in Parsec?"
A "Netflix" style CTRL + ALT + SHIFT + D overlay will be available soon with all the interesting stuff.
BTW. The server icon with GREEN tick mark is not visible during P2P/Direct connections. This is the easiest way
to check what is the current connection mode. When it is visible you can click it to check the location of automatically
selected (or by hand from a list of 30 locations in General Settings) relay server.
"quite excited finding this product, Parsec + Teamviewer, can't wait for ironing out all the bugs and get into commercial phase (and hope priced right)."
The most difficult task is to make Remotly work as good as possible both with very low quality networks (requirement from commercial users) and for gaming...
Thank you so much for your feedback.
"on separate question, not sure remotly is using GPU. GPU video encode utilization is always zero, but 3D utilization is not.
Turned compatibility mode off in both host and client. in host, turned on hardware acceleration (encoding) to NVIDIA NVENC HEVC (RTX 4060 Ti) and max bitrate 45 Mbps"
Please let me know what is the CPU load during connection. It should stay around 0-2% in Task Manager->Details for Remotly on recent machines. Are you checking GPU utilization in Task Manager? If yes, then sometimes you need to select Video Decode instead of Video Encode to see the GPU encoder load (windows bug).
I hope that compatibility mode is disabled since it will not work well.
"Tried to run Furmark, which runs very well over home network with Parsec...
Full screen benchmark did not run, showing a static image
Windowed benchmark ran, but slower, jittering, and more blurry than Parsec."
It this a full screen exclusive mode or just borderless full screen windowed mode (will make the same test before 1.14.1 release)?
Please make sure to use Direct Connection for home network to remove any bandwidth limits and set the bitrate at some high level (depending if it's HD or 4K).
Make sure that the host has a big bandwidth cap (this is used to override client's requested bitrate to not allow connections with too high bitrate):
On the client side for the connection to a specific host please make sure Connect Anywhere is not used for home/local network.
You can have different settings for different machines/hosts depending on their network etc.
If you are connecting from a device that has 1080p to a 4K device we recommend to also set Video Size to the display of the client.
We will try to make this automatic soon (no need to stream 4K to a 1080p display).
I'm sure the video is blurry or jittery because of too low bitrate/bandwidth (or Connect Anywhere is used :/).
"Is there any way to check the utilization of GPU encoding, codec, and bandwidth utilization etc. like in Parsec?"
A "Netflix" style CTRL + ALT + SHIFT + D overlay will be available soon with all the interesting stuff.
BTW. The server icon with GREEN tick mark is not visible during P2P/Direct connections. This is the easiest way
to check what is the current connection mode. When it is visible you can click it to check the location of automatically
selected (or by hand from a list of 30 locations in General Settings) relay server.
"quite excited finding this product, Parsec + Teamviewer, can't wait for ironing out all the bugs and get into commercial phase (and hope priced right)."
The most difficult task is to make Remotly work as good as possible both with very low quality networks (requirement from commercial users) and for gaming...
1. Both video encode and video decode stay at 0% all the time. remotly_boot.exe is the only process that consumes CPU and stays around 1-3%. Compatibility mode was turned off.
2. Furmark's full screen benchmark should be exclusive mode I would think. Runs in Parsec
3. In home network, bandwidth limit on both client and host 45 mbps. No green button on top. will do more testing during the weekend and report back.
potential bug/inconvenience - 1
Reboot-> connect -> log in to admin account (remotly was installed under) -> remotly does not show in sys-tray, not able to change setting in host. in order to launch remotly interface, open remotly app at this point, the connection would drop. but can reconnect. just a minor inconvenience.
Another topic -- a potential safety bug
Really like the "require device authorization" function. all remote access software that stores credential on server to allows one-click access should have implemented this function. but there seems to be a serious safety bug:
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"
2. Furmark's full screen benchmark should be exclusive mode I would think. Runs in Parsec
3. In home network, bandwidth limit on both client and host 45 mbps. No green button on top. will do more testing during the weekend and report back.
potential bug/inconvenience - 1
Reboot-> connect -> log in to admin account (remotly was installed under) -> remotly does not show in sys-tray, not able to change setting in host. in order to launch remotly interface, open remotly app at this point, the connection would drop. but can reconnect. just a minor inconvenience.
Another topic -- a potential safety bug
Really like the "require device authorization" function. all remote access software that stores credential on server to allows one-click access should have implemented this function. but there seems to be a serious safety bug:
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"
Last edited:
OMG! Why are you seeing the remotly_boot.exe? This process should disappear after signing in to your admin account and Remotly.exe should be used from this time on. Something is not right here (this is why is works so bad and does not use HW acceleration).
Can you please make the test in a simple environment:
- Sign in to the admin account where you see the Remotly app user interface (account where it is installed)
- Make sure that in Settings->Video hardware acceleration is not disabled (the acceleration without HEVC in its name is AVC, we will add AV1 soon and it will also appear on this list when both sides support AV1).
"Another potential bug/inconvenience
Reboot-> connect -> log in to admin account (remotly was installed under) -> remotly does not show in sys-tray, not able to change setting in host. in order to launch remotly interface, open remotly app at this point, the connection would drop. but can reconnect. just a minor inconvenience."
I will briefly describe how the whole remote reboot works:
MODE 1 (reboot and login to the admin account where Remotly is installed):
1. The remotly_boot_svc.exe service starts after reboot and launches remotly_boot.exe.
2. remotly_boot.exe logs with the encrypted credentials of the last user that was logged in Remotly on the account that it is installed
3. Enter password to login to the account where Remotly is installed
4. After a short time a low signal icon will appear and the machine will have a status of "booting system" and an orange dot
CAUTION: in current 1.14.0 version there is a bug and you will get disconnected during switch from remotly_boot.exe to full software. This has been fixed in 1.14.1 (this is exactly the inconvenience you have reported - connection drop).
5. Full Remotly software starts on this account and UI is visible (remotly_boot.exe is gone)
6. Connection is again possible (in 1.14.1 low signal warning disappears and signal is recovered with full HW acceleration
MODE 2 (reboot and login to other users account):
1. The remotly_boot_svc.exe service starts after reboot and launches remotly_boot.exe.
2. remotly_boot.exe logs in to Remotly account with the encrypted credentials of the last user that was logged in Remotly on the account that it is installed (admin account).
3. Enter password/login of the other normal/guest account where Remotly is not installed
4. remotly_boot.exe stays working and streams video in compatibility mode (no audio etc.)
Please let me know if you have any questions regarding this. By design we have never thought about running with full optimizations on accounts where Remotly is not installed.
"btw, really like the "require device authorization" function. all remote access software that stores credential on server to allows one-click access should have implemented this function."
And it will get even better and more secure with a biometric access using second device (phone etc.).
Can you please make the test in a simple environment:
- Sign in to the admin account where you see the Remotly app user interface (account where it is installed)
- Make sure that in Settings->Video hardware acceleration is not disabled (the acceleration without HEVC in its name is AVC, we will add AV1 soon and it will also appear on this list when both sides support AV1).
"Another potential bug/inconvenience
Reboot-> connect -> log in to admin account (remotly was installed under) -> remotly does not show in sys-tray, not able to change setting in host. in order to launch remotly interface, open remotly app at this point, the connection would drop. but can reconnect. just a minor inconvenience."
I will briefly describe how the whole remote reboot works:
MODE 1 (reboot and login to the admin account where Remotly is installed):
1. The remotly_boot_svc.exe service starts after reboot and launches remotly_boot.exe.
2. remotly_boot.exe logs with the encrypted credentials of the last user that was logged in Remotly on the account that it is installed
3. Enter password to login to the account where Remotly is installed
4. After a short time a low signal icon will appear and the machine will have a status of "booting system" and an orange dot
CAUTION: in current 1.14.0 version there is a bug and you will get disconnected during switch from remotly_boot.exe to full software. This has been fixed in 1.14.1 (this is exactly the inconvenience you have reported - connection drop).
5. Full Remotly software starts on this account and UI is visible (remotly_boot.exe is gone)
6. Connection is again possible (in 1.14.1 low signal warning disappears and signal is recovered with full HW acceleration
MODE 2 (reboot and login to other users account):
1. The remotly_boot_svc.exe service starts after reboot and launches remotly_boot.exe.
2. remotly_boot.exe logs in to Remotly account with the encrypted credentials of the last user that was logged in Remotly on the account that it is installed (admin account).
3. Enter password/login of the other normal/guest account where Remotly is not installed
4. remotly_boot.exe stays working and streams video in compatibility mode (no audio etc.)
Please let me know if you have any questions regarding this. By design we have never thought about running with full optimizations on accounts where Remotly is not installed.
"btw, really like the "require device authorization" function. all remote access software that stores credential on server to allows one-click access should have implemented this function."
And it will get even better and more secure with a biometric access using second device (phone etc.).
will then wait for the new version to test out. right now, even if login to admin account (installed remotly) the icon does not show up in sys-tray. maybe I did something wrong, but it was rather simply procedure to install. this is also a NAS, hence not running admin right. this computer is part of a domain network. don't know if it makes difference.
if you were to develop for commercial/enterprise where the real money is, would not it pretty much guaranteed that it would be installed in admin account but used with normal account in a domain environment?
if you were to develop for commercial/enterprise where the real money is, would not it pretty much guaranteed that it would be installed in admin account but used with normal account in a domain environment?
It's not that bad...
My test:
1. Reboot system with booter service running
2. No user is signed in
3. Sign in to normal user
4. Run the Remotly.exe from the admin installation folder (you can create shortcut on desktop of this user to Remotly.exe that is installed in Program Files by the admin).
5. After the full version with UI starts you need to login to some Remotly account and select "remember me" (this needs to be done by hand and not remotely)
6. remotly_boot.exe will be closed as soon as the full version starts (after closing Remotly.exe the booter should start again and remote access is still possible).
This way you can access the full version with HW encoding etc. from the normal user. I'm sure some improvements will need to be done to make it as friendly for the user as possible but at least HW acceleration is accessible on account where Remotly is not installed.
My test:
1. Reboot system with booter service running
2. No user is signed in
3. Sign in to normal user
4. Run the Remotly.exe from the admin installation folder (you can create shortcut on desktop of this user to Remotly.exe that is installed in Program Files by the admin).
5. After the full version with UI starts you need to login to some Remotly account and select "remember me" (this needs to be done by hand and not remotely)
6. remotly_boot.exe will be closed as soon as the full version starts (after closing Remotly.exe the booter should start again and remote access is still possible).
This way you can access the full version with HW encoding etc. from the normal user. I'm sure some improvements will need to be done to make it as friendly for the user as possible but at least HW acceleration is accessible on account where Remotly is not installed.