-
-
Notifications
You must be signed in to change notification settings - Fork 7.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
App hangs on Connected, waiting for image.... #426
Comments
Do you have a monitor on the remote side? #59 |
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? |
I do not have a monitor on the remote side. |
@fufesou but it does not report "No display" error, you may need to consider this scenario. |
I have the same behaviour between my macbooks and macOS VM both running Monterey 12.4 and Rustdesk 1.1.9. |
Can someone help clarify here? what is the issue, the monitor being unplugged/sleeping and/or the session being locked? |
@gioman I've tested multiple scenarii:
Maybe the problem is on Opencore side... |
@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. |
had the same issue today. |
|
teamviewer has a permission checker: otherwise: it would be even nicer if rustdesk would ask the user to grant the permission. |
this stackoverflow thread describes how to change these kinds of permissions via terminal: |
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. |
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 |
Screen recording & accessibility need to be turned on the remote for the connection to work. |
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. |
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. |
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. |
MacOS upgrade from 10.14 to 13 and the Screen Recording permissions wasn't carried over, needing manual user intervention. |
I get the same problem. Did some one have any ideas? |
Hi. Any news on virtualized MacOS? Thanks! |
@rafaelarcanjo I tried it on several versions of macos and with different hardware configurations and they all have the same problem |
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. |
1.1.9 was released about one year ago. Maybe you should try the latest nightly build. |
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. |
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.
The text was updated successfully, but these errors were encountered: