mirror of
https://github.com/rustdesk/rustdesk.git
synced 2026-03-02 19:26:56 -05:00
"waiting for image" issues #2107
Labels
No labels
bug
documentation
duplicate
enhancement
enhancement
enhancement
good first issue
help wanted
invalid
question
unreproducible
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/rustdesk-rustdesk#2107
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @rustdesk on GitHub (Sep 5, 2023).
Unresolved
@Aqua1ung commented on GitHub (Sep 24, 2023):
Just FYI, I am getting this one on Android with the latest Rustdesk nightly as of Sept. 24, 2023. Client on Clear Linux, server on Android.
@mclovin-2k commented on GitHub (Oct 8, 2023):
I'm facing the same issue when I try to connected to a locked Android phone with Rustdesk v1.2.3.
I think this issue was happening since v1.2.1, but you can workaround this by clicking cancel button on the "waiting for image" dialog.
Since v1.2.2, clicking cancel button will disconnect the device, which make Rustdesk completely unusable on Android.
@Aqua1ung commented on GitHub (Oct 9, 2023):
The current workaround is to click the Home button (which will make the "Successful/Cancel" window disappear), and then click on the screen. (You may need to enable "Mobile Actions" to see the "Home" button.)
@Aqua1ung commented on GitHub (Oct 30, 2023):
Apparently this workaround ^ no longer works with the latest nightly (Oct. 30).
@Aqua1ung commented on GitHub (Nov 2, 2023):
The workaround started working again with the latest 2 releases.
@rustdesk commented on GitHub (Dec 18, 2023):
https://www.reddit.com/r/rustdesk/comments/18ig4ap/succesful_connected_waiting_for_image/
@mclovin-2k commented on GitHub (Feb 19, 2024):
But Android didn't have this issue until v1.2.1 or v1.2.0.
Could you maybe fix this on Android first, please?
I think quickest way to do this is revert related code to older version or just remove this dialog on Android client.
@asdf4w3t5 commented on GitHub (Mar 4, 2024):
after arch linux update now rustdesk is getting this error. But I guess many devices have had it for a while
I can see their mouse moving but can't see the screen lol
FWIW I installed the flatpak and it all works now. I'll just delete the other version.
@ArchPrime commented on GitHub (Aug 5, 2024):
That doesn't work for me. Remote computer is running installed 1.2.6 Client on Windows 10.
No other remote computer affected this way.
@rustdesk commented on GitHub (Aug 20, 2024):
@ArchPrime please try out this, https://github.com/rustdesk/rustdesk/discussions/9124#discussioncomment-10391439
@ArchPrime commented on GitHub (Aug 20, 2024):
Thanks - will do as soon as I can, though I likely won't have physical access to the other end for a few weeks.
@cesar93600 commented on GitHub (Dec 9, 2024):
Hello, I had the same problem.
Version 1.3.3 (installed or not).
From 2 machines (Windows Server and Desktop) to a Windows 10 Client.
It was not a network problem, I could transfer files in the background.
I disabled "Capture screen using DirectX".
Problem solved
@ArchPrime commented on GitHub (Dec 9, 2024):
Thanks – good to know. In my case uninstall and reinstall of version 1.3.1 on all machines also seemed to do the trick (but this required physical access to all machines)
From: cesar93600 @.>
Sent: Tuesday, 10 December 2024 3:48 am
To: rustdesk/rustdesk @.>
Cc: Paul King @.>; Mention @.>
Subject: Re: [rustdesk/rustdesk] "waiting for image" issues (Issue #5609)
Hello, I had the same problem.
Version 1.3.3 (installed or not).
From 2 machines (Windows Server and Desktop) to a Windows 10 Client.
It was not a network problem, I could transfer files in the background.
I disabled "Capture screen using DirectX".
Problem solved
—
Reply to this email directly, view it on GitHubhttps://github.com/rustdesk/rustdesk/issues/5609#issuecomment-2528182738, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AEBZ5YC5GR4WXRDMKS3YGEL2EWUQ5AVCNFSM6AAAAAA4L6OGO2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMRYGE4DENZTHA.
You are receiving this because you were mentioned.Message ID: @.@.>>
@21pages commented on GitHub (Dec 9, 2024):
If disabling the
Capture screen using DirectXoption resolves your issue, I would like to further investigate the problem with it. Please run the program below on the controlled side and enable theCapture screen using DirectXoption.When you see waiting for image, please upload the log file from the controlled side.
https://github.com/21pages/rustdesk/releases/download/directx/rustdesk-1.3.5-x86_64.exe
Log file path:
If not installed on the controlled side:
%AppData%\RustDesk\log\RustDesk_rCURRENT.logIf installed on the controlled side:
C:\Windows\ServiceProfiles\LocalService\AppData\Roaming\RustDesk\log\server\RustDesk_rCURRENT.logThe log file contains lots of
====DEBUG====lines. Remove personal informations before upload the file.@cesar93600 commented on GitHub (Dec 10, 2024):
Unfortunately I could not reproduce the error.
When I launched your version 1.3.5 (i could not connect the server), i had to start the service (but it was version 1.3.3 that was launched because it was installed).
I uninstalled 1.3.3, with 1.3.5 I no longer had the "waiting for image" error.
I reinstalled 1.3.3 with the .msi (I no longer had the "waiting for image" error either).
I will soon deploy Rustdesk on other workstations, I will try first with your version 1.3.5 (DEBUG).
@21pages commented on GitHub (Dec 10, 2024):
Thanks
@cesar93600 commented on GitHub (Dec 10, 2024):
I attach the logs of 1.3.3.
Maybe a clue.
RustDesk_rCURRENT_1.3.3_WAITING_FOR_IMAGE.log
RustDesk_rCURRENT_1.3.3_DISABLED_DIRECTX.log
@21pages commented on GitHub (Dec 10, 2024):
Thank you, the log is in the file named with the occurrence time
@cesar93600 commented on GitHub (Dec 11, 2024):
Sorry, I was not available.
Here are all the logs.
logs.zip
@21pages commented on GitHub (Dec 11, 2024):
Thank you, I found an anomaly in the logs. The hardware encoding got stuck while encoding the second frame. You don't need to disable DirectX; just disable hardware encoding. I will put the modified program here, and if you have time, you can test it. This will help us a lot.
Tests that will help:
@cesar93600 commented on GitHub (Dec 11, 2024):
Today, I was able to reproduce the error "waiting for image" (disabling "Hardware Codec" solves the problem).
But you have to restart Rustdesk after disabling and re-enabling "Hardware Codec" otherwise message "waiting for image".
I perform the tests by connecting in parallel with Anydesk.
I did the tests with the uninstalled versions 1.3.5 official, debug version from yesterday, hwcodec-stuck and update_vcpkg.
The results are the same.
Settings
Show quality Monitor : Enabled
Default codec : Auto
Hardware Codec : Enabled
Codec: AUTO (H264)
No error but the image is frozen, even if i switch between VP8, VP9, AV1, H264 and AUTO.
The mouse and keyboard work.
Show quality Monitor
Hardware Codec : Disabled
Codec : AUTO (VP9)
No error, switch OK between VP8, VP9, AV1 and AUTO.
Show quality Monitor
logs.zip
@21pages commented on GitHub (Dec 11, 2024):
Thanks for all the tests, it stuck at
avcodec_send_frame, it's very helpful!@21pages commented on GitHub (Dec 13, 2024):
@cesar93600 I still have some questions, you can do the following when you have time,
When waiting for image happens, not stop the RustDesk process, just disable DirectX option, connect again, will waiting for image disappear? I want to confirm wheter stop the RustDesk process is needed for the disable DirectX option to take effect, if need to stop RustDesk process, it's stuck.
New logs added into FFmpeg source code in this link:
https://github.com/21pages/rustdesk/releases/download/hwcodec-stuck-log-build/rustdesk-1.3.5-x86_64.exe
Could you try it with Hwcodec and directx enabled and show the log?
Better to show 2 kinds of logs, one is waiting for image, another is frozen image.
Change the FFmpeg source code, this program may fix the stuck. Enable directx, enable hwcodec, use h264, if fallback to software encoders, it works. https://github.com/21pages/rustdesk/releases/download/hwcodec-stuck-log-build/rustdesk-1.3.5-x86_64-try-fix.exe
What is your GPU graphics card and driver version?
When running the following command using ffmpeg in the command line, can it succeed?
ffmpeg -i h265.mp4 -c:v h264_amf h264.mp4https://www.gyan.dev/ffmpeg/builds/packages/ffmpeg-7.0.2-full_build.7z
h265.zip
@cesar93600 commented on GitHub (Dec 16, 2024):
I confirm, you have to restart Rustdesk to apply the changes correctly.
Otherwise "freeze" or "waiting for image".
Reboot (HW and/or DX disabled)
1 - Enable HW or DX (reconnect without restart) "freeze"
2 - Disable HW or DX (reconnect without restart) "waiting for image"
No problem with the version "rustdesk-1.3.5-x86_64-try-fix.exe"
Video Chipset : AMD Radeaon R5 Series
Video conversion works with ffmpeg.
I have attached all the logs and screenshots. logs.zip
@21pages commented on GitHub (Dec 16, 2024):
Thanks for your test, according to the logs, I can confirm it's caused by FFmpeg amf encode stuck, and https://github.com/rustdesk/rustdesk/pull/10283 may fix it, but because it shows
vram_encode: []in thetry_fixlogs, the fallback can't be tested, could you try more times?Only test the condition below:
Use https://github.com/21pages/rustdesk/releases/download/hwcodec-stuck-log-build/rustdesk-1.3.5-x86_64-try-fix.exe, enable hwcodec, enable directx.
if
vram_encode: [FeatureContextis in the latest log, connect with h264, it should fallback to VP9, test end.if
vram_encode: []is in the latest log, restart RustDesk and check the latest log.If you can' see
vram_encode: [FeatureContextafter many times, could you show the logs in%appdata%\RustDesk\log\check-hwcodec-configafter restartingtry-fixprogram?So it still needs improvement.
@cesar93600 commented on GitHub (Dec 16, 2024):
With the version "rustdesk-1.3.5-x86_64-try-fix.exe" I don't have the H264 option, it automatically connects with VP9.
Even if I select VP8, AV1 or H264 in the settings and restart Rustdesk on both sides.
But it switches (between VP8, VP9 and AV1) if I change the codec live.
@21pages commented on GitHub (Dec 16, 2024):
The reason is that there is a check process at RustDesk startup, it filters the h264, and treat h264 as unusable.
%appdata%\RustDesk\log\check-hwcodec-configfirst?In early tests, it can encode one image, but it may not able to encode one image with this program. If you try several times, it still not shows, feel free to stop trying.
@cesar93600 commented on GitHub (Dec 16, 2024):
With version "1.3.5_try-fix"
I don't have the h264 option, even if I restart several times.
With version "1.3.5_nightly"
I have the "freeze" and "waiting for image" (restart necessary to apply the settings correctly)
When I switched live between VP9 and h264, it remained stuck on h264.
h264 only appears if HW and DX are enabled.
logs.zip
@21pages commented on GitHub (Dec 16, 2024):
Thanks for the tests, sorry, we forgot to clear cache before build FFmpeg, please try next nightly.
@21pages commented on GitHub (Dec 16, 2024):
The new nightly is ready, https://github.com/rustdesk/rustdesk/releases/download/nightly/rustdesk-1.3.5-x86_64.exe. expect: "waiting for image" or "image freeze" should never occur, and no h264 option.
@cesar93600 commented on GitHub (Dec 16, 2024):
With this version everything works fine, in portable or installed version.
On a workstation that was causing problems.
HW and DX enabled, no "freeze" or "waiting for image", no h264 option and switch between codecs ok.
logs.zip
On a workstation that was not causing problems.
HW and DX enabled, h264 option available and switch between codecs ok.
Thanks for your work.
A particular behavior:
With the portable version if the service is not started it does not connect to the Rustdesk server (maybe because of a previous installation)
@datafeng commented on GitHub (Feb 8, 2025):
@gepbird commented on GitHub (Feb 20, 2025):
Having this issue with rustdesk 1.3.7 on linux. A workaround I'm using is changing the codecs from the default H264 to anything else for the session when I see the "Successful; Connected, waiting for image" message.
It could be a packaging issue at nixpkgs, I'll investigate.
@Aqua1ung commented on GitHub (Mar 13, 2025):
Any news about this?
@EvanZhu2000 commented on GitHub (Mar 31, 2025):
still experiencing this issue 1.3.8 mac, any updates?
@Alfex4936 commented on GitHub (Apr 10, 2025):
happened sometimes on windows11, new version.
some problems of lock or smth idk (or dual monitor setup), it happens so rarely.
I could fix it by adding virtual display and move around
@campodoro74 commented on GitHub (Apr 29, 2025):
Still same problem. Mac console, Pixel client: waiting for image
@grocal commented on GitHub (Jul 19, 2025):
I can reproduce that error easily.
Android -> Windows 10
Both 1.4.0
Windows 10 has 3 monitors connected and turned on. OS detects 3 of them. Start Rustdesk - in my case as a service with my own ID/relay server. Now fire up Rustdesk on Android and connect. It works.
And now turn monitors off. In my case OS ends up with only one monitor active/detected (two monitors are display port connected so turning them off disconnects them). Try to connect from Android now. Pop-up on that last monitor shows up that there's connection but "waiting for image" stays on Android.
If now I restart Rustdesk on Windows I can connect while one monitor is active. Then if I turn other monitors on - problem comes back.
TLDR; If you change monitor configuration while Rustdesk is on and change their number you will have "waiting for image". Locking Windows with multiple active monitors is the same situation as locking turns off other monitors except the main one.
I hope I helped a little.
@kanslor commented on GitHub (Sep 12, 2025):
I also encountered the "waiting for image" situation.
My controlled client is Windows Server 2012 R2, and it is located far away from the relay server, so the connection from my side is very slow.
When connecting, the same issue occurs. At that time, I noticed that the mouse on my controlled client (desktop mode)would move to the top-left corner, and it seemed as if a right-click operation was performed, causing a context menu to appear.
Would this information help you identify the root cause of the problem?
The Client Version is 1.4.1(lates version)
@21pages commented on GitHub (Sep 12, 2025):
@kanslor
Thanks for your feedback, could you try out https://github.com/21pages/rustdesk/releases/tag/waiting-for-image both sides and show the log lines containing
====? https://github.com/rustdesk/rustdesk/wiki/FAQ#access-logs@kanslor commented on GitHub (Sep 12, 2025):
@21pages I used this vserion and test for connection, I can't find any log lines containing
====DEBUG====the whole log lines lists:
controlled side either.
@21pages commented on GitHub (Sep 12, 2025):
@kanslor
Thanks for your feedback. From the controller logs, we can see that no video frames were received, but the controlled side should have a message like
====DEBUG==== video service run display_idx: 0.Could you check whether you’ve located the correct path for the controlled side logs?
On Windows,
C:\Windows\ServiceProfiles\LocalService\AppData\Roaming\RustDesk\log\server\RustDesk_rCURRENT.log%AppData%\RustDesk\log\RustDesk_rCURRENT.log@kanslor commented on GitHub (Sep 12, 2025):
@21pages
update the controlled side log:
@21pages commented on GitHub (Sep 12, 2025):
We can see that the controlled end sends the video frame to the controling end. Please check if there are log lines containing
====DEBUG==== VideoFrameon the controlling end when waiting for image happens? If can't find the corresponding log, it may be that the network is too poor.@kanslor commented on GitHub (Sep 12, 2025):
@21pages
Yes, the network connection between the problematic host and the relay server is not very good, as it involves cross-region access.
In my own tests, connections to hosts within the same region work normally without encountering this issue; the problem only occurs with cross-region access.
I have also noticed that when the Windows Server 2012 R2 remote endpoint opens the Start menu interface, subsequent remote connections have a higher probability of successfully displaying the image. In other scenarios, the image almost never loads, and the interface typically shows the message "Receiving image." This observation seems to suggest that the impact of weak network connectivity may not be the primary factor. Do you have any relevant clues or insights to share?
@21pages commented on GitHub (Sep 12, 2025):
https://www.reddit.com/r/rustdesk/comments/1cr8kfv/should_you_selfhost_a_rustdesk_server/
@artiemedvedev commented on GitHub (Oct 27, 2025):
I've got the same issue recently. All worked fine and one day I got "waiting for image" issue.
I have two machines with samish hardware (the only difference is a CPU). Both machines are connected to the same network. Both machines are connected to the WireGuard VPN but RustDesk is added to non-tunneled apps (bypassing VPN).
Control side: Windows 11 Home Laptop.
The first controlled machine: runs Windows 11 Home and has Ryzen 5900X CPU + 3xRTX3090 - connection is ok.
The second controlled machine: runs Windows 11 Pro and has Ryzen 5700X CPU + 3xRTX3090 - connection was ok, got "waiting for image" issue recently. Sometimes after waiting for image for too long, connection to machine fails (remote side offline) and restores after 10-60 seconds.
If I switch the second machine to run via VPN it connects and shows image with no issues. But first machine runs ok without VPN. Tried multiple days - same.
Tried with my own signaling and relay server - same.
Here is the log of the case when I got "waiting for image" without VPN.
[2025-10-27 10:48:46.675233 +03:00] INFO [src\client.rs:407] rendezvous server: rs-ny.rustdesk.com:21116
[2025-10-27 10:48:46.675429 +03:00] INFO [src\client.rs:470] #1 TCP punch attempt with 192.168.1.67:53541, id: 154955227
[2025-10-27 10:48:46.906150 +03:00] ERROR [src\client.rs:3632] Connection closed: Remote desktop is offline(0)
[2025-10-27 10:48:46.906218 +03:00] DEBUG [src\clipboard.rs:169] try to empty client cliprdr for conn_id 0
[2025-10-27 10:48:46.906240 +03:00] INFO [src\client\io_loop.rs:1057] sync transfer job status
[2025-10-27 10:48:46.906679 +03:00] INFO [src\client\io_loop.rs:1068] meta: TransferSerde { write_jobs: [], read_jobs: [] }
[2025-10-27 10:48:46.906704 +03:00] INFO [src\client.rs:2941] Audio decoder loop exits
[2025-10-27 10:48:52.578800 +03:00] INFO [src\flutter.rs:1392] Session 154955227 start, use texture render: true
[2025-10-27 10:48:53.154633 +03:00] DEBUG [src\client.rs:392] TCP connection establishment time used: 574.4271ms
[2025-10-27 10:48:53.154700 +03:00] INFO [src\client.rs:407] rendezvous server: rs-ny.rustdesk.com:21116
[2025-10-27 10:48:53.154808 +03:00] INFO [src\client.rs:470] #1 TCP punch attempt with 192.168.1.67:53542, id: 154955227
[2025-10-27 10:48:53.375676 +03:00] ERROR [src\client.rs:3632] Connection closed: Remote desktop is offline(0)
[2025-10-27 10:48:53.375739 +03:00] DEBUG [src\clipboard.rs:169] try to empty client cliprdr for conn_id 0
[2025-10-27 10:48:53.375758 +03:00] INFO [src\client\io_loop.rs:1057] sync transfer job status
[2025-10-27 10:48:53.376227 +03:00] INFO [src\client\io_loop.rs:1068] meta: TransferSerde { write_jobs: [], read_jobs: [] }
[2025-10-27 10:48:53.376310 +03:00] INFO [src\client.rs:2941] Audio decoder loop exits
[2025-10-27 10:49:05.376664 +03:00] INFO [src\flutter.rs:1392] Session 154955227 start, use texture render: true
[2025-10-27 10:49:05.766816 +03:00] DEBUG [src\client.rs:392] TCP connection establishment time used: 388.7252ms
[2025-10-27 10:49:05.766908 +03:00] INFO [src\client.rs:407] rendezvous server: rs-ny.rustdesk.com:21116
[2025-10-27 10:49:05.767050 +03:00] INFO [src\client.rs:470] #1 TCP punch attempt with 192.168.1.67:53548, id: 154955227
[2025-10-27 10:49:08.985998 +03:00] INFO [src\client.rs:470] #2 TCP punch attempt with 192.168.1.67:53548, id: 154955227
[2025-10-27 10:49:14.987240 +03:00] INFO [src\client.rs:470] #3 TCP punch attempt with 192.168.1.67:53548, id: 154955227
[2025-10-27 10:49:17.473186 +03:00] INFO [src\client.rs:532] relay requested from peer, time used: 12.0950969s, relay_server: ovh-fr1.rustdesk.com
[2025-10-27 10:49:18.047041 +03:00] INFO [src\client.rs:572] 573.8168ms used to establish Relay connection
[2025-10-27 10:49:21.079476 +03:00] DEBUG [src\client\io_loop.rs:204] get cliprdr client for conn_id 13
[2025-10-27 10:49:21.730960 +03:00] DEBUG [src\ui_session_interface.rs:1718] handle_peer_info :PeerInfo { username: "artie", hostname: "nest", platform: "Windows", displays: [DisplayInfo { x: 0, y: 0, width: 1920, height: 1080, name: "\\.\DISPLAY13", online: true, cursor_embedded: false, original_resolution: MessageField(Some(Resolution { width: 1920, height: 1080, special_fields: SpecialFields { unknown_fields: UnknownFields { fields: None }, cached_size: CachedSize { size: 0 } } })), scale: 1.0, special_fields: SpecialFields { unknown_fields: UnknownFields { fields: None }, cached_size: CachedSize { size: 0 } } }], current_display: 0, sas_enabled: true, version: "1.4.3", features: MessageField(Some(Features { privacy_mode: true, terminal: true, special_fields: SpecialFields { unknown_fields: UnknownFields { fields: None }, cached_size: CachedSize { size: 0 } } })), encoding: MessageField(Some(SupportedEncoding { h264: true, h265: true, vp8: true, av1: true, i444: MessageField(Some(CodecAbility { vp8: false, vp9: true, av1: true, h264: false, h265: false, special_fields: SpecialFields { unknown_fields: UnknownFields { fields: None }, cached_size: CachedSize { size: 0 } } })), special_fields: SpecialFields { unknown_fields: UnknownFields { fields: None }, cached_size: CachedSize { size: 0 } } })), resolutions: MessageField(Some(SupportedResolutions { resolutions: [Resolution { width: 1024, height: 768, special_fields: SpecialFields { unknown_fields: UnknownFields { fields: None }, cached_size: CachedSize { size: 0 } } }, Resolution { width: 1360, height: 768, special_fields: SpecialFields { unknown_fields: UnknownFields { fields: None }, cached_size: CachedSize { size: 0 } } }, Resolution { width: 1440, height: 900, special_fields: SpecialFields { unknown_fields: UnknownFields { fields: None }, cached_size: CachedSize { size: 0 } } }, Resolution { width: 1600, height: 900, special_fields: SpecialFields { unknown_fields: UnknownFields { fields: None }, cached_size: CachedSize { size: 0 } } }, Resolution { width: 1600, height: 1200, special_fields: SpecialFields { unknown_fields: UnknownFields { fields: None }, cached_size: CachedSize { size: 0 } } }, Resolution { width: 1920, height: 1080, special_fields: SpecialFields { unknown_fields: UnknownFields { fields: None }, cached_size: CachedSize { size: 0 } } }, Resolution { width: 1920, height: 1200, special_fields: SpecialFields { unknown_fields: UnknownFields { fields: None }, cached_size: CachedSize { size: 0 } } }, Resolution { width: 2560, height: 1440, special_fields: SpecialFields { unknown_fields: UnknownFields { fields: None }, cached_size: CachedSize { size: 0 } } }, Resolution { width: 3840, height: 2160, special_fields: SpecialFields { unknown_fields: UnknownFields { fields: None }, cached_size: CachedSize { size: 0 } } }], special_fields: SpecialFields { unknown_fields: UnknownFields { fields: None }, cached_size: CachedSize { size: 0 } } })), platform_additions: "{"amyuni_virtual_displays":1,"has_file_clipboard":true,"idd_impl":"amyuni_idd","is_installed":true,"support_view_camera":true,"supported_privacy_mode_impl":"privacy_mode_impl_exclude_from_capture","privacy_mode_impl_mag_tip"],["privacy_mode_impl_virtual_display","privacy_mode_impl_virtual_display_tip"}", windows_sessions: MessageField(None), special_fields: SpecialFields { unknown_fields: UnknownFields { fields: None }, cached_size: CachedSize { size: 0 } } }
[2025-10-27 10:49:21.735151 +03:00] INFO [src\client.rs:2578] peer info supported_encoding:SupportedEncoding { h264: true, h265: true, vp8: true, av1: true, i444: MessageField(Some(CodecAbility { vp8: false, vp9: true, av1: true, h264: false, h265: false, special_fields: SpecialFields { unknown_fields: UnknownFields { fields: None }, cached_size: CachedSize { size: 0 } } })), special_fields: SpecialFields { unknown_fields: UnknownFields { fields: None }, cached_size: CachedSize { size: 0 } } }
[2025-10-27 10:49:21.735455 +03:00] INFO [src\clipboard.rs:812] Subscribe clipboard listener: client-clipboard
[2025-10-27 10:49:21.735468 +03:00] INFO [src\clipboard.rs:821] Start clipboard listener thread
[2025-10-27 10:49:21.736060 +03:00] INFO [src\clipboard.rs:838] Clipboard listener thread started
[2025-10-27 10:49:21.736080 +03:00] INFO [src\clipboard.rs:841] Clipboard listener subscribed: client-clipboard
[2025-10-27 10:49:21.736102 +03:00] INFO [src\client.rs:982] Start client clipboard loop
[2025-10-27 10:49:21.736054 +03:00] DEBUG [src\clipboard.rs:876] Clipboard listener started
[2025-10-27 10:49:21.757722 +03:00] DEBUG [src\client.rs:2932] recved audio format, sample rate=48000
[2025-10-27 10:49:21.758803 +03:00] INFO [src\client.rs:1350] Using default output device: "Speakers (2- Realtek(R) Audio)"
[2025-10-27 10:49:21.759583 +03:00] INFO [src\client.rs:1356] Default output format: SupportedStreamConfig { channels: 2, sample_rate: SampleRate(48000), buffer_size: Range { min: 0, max: 4294967295 }, sample_format: F32 }
[2025-10-27 10:49:21.759600 +03:00] INFO [src\client.rs:1357] Remote input format: AudioFormat { sample_rate: 48000, channels: 2, special_fields: SpecialFields { unknown_fields: UnknownFields { fields: None }, cached_size: CachedSize { size: 0 } } }
@wildwind123 commented on GitHub (Nov 23, 2025):
i got same. "Connected, waiting for image...".
Linux -> windows 11.
I connect string like
I disable vpn. And it work.
@mrfakeryangs-coder commented on GitHub (Jan 4, 2026):
i got same too. I had to reboot my client to fixed it temporarily.But this problem still exists.
@Lippiece commented on GitHub (Jan 13, 2026):
Which client? The one you connect to or the one you connect from?
@Aqua1ung commented on GitHub (Jan 26, 2026):
I couldn't believe my eyes, but apparently enabling "Disable screen share protections" in Android's "Developer options" seems to be fixing this issue!!
Android users, give it a try!
[Of course, when enabling RustDesk's "Screen Capture" service, you still have to manually allow "Screen Capture." Nevertheless, the service can stay in the background all the time.]
@Il-po commented on GitHub (Feb 1, 2026):
same problem guys even enable disable screen share protections! Mac->android 15
rustdesk last version