search

FDH2 / UxPlay

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

(mDNS port 5353 UDP issues on Windows????) UxPlay stops responding after a while #297

Closed drephuz closed 4 months ago

drephuz commented 4 months ago

No error displayed in UxPlay window, however the UxPlay device will disappear from available devices after some time. Only way to reconnect is to relaunch the app.

fduncanh commented 4 months ago

this happens if you have a firewall and port 5353 is not open: see the README Troubleshooting section

Avahi works at first, but new clients do not see UxPlay, or clients that initially saw it stop doing so after they disconnect.

This is usually because Avahi is only using the "loopback" network interface, and is not receiving mDNS queries from new clients that were not listening when UxPlay started.

To check this, after starting uxplay, use the utility avahi-browse -a -t in a different terminal window on the server to verify that the UxPlay AirTunes and AirPlay services are correctly registered (only the AirTunes service is used in the "Legacy" AirPlay Mirror mode used by UxPlay, but the AirPlay service is used for the initial contact).

The results returned by avahi-browse should show entries for uxplay like

+   eno1 IPv6 UxPlay                                        AirPlay Remote Video local
+   eno1 IPv4 UxPlay                                        AirPlay Remote Video local
+     lo IPv4 UxPlay                                        AirPlay Remote Video local
+   eno1 IPv6 863EA27598FE@UxPlay                           AirTunes Remote Audio local
+   eno1 IPv4 863EA27598FE@UxPlay                           AirTunes Remote Audio local
+     lo IPv4 863EA27598FE@UxPlay                           AirTunes Remote Audio local

If only the loopback ("lo") entries are shown, a firewall on the UxPlay host is probably blocking full DNS-SD service, and you need to open the default UDP port 5353 for mDNS requests, as loopback-based DNS-SD service is unreliable.

drephuz commented 4 months ago

this happens if you have a firewall and port 5353 is not open: see the README Troubleshooting section

Thank you, I have disabled the firewall entirely on the system prior to setup.

Avahi works at first, but new clients do not see UxPlay, or clients that initially saw it stop doing so after they disconnect.

I can see it, and any other iOS device can see it. After connecting, and disconnecting, the device is still there.

The issue is that after a while it seems to timeout, and disappear.

This is usually because Avahi is only using the "loopback" network interface, and is not receiving mDNS queries from new clients that were not listening when UxPlay started.

To check this, after starting uxplay, use the utility avahi-browse -a -t in a different terminal window on the server to verify that the UxPlay AirTunes and AirPlay services are correctly registered (only the AirTunes service is used in the "Legacy" AirPlay Mirror mode used by UxPlay, but the AirPlay service is used for the initial contact).

Working with the Windows build, I launched the MSYS2 terminal but the avahi-browse doesn't seem like a viable command.

Apologies if I missed something, I'm relatively new to this whole building thing.

fduncanh commented 4 months ago

OK you are on windows, so not using avahi (you are using the apple bonjour dns_sd server for windows).

EDIT the restricted form means that only those clients that were listening for DNS_SD announcements when uxplay started would see it. no new clients would detect it , and the initial clients would gradually forget it.

https://apps.apple.com/us/developer/lily-ballard/id305441020

EDIT https://superuser.com/questions/278978/why-has-microsoft-never-implemented-a-loopback-interface-in-windows

It seems that there is something like a loopback interface on windows, so maybe it could keep dns_sd partially working if the mDNS query network port 5353 is blocked.??? use the above iOS/macOS tool to examine your network

also https://www.howtogeek.com/28609/how-can-i-tell-what-is-listening-on-a-tcpip-port-in-windows/

fduncanh commented 4 months ago

I'm almost sure your issue is with UDP port 5353 , the mDNS port on the host running uxplay, but might be quite wrong.

https://stevessmarthomeguide.com/multicast-dns/

since you installed the Bonjour sdk (I assume) you should have the dns-sd command-line (windows) tool mentioned in the article.

fduncanh commented 4 months ago

dns-sd -B _raop._tcp dns_sd -B _airplay._tcp

will show the service registrations on windows

maybe you can check if they disappear after a while?

drephuz commented 4 months ago

dns-sd -B _raop._tcp dns-sd -B _airplay._tcp

will show the service registrations on windows

maybe you can check if they disappear after a while?

I just started both of these instances in separate windows, then I stopped and started the UxPlay process. I will report back when/if it shows that the services are "RMV" when the UxPlay disappears from AirPlay devices.

fduncanh commented 4 months ago

I will do the same, just to verify.

This is what I see (Windows 10)


C:\Users\user>dns-sd -B _raop._tcp
Browsing for _raop._tcp
Timestamp     A/R Flags if Domain                    Service Type              Instance Name
17:54:36.485  Add     3  6 local.                    _raop._tcp.               90EE6D9E56CB@Living Room
17:54:36.486  Add     2  6 local.                    _raop._tcp.               2CB78D6B7512@Apple TV
17:55:11.636  Add     2  6 local.                    _raop._tcp.               80FF078A0883@UxPlay@PCHOST

C:\Users\user>dns-sd -B _airplay._tcp
Browsing for _airplay._tcp
Timestamp     A/R Flags if Domain                    Service Type              Instance Name
17:54:32.026  Add     3  6 local.                    _airplay._tcp.            Living Room
17:54:32.027  Add     2  6 local.                    _airplay._tcp.            Apple TV
17:55:11.636  Add     2  6 local.                    _airplay._tcp.            UxPlay@PCHOST

still working after 45 mins (uxplay connnects, including to clients that rebooted after it started in the meantime, which would not happen if mDNS on port UDP 5353 was not working)

The services provided by UxPlay on Windows (PCHOST) are also visible with the Discovery DSN-SD Browser running on an iPad.

GenghisKhanDrip commented 4 months ago

I'm experiencing a similar problem but with iTunes on Windows, after a couple of minutes the DNS-SD name for homesharing will stop resolving on avahi browse on another linux device, could it be an issue with bonjour versions? Not sure if this helps with anything relating to UxPlay but thought it would be useful to provide Running Windows 10 x64 and with the 2nd latest version of iTunes from internet exe (iTunes version before the recent iPad release, non-Microsoft Store)

drephuz commented 4 months ago

I will do the same, just to verify.

This is what I see (Windows 10)


C:\Users\user>dns-sd -B _raop._tcp
Browsing for _raop._tcp
Timestamp     A/R Flags if Domain                    Service Type              Instance Name
17:54:36.485  Add     3  6 local.                    _raop._tcp.               90EE6D9E56CB@Living Room
17:54:36.486  Add     2  6 local.                    _raop._tcp.               2CB78D6B7512@Apple TV
17:55:11.636  Add     2  6 local.                    _raop._tcp.               80FF078A0883@UxPlay@PCHOST

C:\Users\user>dns-sd -B _airplay._tcp
Browsing for _airplay._tcp
Timestamp     A/R Flags if Domain                    Service Type              Instance Name
17:54:32.026  Add     3  6 local.                    _airplay._tcp.            Living Room
17:54:32.027  Add     2  6 local.                    _airplay._tcp.            Apple TV
17:55:11.636  Add     2  6 local.                    _airplay._tcp.            UxPlay@PCHOST

still working after 45 mins (uxplay connnects, including to clients that rebooted after it started in the meantime, which would not happen if mDNS on port UDP 5353 was not working)

The services provided by UxPlay on Windows (PCHOST) are also visible with the Discovery DSN-SD Browser running on an iPad.

I ran mine for 12 hours straight and UxPlay did not drop. I will be starting it up right now to see if idling without monitoring causes it to disappear.

During the monitoring session, I was able to see other devices come on and off of the network, but UxPlay never dropped once (raop).

fduncanh commented 4 months ago

So is the issue still there?

drephuz commented 4 months ago

At this time, I can’t replicate it and I’m going to chalk it up to windows just being windows. I will report back and open the issue again if it crops up. Sent from my iPhone

On May 19, 2024, at 1:38 PM, fduncanh @.***> wrote:



So is the issue still there?

— Reply to this email directly, view it on GitHubhttps://github.com/FDH2/UxPlay/issues/297#issuecomment-2119353135, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AOEF4OSOWBMB3YQTEUXUQATZDEEUTAVCNFSM6AAAAABHRCMDCKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJZGM2TGMJTGU. You are receiving this because you authored the thread.Message ID: @.***>

fduncanh commented 4 months ago

you can also build and run UxPlay natively on windows (in the MSYS2 linux-like environment)

https://github.com/FDH2/UxPlay#building-uxplay-on-microsoft-windows-using-msys2-with-the-mingw-64-compiler

drephuz commented 4 months ago

oh yeah, that’s exactly what I did.

Sent from my iPhone

On May 19, 2024, at 2:05 PM, fduncanh @.***> wrote:



you can also build and run UxPlay natively on windows (in the MSYS2 linux-like environment)

https://github.com/FDH2/UxPlay#building-uxplay-on-microsoft-windows-using-msys2-with-the-mingw-64-compiler

— Reply to this email directly, view it on GitHubhttps://github.com/FDH2/UxPlay/issues/297#issuecomment-2119359687, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AOEF4OREPWCZEPJMPAUFKQLZDEH2BAVCNFSM6AAAAABHRCMDCKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJZGM2TSNRYG4. You are receiving this because you authored the thread.Message ID: @.***>