From b790a6fd47c3969d60649074a52516d77e11d251 Mon Sep 17 00:00:00 2001
From: "F. Duncanh" <fduncanh@gmail.com>
Date: Tue, 5 Dec 2023 17:57:35 -0500
Subject: [PATCH] README update (router issues with mDNS)

---
 README.html | 30 +++++++++++++++++++++++++-----
 README.md   | 18 +++++++++++++++---
 README.txt  | 32 +++++++++++++++++++++++++++-----
 3 files changed, 67 insertions(+), 13 deletions(-)

diff --git a/README.html b/README.html
index b4d0f93..bfe24c3 100644
--- a/README.html
+++ b/README.html
@@ -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
diff --git a/README.md b/README.md
index d20d96b..7827ae7 100644
--- a/README.md
+++ b/README.md
@@ -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**.
diff --git a/README.txt b/README.txt
index cc7153c..1035f1e 100644
--- a/README.txt
+++ b/README.txt
@@ -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