morgan/UxPlay
1
0
Fork 0
mirror of https://github.com/morgan9e/UxPlay synced 2026-04-14 00:04:13 +09:00
Code Issues Packages Projects Releases Wiki Activity

README update (router issues with mDNS)

Browse Source
This commit is contained in:
F. Duncanh
2023-12-05 17:57:35 -05:00
parent 26c5779578
commit b790a6fd47
3 changed files with 67 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
README.html
View File

@@ -1189,9 +1189,27 @@ href="https://github.com/lathiat/avahi/blob/master/avahi-compat-libdns_sd/dns_sd
A few additional error codes are defined in a later version from <a
href="https://opensource.apple.com/source/mDNSResponder/mDNSResponder-544/mDNSShared/dns_sd.h.auto.html">Apple</a>.</p>
<p>If UxPlay stalls <em>without an error message</em> and <em>without
the server name showing on the client</em>, this is either
pre-UxPlay-1.60 behavior when no DNS-SD server was found, or a network
problem.</p>
the server name showing on the client</em>, <strong>this is a network
problem</strong> (if your UxPlay version is older than 1.60, it is also
the behavior when no DNS-SD server is found.)</p>
<p>A useful tool for examining such network problems from the client end
is the (free) Discovery DNS-SD browser <a
href="https://apps.apple.com/us/developer/lily-ballard/id305441020">available
in the Apple App Store</a> for both iOS (works on iPadOS too) and
macOS.</p>
<ul>
<li>Some users using dual-band (2.4GHz/5GHz) routers have reported that
clients using the 5GHz band (sometimes) “fail to see UxPlay” (i.e., do
not get a response to their mDNS queries), but the 2.4GHz band works.
Other projects using Bonjour/mDNS have had similar reports; the issue
seems to be router-specific, perhaps related to “auto” rather than fixed
channel selection (5GHz has many more channels to switch between), or
channel width selections; one speculation is that since mDNS uses UDP
protocol (where “lost” messages are not resent), a mDNS query might get
lost if channel switching occurs during the query.</li>
</ul>
<p>If your router has this problem, a reported “fix” is to (at least on
5GHz) use fixed channel and/or fixed (not dynamic) channel width.</p>
<ul>
<li><strong>Avahi works at first, but new clients do not see UxPlay, or
clients that initially saw it stop doing so after they
@@ -1259,8 +1277,10 @@ doesn’t work on your system</strong> (by default, GStreamer uses the
occurred when a user with a firewall only opened two udp network ports:
<strong>three</strong> are required (the third one receives the audio
data).</p>
<p><strong>Raspberry Pi</strong> devices work best with hardware GPU
h264 video decoding if the Video4Linux2 plugin in GStreamer v1.20.x or
<p><strong>Raspberry Pi</strong> devices (<em>Pi 4B+ and earlier: this
does not apply to the Pi 5, which does not provide hardware h264
decoding, and does not need it</em>) work best with hardware GPU h264
video decoding if the Video4Linux2 plugin in GStreamer v1.20.x or
earlier has been patched (see the UxPlay <a
href="https://github.com/FDH2/UxPlay/wiki/Gstreamer-Video4Linux2-plugin-patches">Wiki</a>
for patches). This is fixed in GStreamer-1.22, and by backport patches

18
README.md
View File

@@ -952,8 +952,19 @@ A few additional error codes are defined in a later version
from [Apple](https://opensource.apple.com/source/mDNSResponder/mDNSResponder-544/mDNSShared/dns_sd.h.auto.html).
If UxPlay stalls _without an error message_ and _without the server name showing on the client_, this is either pre-UxPlay-1.60
behavior when no DNS-SD server was found, or a network problem.
If UxPlay stalls _without an error message_ and _without the server name showing on the client_, **this is a network problem** (if your UxPlay version
is older than 1.60, it is also the behavior when no DNS-SD server is found.)
A useful tool for examining such network problems from the client end is the (free) Discovery DNS-SD
browser [available in the Apple App Store](https://apps.apple.com/us/developer/lily-ballard/id305441020) for both iOS (works on iPadOS too) and macOS.
* Some users using dual-band (2.4GHz/5GHz) routers have reported that clients using the 5GHz band (sometimes) "fail to see
UxPlay" (i.e., do not get a response to their mDNS queries), but the 2.4GHz band works. Other projects using Bonjour/mDNS have had similar reports;
the issue seems to be router-specific, perhaps related to "auto" rather than fixed channel selection (5GHz has many more
channels to switch between), or channel width selections; one speculation is that since mDNS uses UDP protocol (where
"lost" messages are not resent), a mDNS query might get lost if channel switching occurs during the query.
If your router has this problem, a reported "fix" is to (at least on 5GHz) use fixed channel and/or fixed (not dynamic) channel width.
* **Avahi works at first, but new clients do not see UxPlay, or clients that initially saw it stop doing so after they disconnect**.
@@ -1013,7 +1024,8 @@ to guess what are the "best" plugins to use on your system).
A different reason for no audio occurred when a user with a firewall only opened two udp network
ports: **three** are required (the third one receives the audio data).
**Raspberry Pi** devices work best with hardware GPU h264 video decoding if the Video4Linux2 plugin in GStreamer v1.20.x or earlier has
**Raspberry Pi** devices (_Pi 4B+ and earlier: this does not apply to the Pi 5, which does not provide hardware h264 decoding, and does not
need it_) work best with hardware GPU h264 video decoding if the Video4Linux2 plugin in GStreamer v1.20.x or earlier has
been patched (see the UxPlay [Wiki](https://github.com/FDH2/UxPlay/wiki/Gstreamer-Video4Linux2-plugin-patches) for patches).
This is fixed in GStreamer-1.22, and by backport patches from this in distributions such as Raspberry Pi OS (Bullseye): **use option `-bt709`
with the GStreamer-1.18.4 from Raspberry Pi OS**.

32
README.txt
View File

@@ -1212,8 +1212,28 @@ A few additional error codes are defined in a later version from
[Apple](https://opensource.apple.com/source/mDNSResponder/mDNSResponder-544/mDNSShared/dns_sd.h.auto.html).
If UxPlay stalls *without an error message* and *without the server name
showing on the client*, this is either pre-UxPlay-1.60 behavior when no
DNS-SD server was found, or a network problem.
showing on the client*, **this is a network problem** (if your UxPlay
version is older than 1.60, it is also the behavior when no DNS-SD
server is found.)
A useful tool for examining such network problems from the client end is
the (free) Discovery DNS-SD browser [available in the Apple App
Store](https://apps.apple.com/us/developer/lily-ballard/id305441020) for
both iOS (works on iPadOS too) and macOS.
- Some users using dual-band (2.4GHz/5GHz) routers have reported that
clients using the 5GHz band (sometimes) "fail to see UxPlay" (i.e.,
do not get a response to their mDNS queries), but the 2.4GHz band
works. Other projects using Bonjour/mDNS have had similar reports;
the issue seems to be router-specific, perhaps related to "auto"
rather than fixed channel selection (5GHz has many more channels to
switch between), or channel width selections; one speculation is
that since mDNS uses UDP protocol (where "lost" messages are not
resent), a mDNS query might get lost if channel switching occurs
during the query.
If your router has this problem, a reported "fix" is to (at least on
5GHz) use fixed channel and/or fixed (not dynamic) channel width.
- **Avahi works at first, but new clients do not see UxPlay, or
clients that initially saw it stop doing so after they disconnect**.
@@ -1282,9 +1302,11 @@ on your system). A different reason for no audio occurred when a user
with a firewall only opened two udp network ports: **three** are
required (the third one receives the audio data).
**Raspberry Pi** devices work best with hardware GPU h264 video decoding
if the Video4Linux2 plugin in GStreamer v1.20.x or earlier has been
patched (see the UxPlay
**Raspberry Pi** devices (*Pi 4B+ and earlier: this does not apply to
the Pi 5, which does not provide hardware h264 decoding, and does not
need it*) work best with hardware GPU h264 video decoding if the
Video4Linux2 plugin in GStreamer v1.20.x or earlier has been patched
(see the UxPlay
[Wiki](https://github.com/FDH2/UxPlay/wiki/Gstreamer-Video4Linux2-plugin-patches)
for patches). This is fixed in GStreamer-1.22, and by backport patches
from this in distributions such as Raspberry Pi OS (Bullseye): **use