search

FDH2 / UxPlay

AirPlay Unix mirroring server
GNU General Public License v3.0
1.55k stars 78 forks source link

After ~20 minutes my screen mirroring freeze forever #58

Closed k0ste closed 2 years ago

k0ste commented 2 years ago

Hi, just started to use uxplay today, 1.46, then compile from git

The command is:

uxplay -s 3840x2160 -vs "waylandsink fullscreen=true" -fps 60 -as 0 -d

The problem is: after ~20 minutes screen mirror (Wayland window on Linux) freeze and on debug I see this:

POST /feedback RTSP/1.0
CSeq: 1066
DACP-ID: 92E04835971C9CF6
Active-Remote: 2323908967
User-Agent: AirPlay/600.8.1

Handling request POST with URL /feedback
raop_handler_feedback

RTSP/1.0 200 OK
CSeq: 1066
Server: AirTunes/220.68

raop_ntp send_len = 32
raop_ntp receive time type_t packetlen = 32
raop_ntp sync correction = 0
raop_ntp send_len = 32
raop_ntp receive timeout
raop_ntp send_len = 32
raop_ntp receive timeout
raop_ntp send_len = 32
raop_ntp receive timeout
raop_ntp send_len = 32
raop_ntp receive timeout
raop_ntp send_len = 32
raop_ntp receive timeout
raop_ntp send_len = 32
raop_ntp receive timeout
raop_ntp send_len = 32
raop_ntp receive timeout
raop_ntp send_len = 32
raop_ntp receive timeout
raop_ntp send_len = 32
raop_ntp receive timeout
raop_ntp send_len = 32
raop_ntp receive timeout

Mac machine in this case don't drop connection After some time RTP seems work again, but screen freezes for forever

Reconnect (e.g. disable mirroring on Mac and reenable) - impossible, MacOS just can't connect again, restart of uxplay resolve's this problem

Any ideas what is wrong? Power savings on Linux machine was disabled (for Wi-Fi module and for PC in Gnome settings)

k0ste commented 2 years ago 
using system MAC address 9c:b6:d0:95:a7:1d
Initialized server socket(s)
Accepted IPv4 client on socket 29
Local: 192.168.1.11
Remote: 192.168.1.4
Open connections: 1
Client identified as User-Agent: AirPlay/605.1
Accepted IPv4 client on socket 31
Local: 192.168.1.11
Remote: 192.168.1.4
Open connections: 2
raop_rtp_mirror starting mirroring
raop_ntp receive timeout 1 (limit 10) (request sent 1644426643380610)
raop_ntp receive timeout 2 (limit 10) (request sent 1644426646690137)
raop_ntp receive timeout 3 (limit 10) (request sent 1644426649995505)
raop_ntp receive timeout 4 (limit 10) (request sent 1644426653303961)
raop_ntp receive timeout 5 (limit 10) (request sent 1644426656609119)
raop_ntp receive timeout 6 (limit 10) (request sent 1644426659915809)
raop_ntp receive timeout 7 (limit 10) (request sent 1644426663222462)
raop_ntp receive timeout 8 (limit 10) (request sent 1644426666529860)
raop_ntp receive timeout 1 (limit 10) (request sent 1644427870367410)
raop_ntp receive timeout 2 (limit 10) (request sent 1644427873675722)
raop_ntp receive timeout 3 (limit 10) (request sent 1644427876982366)
raop_ntp receive timeout 4 (limit 10) (request sent 1644427880289991)
raop_ntp receive timeout 5 (limit 10) (request sent 1644427883597582)
raop_ntp receive timeout 6 (limit 10) (request sent 1644427886902072)
raop_ntp receive timeout 7 (limit 10) (request sent 1644427890209144)
raop_ntp receive timeout 8 (limit 10) (request sent 1644427893515394)
raop_ntp receive timeout 9 (limit 10) (request sent 1644427896822360)
raop_ntp receive timeout 10 (limit 10) (request sent 1644427900130005)
***ERROR lost connection with client
Removing connection for socket 29
Destroying connection
Open connections: 1
Removing connection for socket 31
Destroying connection
Open connections: 0
Initialized server socket(s)

And after this connection was closed (Mac streaming stop too)

fduncanh commented 2 years ago

@k0ste This is what is intended. You can then reconnect. (The frozen window should be left in place, and it should unfreeze when you reconnect)

fduncanh commented 2 years ago

Your output shows that it first froze at 1644426643[380610] secs, for 8 timeouts (24 secs), then froze again at 1644427870[367410] secs (1227 secs = 20 mins later), was still frozen after 10 timeoits (the default close connection limit).

Maybe try with uxplay -reset 0 which gives no timeout limit, and see how long your session lasts (in that case , with -reset 0, only ECONNRESET will close the connection) ( or try -reset 100, which will wait for 5 minutes of timeouts before resetting, I guess ECONNRESET will happen before that)

k0ste commented 2 years ago

I think you was right, that this is network issue. I think by some reason Access Point don't forward packets from Mac to Linux at some point of time

?1 ~ % sudo arping -I en0 192.168.1.11
ARPING 192.168.1.11
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
42 bytes from 9c:b6:d0:95:a7:1d (192.168.1.11): index=0 time=364.258 msec  <--------- on/off wi-fi toggle on Linux
42 bytes from 9c:b6:d0:95:a7:1d (192.168.1.11): index=1 time=182.840 msec
42 bytes from 9c:b6:d0:95:a7:1d (192.168.1.11): index=2 time=102.440 msec
42 bytes from 9c:b6:d0:95:a7:1d (192.168.1.11): index=3 time=18.915 msec
42 bytes from 9c:b6:d0:95:a7:1d (192.168.1.11): index=4 time=349.109 msec
42 bytes from 9c:b6:d0:95:a7:1d (192.168.1.11): index=5 time=167.002 msec
42 bytes from 9c:b6:d0:95:a7:1d (192.168.1.11): index=6 time=88.247 msec
42 bytes from 9c:b6:d0:95:a7:1d (192.168.1.11): index=7 time=419.358 msec
42 bytes from 9c:b6:d0:95:a7:1d (192.168.1.11): index=8 time=339.904 msec
42 bytes from 9c:b6:d0:95:a7:1d (192.168.1.11): index=9 time=153.424 msec
42 bytes from 9c:b6:d0:95:a7:1d (192.168.1.11): index=10 time=75.004 msec
42 bytes from 9c:b6:d0:95:a7:1d (192.168.1.11): index=11 time=404.698 msec
42 bytes from 9c:b6:d0:95:a7:1d (192.168.1.11): index=12 time=321.817 msec
42 bytes from 9c:b6:d0:95:a7:1d (192.168.1.11): index=13 time=135.292 msec
42 bytes from 9c:b6:d0:95:a7:1d (192.168.1.11): index=14 time=52.226 msec
42 bytes from 9c:b6:d0:95:a7:1d (192.168.1.11): index=15 time=380.586 msec
42 bytes from 9c:b6:d0:95:a7:1d (192.168.1.11): index=16 time=198.687 msec
42 bytes from 9c:b6:d0:95:a7:1d (192.168.1.11): index=17 time=114.296 msec

I really don't see this ARP's on Linux kernel. But from Linux to Mac ARP's work, and as we can see for first ARP, the Linux really don't know 38:F9:D3:C8:1E:CE neighbour

[k0ste@WorkStation ~]$ sudo arping -I wlan0 192.168.1.4
ARPING 192.168.1.4 from 192.168.1.11 wlan0
Unicast reply from 192.168.1.4 [38:F9:D3:C8:1E:CE]  171.529ms <---- first long discovery 
Unicast reply from 192.168.1.4 [38:F9:D3:C8:1E:CE]  93.145ms
Unicast reply from 192.168.1.4 [38:F9:D3:C8:1E:CE]  5.029ms
Unicast reply from 192.168.1.4 [38:F9:D3:C8:1E:CE]  37.989ms
Unicast reply from 192.168.1.4 [38:F9:D3:C8:1E:CE]  5.303ms
Unicast reply from 192.168.1.4 [38:F9:D3:C8:1E:CE]  5.299ms
Unicast reply from 192.168.1.4 [38:F9:D3:C8:1E:CE]  5.125ms
Unicast reply from 192.168.1.4 [38:F9:D3:C8:1E:CE]  5.217ms
Unicast reply from 192.168.1.4 [38:F9:D3:C8:1E:CE]  5.334ms
Unicast reply from 192.168.1.4 [38:F9:D3:C8:1E:CE]  5.290ms
Unicast reply from 192.168.1.4 [38:F9:D3:C8:1E:CE]  5.393ms

I.e this is L2 issue, may be not actually Mac or Linux, because another networking on Linux is working. When I was primary woking on this Dell XPS 13 9380, I was really hate this adapter after Intel adapters (iwlwifi)

02:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32)
        Subsystem: Rivet Networks Killer 1435 Wireless-AC

This adapter is really bad, firmware fault once at month at least, so may be this "Killer" still kill ethernet after years of release

fduncanh commented 2 years ago

Anyway, its good for uxplay to disconnect when the client "disappears", and not just hang, because I made it so no one else can connect until the first connection is destroyed.

(previously a second client could interrupt a connected client, which is not good)

Any thoughts about whether 10 timeouts (30 sec) is about right, or too long or too short for the default timeout limit? as a user with a network issue that recovers can change it with the -reset option?

k0ste commented 2 years ago

Anyway, its good for uxplay to disconnect when the client "disappears", and not just hang, because I made it so no one else can connect until the first connection is destroyed.

Definitely!

Any thoughts about whether 10 timeouts (30 sec) is about right, or too long or too short for the default timeout limit? as a user with a network issue that recovers can change it with the -reset option?

I think the reset in a 15 seconds (5 timeouts?) is the good default value

Just in case, I'll try to take a Thunderbolt 3 cable with me from the office for a weekend, I'll see for any problems on 40G wire link

fduncanh commented 2 years ago

OK yes 5 is good. I added an informative error message when the connection closes due to timeout thanks for your help.