App hangs on Connected, waiting for image....

[eqpaisley]

Describe the bug you encountered:

When connecting to a new setup, the connection is made but the Connected, waiting for image... screen never goes away.

What did you expect to happen instead?

Log in should complete and the remote desktop should appear.

How did you install RustDesk?

Windows portable

RustDesk version and environment

Running rustdesk (downloaded today 3/9/22 from the website) on Windows 10. Connecting via Windows 10 on a different PC.

I use rust desk to connect to a different computer with no issues.

[fufesou]

Do you have a monitor on the remote side? #59

[rustdesk]

Please try out https://github.com/rustdesk/rustdesk/releases/download/tmp/rustdesk-1.1.9-putes.exe (on both side) if you have the monitor?

[eqpaisley]

I do not have a monitor on the remote side.

[rustdesk]

do not have a monitor

@fufesou but it does not report "No display" error, you may need to consider this scenario.

[rustdesk]

@eqpaisley try out https://github.com/rustdesk/rustdesk/releases/download/tmp/rustdesk-1.1.9-putes.exe please

[xvolks]

I have the same behaviour between my macbooks and macOS VM both running Monterey 12.4 and Rustdesk 1.1.9.
Tested with public server and private server.
Between 2 macbooks it works fine, but it behaves the same if no session is open on the remote computer.

[gioman]

Can someone help clarify here? what is the issue, the monitor being unplugged/sleeping and/or the session being locked?

[xvolks]

@gioman I've tested multiple scenarii:

• Macbook Pro 2012 (12.4, open legacy patcher, no session opened) --> no image,
• Virtual Mac (12.4, Opencore, Proxmox, both session opened or not) --> no image,
• Macbook Pro 16" core-I9 (12.5, both session opened or not) --> image OK.

Maybe the problem is on Opencore side...

[gioman]

@xvolks thanks for the reply.

This is my observation so far.

Local machine Win 10, remote machine Linux Mint 20:

I can connect and control the remote machine (even if the screen is physically turned off) as long in Linux Mint the option "turn off screen when inactive for..." is not enabled. The moment that the screen power saving kicks in, then the remote machine is not controllable anymore (rustdesk shows the hanging "waiting for image" message).

Local machine Win 10, remote machine mac mini M1 / macOS Monterey:

locking the session, physically turning off the display and letting macOS turn off the display after "x" minutes of inactivity, are all cause to rustdesk not being able to control the remote machine ("waiting for image" message).

Screens on remote systems are all connected via HDMI cable.

[MaCXyLo]

had the same issue today.
allow screen recording on "settings", "security and privacy" on the mac.
https://docs.microsoft.com/de-de/stream/media/stream-record-video/stream-record-video-privacy-setting.png
the keyboard input still seems to cause problems. maybe another permission problem?
didn't have time to take a closer look.

[rustdesk]

permission

#974 (comment)

[MaCXyLo]

teamviewer has a permission checker:
https://community.teamviewer.com/English/kb/articles/44699-remote-control-a-mac
seems to be a possible workaround.

otherwise: it would be even nicer if rustdesk would ask the user to grant the permission.

[MaCXyLo]

this stackoverflow thread describes how to change these kinds of permissions via terminal:
https://stackoverflow.com/questions/37865439/terminal-command-to-change-security-and-privacy-advanced-setting

[gioman]

Local machine Win 10, remote machine mac mini M1 / macOS Monterey:

locking the session, physically turning off the display and letting macOS turn off the display after "x" minutes of inactivity, are all cause to rustdesk not being able to control the remote machine ("waiting for image" message).

if the remote machine is a mac mini Intel / macOS Catalina the issue is slightly different:

physically turning off the display and letting macOS turn off the display after "x" minutes of inactivity do not seems to be a problem for rustdesk, while locking the session is: when the session is locked and the remote machine is unattended then rustdesk connects but show a static image of the desktop the moment the session was locked. If someone move the mouse on the remote machine than the login screen shows and the password can be entered.

[charlespick]

I'm having the same issue, connecting to a macos VM (running on a real mac), esxi with a video output that I can use with anydesk, macos's built in vnc, and the vsphere web console. But with rust desk it just connects and sits there. Frustrating cause anydesk seems to have a different issue right now

[L-Acacia]

Screen recording & accessibility need to be turned on the remote for the connection to work.

[Kukulkano]

I try to access MacOS 12.6 Monterey client using OpenSuse 15.3 Linux. Both running RustDesk 1.1.9.

I get asked the password and then the screen stays black saying "Connected, waiting for image...". There is no nightly DMG file I can try...

Screen recording & accessibility are turned on at the Mac.

[mon-jai]

I have a Windows host running nightly build. I tried connecting to it with Windows (v1.19 and nightly build) as well as Android v1.19.

I was not able to connect to the host with both Windows builds. v1.19 failed with the message "An existing connection was forcedly closed by the remote host OS ERROR 10054". Nightly hanged with "Connected, waiting for image..." prompt.

Android app connected to the remote host successfully after several attempts but the refresh rate was so low that makes RustDesk unusable, something like 1 frame/minute.

[G2G2G2G]

Connecting is fine with what @MaCXyLo said. Going into permissions and enabling the screen sharing.

We didn't get the keyboard and mouse to work though even though the "enable keyboard/mouse" was checked. We'll try some other things (restarting the computer) and such later

His stack overflow is probably the solution to an automated enable of the screensharing.

[29039]

MacOS upgrade from 10.14 to 13 and the Screen Recording permissions wasn't carried over, needing manual user intervention.

[zhOrange]

I get the same problem. Did some one have any ideas?

[GuilhermeWerner]

I have the same problem when trying to access a vm running on proxmox. I changed the privacy settings and it didn't work.

• Host: Proxmox VE 7.3-3
• VM: OpenCore Mac OS Ventura 13.1
• Client: Windows 11 Pro

[rafaelarcanjo]

Hi.

Any news on virtualized MacOS?

Thanks!

[GuilhermeWerner]

@rafaelarcanjo I tried it on several versions of macos and with different hardware configurations and they all have the same problem

[RLWestfall]

I had this same problem just now with RustDesk 1.1.9 installed on a MacBook Pro laptop with MacOS 10.15.7. I successfully enter the credentials to manage a remote MacBook Pro laptop that has RustDesk 1.1.9 installed. I get a popup window saying something to the effect the connection was successful and waiting for image. If you press the OK button on the popup window, the connection drops. The person on the other end of the connection sees my name pop up on their display after the successful login but I don't know if my name disappears from their display at the same time the connection drops on my end.

[mon-jai]

1.1.9 was released about one year ago.

Maybe you should try the latest nightly build.

[rustdesk]

#3261

[agentr14]

Anyone figure this out yet ?

[gioman]

Anyone figure this out yet ?

@agentr14 using one of these https://www.amazon.com/dp/B07YKGGQTJ?ref=ppx_yo2ov_dt_b_product_details&th=1 to workaround the issue.