remote-control
remote-control copied to clipboard
Screen Sharing "Network Problems"
Hey there!
Firstly thanks for great software, I really like it.
I'm experiencing some "networking issues" with screen sharing. It's when I'm trying to start session:
host server is on gigabit network connection, getting around ~900 mbit on speedtest:
Retrieving speedtest.net configuration...
Testing from Hetzner Online GmbH (49.12.99.49)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Goldenphone GmbH (Zug) [162.66 km]: 14.674 ms
Testing download speed................................................................................
Download: 854.91 Mbit/s
Testing upload speed......................................................................................................
Upload: 848.71 Mbit/s
I'm connecting to web panel using HSDPA+ connection (10/10 mbit) - also tried on fiber link connection getting same notices like above so I assume it's not the case.
Mobile client is on his own LTE link (100/42 mbit on speedtest).
So the thing is I'm getting view of mobile not always and it takes like 20-60 seconds to get it (during this period I see loader with jumping dots). During this period all keystrokes from web panel are propagated to mobile device.
Once the session is started it's quite stable.
How can I debug it? Or maybe I should tweak some server settings?
It's the same (or even worse) when I use Your srv.apuppet.org.
I've just tested, when i'm clicking buttons while having those dot's I'm getting screen faster I even think without clicking anything I wouldn't get screen casted at all.
When a smartphone displays static screen, the video encoder produces no traffic, and the media server thinks there's no traffic at all.
Unfortunately I don't know yet how to fix this encoder issue.
As a workaround, Apuppet has a "Flashing dot while sharing" feature. Which displays a flashing dot in the top left corner of the screen. This option requires granting the "Draw on top" permission to the Apuppet mobile agent.
Please try to set this checkbox in the app settings, and perhaps this will help.
Hi, thanks for prompt reply.
Are You sure it's the case? I'm able to send keystrokes so I'm clicking "expand status bar" to show status bar and home button to close it and they are propagated to mobile (I see on mobile screen it's doing it), but screen in web interface is not immediately shown, it looks more random to me right now.
Expanding status bar generates more dynamicity on screen than this tiny flashing dot so I guess it should be enought to start sending traffic?
Ok, so I've tested on Xiaomi Redmi 4 phone. When I get those dots jumping and can't get screen cast for a long time always turning off display (through hw button on mobile) and clicking home button on web interface is helping initialize screen casting.
Probably it will be the same using home button on mobile - I need to verify that. And I'll test other phone.
Control commands and screencast use different ports. So even if you're able to send commands, the screen can still delay.
Do you see a green flashing dot in the left top corner of the screen when the screen is sharing?
@h-mdm I know that commands and screen sharing use different ports / services, I see green flashing dot in left top corner of the screen but this is not the case - as I mentioned eralier I'm doing lot of big changes on screen and dots are still jumping on web admin panel... On redmi 4x (Android 7.2) turning off display and clicking home button helps, on Samsung Galaxy 9+ (Android 10) I can't find any solution that make showing screen more reliable.
How can I start debugging it. On web panel or form janus side or it's mobile app? Maybe You could give some pointers to janus docs etc.?
The traffic can be lost at any point, or this could be an encoder/decoder issue. The information about the UDP port and other RTP parameters is written in logcat. Also, there is some console output in the web panel.
What you could try is to rebuild Apuppet with USE_GOOGLE_ENCODER=true (in app/build.gradle). This replaces a hardware codec by a software codec (Google). This may a bit corrupt the image but there are more chances that you will see something.