From 3d71c131366c12daa1b503708307fb6be32d145b Mon Sep 17 00:00:00 2001
From: "F. Duncanh" <fduncanh@gmail.com>
Date: Thu, 19 Mar 2026 03:49:29 -0400
Subject: [PATCH] README update for v1.73.5

---
 README.html | 188 ++++++++++++++++++++++++++++++++--------------------
 README.md   | 105 ++++++++++++++++++-----------
 README.txt  | 171 +++++++++++++++++++++++++++++------------------
 3 files changed, 291 insertions(+), 173 deletions(-)

diff --git a/README.html b/README.html
index b6efcd5..9874fce 100644
--- a/README.html
+++ b/README.html
@@ -8,7 +8,8 @@ developed at the GitHub site <a href="https://github.com/FDH2/UxPlay"
 class="uri">https://github.com/FDH2/UxPlay</a> (where ALL user issues
 should be posted, and latest versions can be found).</strong></h3>
 <ul>
-<li><p><strong>NEW in v1.73</strong> (January 2026):</p></li>
+<li><p><strong>NEW in v1.73, up to v1.73.5</strong> (March
+2026):</p></li>
 <li><p>Some YouTube app HLS videos now offer alternative language tracks
 (generated by AI dubbing). Language choices will be made in order of
 preferences set with option -lang (or by environment variable $LANGUAGE,
@@ -20,18 +21,18 @@ suppresses playing of dubbed audio if $LANGUAGE is set.</p></li>
 and Video to mp4 file (new option -mp4 [fn]).</p></li>
 <li><p>Support for <strong>service discovery using a Bluetooth LE
 “beacon”</strong> for both Linux/*BSD and Windows (as an alternative to
-Bonjour/Rendezvous DNS-SD service discovery). <strong>This can be used
-on networks that do not allow the user to run a DNS_SD service.</strong>
-The user must run a Bluetooth LE “beacon”, (a USB 4.0 or later “dongle”
-can be used). The beacon is managed by a Python3 script
-<code>uxplay-beacon.py</code>: four implementations of Bleutooth LE
-advertising are available as loadable modules: BlueZ for Linux only,
-winrt for Windows only, BleuIO for the BlueIO usb-serial dongle (which
-has its own BlueTooth-LE stack, independent of that of the host system)
-that runs on all systems including macOS and *BSD), and a low-level HCI
-module (Linux and BSD only) that access the Host Contoller Interface
-(but users need enhanced privileges to use this). The beacon runs
-independently of UxPlay: while UxPlay is running, it regularly
+Bonjour/Rendezvous DNS-SD service discovery) was introduced in v1.73 and
+improved in 1.73.5. This can be used on networks that do not allow the
+user to run a DNS_SD service.** The user must run a Bluetooth LE
+“beacon”, (Bluetooth 4.0 or later is needed, a cheap USD “dongle” will
+do.). The beacon is managed by a Python &gt;= 3.6 script
+<code>uxplay-beacon.py</code>. Loadable Python modules provide
+appropriate Bluetooth LE support for Linux, Windows, and FreeBSD;
+<em>macOS is only supported by the BleuIO USB dongle which uniquely has
+its own Bluetooth LE stack based on a Renesas SoC, and is seen by the
+host as a serial modem (this can be used on all the operating systems
+supported by Uxplay, including other BSD variants).</em> The beacon runs
+independently of UxPlay. While UxPlay is running, the beacon regularly
 broadcasts a Bluetooth LE (“Low Energy”) 46 byte legacy-type
 advertisement informing nearby iOS/macOS devices of the local IPv4
 network address of the UxPlay server, and which TCP port to contact
@@ -1548,33 +1549,58 @@ this to see even more of the GStreamer inner workings.</p>
 <h1 id="bluetooth-le-beacon-setup">Bluetooth LE beacon setup</h1>
 <p>The python&gt;=3.6 script for running a Bluetooth LE Service
 Discovery beacon is uxplay-beacon.py. It provides four possible
-Bluetooth LE implementations (loaded as modules): one for Linux systems
-with D-Bus, one for Windows, and one for the <a
+Bluetooth LE implementations (loaded as modules):</p>
+<ul>
+<li><p><strong>BlueZ</strong> for Linux systems with D-Bus;</p></li>
+<li><p><strong>winrt</strong> for Windows;</p></li>
+<li><p><strong>BleuIO</strong> for the <a
 href="https://www.bleuio.com">BleuIO (or BleuIO Pro) USB dongle</a> with
 its own on-board Bluetooth-LE Stack that does not use the host operating
-system Bluetooth (the Host sees the device as a USB serial modem). This
-is needed for macOS where the operating system does not allow users to
-send Bluetooth-LE advertisements of the type we require. If a BleuIO
-dongle is available, the bleuio version of the python script can be used
-on many operating systems including macOS, Windows and Linux, and
-perhaps *BSD (not tested): it requires python library
-<code>python3-pyserial</code> to be installed.</p>
-<p>A fourth implementation (module HCI) for Linux or FreeBSD (maybe
-other BSD’s too?) requires elevated permissions to access the Host
-Controller Interface. These are granted by adding users to a new group
-“hciusers” that are give permission to call
-“<code>sudo -n hcitool/hciconfig/hccontrol</code>” without entering a
-password: this can be configured by the system admistrator using visudo,
-but has security implications.</p>
-<p>On Linux, Bluetooth support (using the offical Linux Bluetooth stack
-BlueZ) must be installed (on Debian-based systems:
+system Bluetooth (the host sees the device as a USB serial modem). This
+is needed for macOS where the native operating system Bluetooth stack
+does not allow users to send Bluetooth-LE advertising data of the
+“manufacturer-specific” type <code>AdvData=0xFF</code>. If a BleuIO
+dongle (currently costs about USD25) is available, the BleuIO version of
+the python script can be used on many operating systems including macOS,
+Windows, Linux, FreeBSD, and probably other BSD variants (not tested):
+it requires python library <code>python3-pyserial</code> to be
+installed. On Linux, users must be members of group <code>dialout</code>
+or sometimes <code>uucp</code> (<code>dialer</code> on
+FreeBSD).</p></li>
+<li><p><strong>HCI</strong> for Linux without D-Bus (uses utiities
+<code>hcitool</code> and <code>hciconfig</code>) or FreeBSD (uses
+<code>hccontrol</code>) and requires elevated privileges to access the
+Host Controller Interface. These privileges can be granted by adding
+users to a new group “hciusers” that are given permission to call
+“<code>sudo -n hci*</code>” (<code>hci*</code> = hcitool, hciconfig or
+hccontrol) without entering a password: this can be configured by the
+system administrator using <code>visudo</code> (<em>security
+implications should be considered</em>). Use visudo to create a file
+<code>hciusers</code> in <code>/etc/sudoers.d/</code> (Linux) or
+<code>/usr/local/etc/sudoers.d</code> (FreeBSD), containing the line
+“<code>%hciusers ALL=(ALL) NOPASSWD: &lt;hcitools&gt;</code>” (where
+<code>&lt;hcitools&gt;</code> is replaced by
+“<code>/usr/bin/hcitool, /usr/bin/hciconfig</code>” (Linux) or
+“<code>/usr/sbin/hccontrol</code>” (FreeBSD). In addition, FreeBSD’s
+<code>hccontrol</code> needs a patch to allow generic LE Advertising
+Data to be input. We have submitted it to FreeBSD as a Pull Request, and
+you can find it on the [UxPlay Wiki]
+(https://github.com/FDH2/UxPlay/wiki/hccontrol-patch-for-FreeBSD-15.0)</p></li>
+</ul>
+<p>On Linux, Bluetooth support (using the official Linux Bluetooth stack
+BlueZ, and D-Bus) must be installed (on Debian-based systems:
 <code>sudo apt install bluez bluez-tools</code>; recent Ubuntu releases
-provide bluez as a snap package). In addition to standard Python3
-libraries, you may need to install the gi, dbus, and psutil Python
-libraries used by uxplay-beacon.py. On Debian-based systems:</p>
+provide bluez as a snap package). BlueZ tools ‘hcitool’ and ‘hciconfig’
+(needed if you use the HCI module on Linux) are declared “deprecated” by
+the BlueZ developers: some Linux distributions have removed them from
+the default BleuZ packages, into “extra” packages with names like
+“bluez-deprecated”.</p>
+<p>In addition to standard Python3 libraries, you may need to install
+the gi, dbus, and psutil Python libraries used by uxplay-beacon.py. On
+Debian-based systems:</p>
 <pre><code>sudo apt install python3-gi python3-dbus python3-psutil</code></pre>
-<p>If a python3-gi package is not found, install the python3-gobject
-package which provides it.</p>
+<p>If a python3-gi package is available in your Linux distribution,
+install the python3-gobject package which provides it.</p>
 <p>For Windows support in the MSYS2 UCRT64 environment, use pacman -S to
 install <code>mingw-w64-ucrt-x86_64-python</code>,
 <code>*-python-gobject</code>, <code>*-python-psutil</code>, and
@@ -1587,11 +1613,11 @@ pip install winrt-Windows.Storage.Streams</code></pre>
 <p>For python &gt;= 3.11, the pip commands on “externally-managed”
 python installations (such as the one provided in MSYS2) should be</p>
 <pre><code>pip install ....  --break-system-packages</code></pre>
-<p>The option <code>--break-system-packages</code> was required to make
-users hesitate before adding packages not provided by the “external
-management”: <em>this is unnecessarily scary, as in the case of the
-winrt packages, no breakage will occur</em>.</p>
-<p>If uxplay will be run with option “<code>uxplay -ble</code>” (so it
+<p>The option <code>--break-system-packages</code> was added as a
+requirement to make users hesitate before adding packages not provided
+by the “external management”: <em>this is unnecessarily scary, as in the
+case of the winrt packages, no breakage can occur</em>.</p>
+<p>UxPlay must be run with option “<code>uxplay -ble</code>” (so it
 writes data for the Bluetooth beacon in the default BLE data file
 <code>~/.uxplay.ble</code>), just run <code>uxplay-beacon.py</code> in a
 separate terminal. The python script will start Bluetooth LE
@@ -1610,6 +1636,11 @@ configuration file options. Get help with <code>man uxplay-beacon</code>
 or <code>uxplay-beacon.py --help</code>.</p>
 <p>Options are</p>
 <ul>
+<li><p><code>&lt;module&gt;</code> where “module” is BleuIO or HCI (no
+intital <code>--</code>) . Without this option, the default module used
+will be <strong>BlueZ</strong> (Linux), <strong>winrt</strong>
+(Windows), <strong>BleuIO</strong> (all other operating
+systems).</p></li>
 <li><p><code>--file &lt;config file&gt;</code> read beacon options from
 <code>&lt;config file&gt;</code> instead of
 <code>~/.uxplay.beacon</code>.</p></li>
@@ -1623,33 +1654,48 @@ default choice of BLE data file (<code>~/.uxplay.ble</code>) that is
 monitored by the beacon script. This also requires that uxplay is run
 with option “<code>uxplay -ble &lt;BLE data file&gt;</code>”.</p></li>
 </ul>
-<p>The BlueZ/Dbus version has three more options not offered by the
-Windows version (the Windows operating system chooses their values):</p>
+<p>These are the only options accepted by the <strong>winrt</strong>
+module on Windows. The other modules accept</p>
 <ul>
-<li><p><code>--advmin x</code>, <code>--advmax y</code>. These controls
-the interval between BLE advertisement broadcasts. This interval is in
-the range [x, y], given in units of msecs. Allowed ranges are 100 &lt;=
-x &lt;= y &lt;= 10240. If advmin=advmax, the interval is fixed: if
-advmin &lt; advmax it is chosen flexibly in this range to avoid
-interfering with other tasks the Bluetooth device is carrying out. The
-default values are advmin = advmax = 100. The advertisement is broadcast
-on all three Bluetooth LE advertising channels: 37,38,39.</p></li>
-<li><p><code>--index x</code> (default x = 0, x &gt;= 0). This can be
-used by the DBus to distinguish between multiple simultaneous instances
-of uxplay-beacon.py that are running to support multiple instances of
+<li><code>--advmin x</code>, <code>--advmax y</code>. These controls the
+interval between BLE advertisement broadcasts. This interval is in the
+range [x, y], given in units of msecs. Allowed ranges are 100 &lt;= x
+&lt;= y &lt;= 10240. If advmin=advmax, the interval is fixed: if advmin
+&lt; advmax it is chosen flexibly in this range to avoid interfering
+with other tasks the Bluetooth device is carrying out. The default
+values are advmin = advmax = 100. The advertisement is broadcast on all
+three Bluetooth LE advertising channels: 37,38,39.</li>
+</ul>
+<p>On a Windows system, the values of these paramaters are set by the
+operating system, and cannot be set by users.</p>
+<p>The <strong>BlueZ</strong> module (Linux) also accepts</p>
+<ul>
+<li><code>--index x</code> (default x = 0, x &gt;= 0). This can be used
+by the DBus to distinguish between multiple simultaneous instances of
+uxplay-beacon.py that are running to support multiple instances of
 UxPlay. Each instance must have its own BLE Data file (just as each
 instance of UxPlay must also have its own MAC address and ports).
 <em>Note: running multiple beacons simultaneously on the same host has
 not been tested, and this option might not be useful or
-needed.</em></p></li>
+needed.</em></li>
 </ul>
-<p>While the native macOS and *BSD Bluetooth stacks do not allow
-unpriviledged users to send “manufacturer-specific” advertisements like
-the uxplay service discovery announcement, this can be achieved using
-the BleuIO USB device: the BleuIO module for uxplay-beacon.py is
-installed with UxPlay in all operating systems, including macos and
-*BSD, while the BlueZ and winrt modules are only installed on Linux and
-Windows, respectively.</p>
+<p>The <strong>BleuIO</strong> and <strong>HCI</strong> modules
+accept</p>
+<ul>
+<li><code>--device x</code> which allows overiding automatically-made
+choices of serial ports (<strong>BleuIO</strong>) or hci device nodes
+(<strong>HCI</strong>). This is probably only useful if the host system
+has multiple devices that could be used.</li>
+</ul>
+<p>The native macOS Bluetooth stack has no documented way for users to
+send “manufacturer-specific” Bluetooth LE advertisements (such that sent
+for AirPlay Service Discovery), and the only support of uxplay-beacon.py
+on macOS uses a BleuIO USB serial device. However macOS provides a
+low-level utility BlueTool (found at <code>/usr/sbin/bluetool</code>)
+that can send HCI commands, so possibly could be used to adapt the
+python3 <strong>HCI</strong> module to support macOS as well
+(<em>working implementations welcome!</em>). <strong>The recommended and
+working method on macOS is to use a BleuIO dongle.</strong></p>
 <p>If you wish to test Bluetooth LE Service Discovery on Linux/*BSD, you
 can disable DNS_SD Service discovery by the avahi-daemon with</p>
 <pre><code>$ sudo systemctl mask avahi-daemon.socket
@@ -1661,16 +1707,10 @@ Management</strong>: press “Windows + R” to open the Run dialog, run
 <code>services.msc</code>, and click on <strong>Bonjour Service</strong>
 in the alphabetic list. This will show links for it to be stopped and
 restarted.</p>
-<p>For more information, see the <a
+<p>For more information on Bluetooth LE support, including HCI commands,
+see the <a
 href="https://github.com/FDH2/UxPlay/wiki/Bluetooth_LE_beacon">wiki
-page</a>. This page also explains how to setup a BLE beacon for UxPlay
-on Linux by direct accesss to the Bluetooth stack using
-<code>hcitool</code> to send low-level HCI commands, with root
-privileges. This can also be done on FreeBSD using
-<code>hccontrol</code>, and on macOS using <code>bluetool</code>.
-<strong>The recommended way to set up Bluetooth LE Service Discovery on
-macOS or *BSD is to acquire a BleuIO USB device, which is supported by
-uxplay-beacon.py without root privileges</strong>.</p>
+page</a>.</p>
 <ul>
 <li><strong>Note that Bluetooth LE AirPlay Service Discovery only
 supports broadcast of IPv4 addresses</strong>.</li>
@@ -1709,7 +1749,11 @@ You might need to edit the avahi-daemon.conf file (it is typically in
 systems may instead use the mdnsd daemon as an alternative to provide
 DNS-SD service. (FreeBSD offers both alternatives, but only Avahi was
 tested; see <a
-href="https://gist.github.com/reidransom/6033227">here</a>.)</p>
+href="https://gist.github.com/reidransom/6033227">here</a>, or <a
+href="https://docs.freebsd.org/en/books/handbook/network-servers/#_configuring_and_starting_avahi">section
+32.8.1 of the FreeBSD Handbook</a>) Note that avahi service is not
+needed if you instead use a Bluetooth LE beacon (see <a
+href="#bluetooth-le-beacon-setup">above</a>) for Service-Discovery.</p>
 <ul>
 <li><strong>uxplay starts, but either stalls or stops after “Initialized
 server socket(s)” appears (<em>without the server name showing on the
diff --git a/README.md b/README.md
index ea991b0..9447c15 100644
--- a/README.md
+++ b/README.md
@@ -2,7 +2,7 @@
 
 ### **Now developed at the GitHub site <https://github.com/FDH2/UxPlay> (where ALL user issues should be posted, and latest versions can be found).**
 
--  **NEW in v1.73** (January 2026):
+-  **NEW in v1.73, up to  v1.73.5** (March 2026):
 
 -   Some YouTube app HLS videos now offer alternative language tracks (generated by AI dubbing).  Language choices will be made in order of
     preferences set with option -lang (or by environment variable $LANGUAGE, which "-lang"  overrides). Format is `-lang fr:es:en`, where French ("fr") is
@@ -12,13 +12,12 @@
 -   Support for recording Mirror-mode/Audio-mode (but not HLS) Audio and Video to mp4 file (new option -mp4 [fn]). 
 
 -   Support for **service discovery using a Bluetooth LE "beacon"** for both Linux/\*BSD and Windows (as an alternative to Bonjour/Rendezvous DNS-SD
-    service discovery). **This can be used on networks that do not allow the user to run a  DNS_SD service.**   The user must run a Bluetooth LE "beacon", (a USB 4.0 or
-    later "dongle" can be used). The beacon is managed by a Python3 script `uxplay-beacon.py`: four implementations of Bleutooth LE advertising are available
-    as loadable modules: BlueZ for Linux only,  winrt for Windows only,  BleuIO
-    for the BlueIO usb-serial dongle (which has its own BlueTooth-LE stack, independent of that of the
-    host system) that runs on all systems including macOS and *BSD), and a low-level HCI module (Linux and BSD only) that
-    access the Host Contoller Interface (but users need enhanced privileges to use this). The beacon
-    runs independently of UxPlay: while UxPlay is running, it regularly broadcasts a Bluetooth LE ("Low Energy") 46 byte
+    service discovery) was introduced in v1.73 and improved in 1.73.5.  This can be used on networks that do not allow the user to run a  DNS_SD service.**
+    The user must run a Bluetooth LE "beacon", (Bluetooth  4.0 or later is needed, a cheap USD "dongle" will do.). The
+    beacon is managed by a Python >= 3.6 script `uxplay-beacon.py`. Loadable Python modules provide appropriate Bluetooth LE  support for Linux, Windows,
+    and FreeBSD;  _macOS is only supported by the BleuIO USB dongle which uniquely has its own Bluetooth LE stack based on a Renesas SoC, and is seen by the
+    host as a serial modem (this can be used on all the operating systems supported by Uxplay, including other BSD variants)._    The beacon runs independently
+    of UxPlay.  While UxPlay is running, the beacon  regularly broadcasts a Bluetooth LE ("Low Energy") 46 byte
     legacy-type advertisement  informing nearby iOS/macOS devices of
     the local IPv4 network address of the UxPlay server, and which TCP port to contact UxPlay on.  Instructions
     are [given below](#bluetooth-le-beacon-setup).
@@ -1560,29 +1559,44 @@ GStreamer inner workings.
 # Bluetooth LE beacon setup
 
 The python>=3.6 script for running a Bluetooth LE Service Discovery beacon is uxplay-beacon.py.
-It provides four possible Bluetooth LE implementations (loaded as modules):  one for Linux systems with D-Bus,
-one for Windows,  and one for the [BleuIO (or BleuIO Pro) USB
-dongle](https://www.bleuio.com)  with its own on-board Bluetooth-LE Stack that
-does not use the host operating system Bluetooth (the Host sees the device as a USB serial modem).   This is needed for macOS where the
-operating system does not allow users to send  Bluetooth-LE advertisements of the type we require.  If a BleuIO  dongle is
-available, the bleuio version of the python script
-can be used on many operating systems including macOS, Windows and Linux, and perhaps *BSD (not tested):
-it requires python library `python3-pyserial` to be installed.
+It provides four possible Bluetooth LE implementations (loaded as modules):
 
-A fourth implementation (module HCI) for Linux or FreeBSD (maybe other BSD's too?)  requires elevated permissions to access the Host
-Controller  Interface.   These are granted by adding users to a new group "hciusers" that are give permission to
-call "`sudo -n hcitool/hciconfig/hccontrol`" without entering a password:  this can be configured by the system admistrator
-using visudo, but has security implications.
+* **BlueZ** for Linux systems with D-Bus;
+
+* **winrt**  for Windows;
+
+* **BleuIO** for the [BleuIO (or BleuIO Pro) USB dongle](https://www.bleuio.com)  with its own on-board Bluetooth-LE Stack that
+    does not use the host operating system Bluetooth (the host sees the device as a USB serial modem).   This is needed for macOS where the
+    native operating system Bluetooth stack does not allow users to send  Bluetooth-LE advertising data
+    of the "manufacturer-specific" type `AdvData=0xFF`.  If a BleuIO dongle (currently costs about USD25) is
+    available, the BleuIO version of the python script can be used on many operating systems including macOS, Windows, Linux, FreeBSD,
+    and probably other BSD variants (not tested): it requires python library `python3-pyserial` to be installed.  On Linux, users must be members of
+    group `dialout` or sometimes ``uucp`` (```dialer``` on FreeBSD).
+
+* **HCI**  for Linux without D-Bus (uses utiities `hcitool` and ``hciconfig``)  or FreeBSD (uses
+    `hccontrol`) and  requires elevated privileges to access the Host Controller  Interface.   These privileges can be  granted by adding users
+    to a new group "hciusers" that are given permission to call "`sudo -n hci*`" (``hci*`` = hcitool, hciconfig or hccontrol) without entering a password:
+    this can be configured by the system administrator using `visudo` (_security implications should be considered_).   Use visudo to create a file `hciusers`
+    in `/etc/sudoers.d/` (Linux)
+    or `/usr/local/etc/sudoers.d` (FreeBSD), containing the
+    line "`%hciusers ALL=(ALL) NOPASSWD: <hcitools>`" (where  ``<hcitools>`` is replaced
+    by "`/usr/bin/hcitool, /usr/bin/hciconfig`" (Linux) or "``/usr/sbin/hccontrol``" (FreeBSD).  In
+    addition, FreeBSD's `hccontrol` needs a patch to allow generic LE Advertising Data to be input.   We have submitted it to FreeBSD as a Pull Request,
+    and you can find it on the [UxPlay Wiki] (https://github.com/FDH2/UxPlay/wiki/hccontrol-patch-for-FreeBSD-15.0)
+
+
+On Linux, Bluetooth support (using the official Linux Bluetooth stack BlueZ, and D-Bus) must be installed (on Debian-based systems: `sudo apt install bluez bluez-tools`;
+recent Ubuntu releases provide bluez as a snap package).   BlueZ tools 'hcitool' and 'hciconfig' (needed if you use the HCI module
+on Linux) are declared  "deprecated" by the BlueZ developers: some Linux distributions
+have removed them from the  default BleuZ packages, into  "extra" packages with names like "bluez-deprecated".
 
-On Linux, Bluetooth support (using the offical Linux Bluetooth stack BlueZ) must be installed (on Debian-based systems: `sudo apt install bluez bluez-tools`;
-recent Ubuntu releases provide bluez as a snap package).
 In addition to standard Python3 libraries, you may need to install the gi, dbus, and psutil Python libraries used by
 uxplay-beacon.py.  On Debian-based systems:
 
 ```
 sudo apt install python3-gi python3-dbus python3-psutil
 ```
-If a python3-gi package is not found, install the python3-gobject package which provides it.
+If a python3-gi package is available in your Linux distribution, install the python3-gobject package which provides it.
 
 For Windows support in the  MSYS2 UCRT64 environment, use pacman -S to
 install `mingw-w64-ucrt-x86_64-python`, ``*-python-gobject``,
@@ -1601,11 +1615,11 @@ For python >= 3.11, the pip commands on "externally-managed" python installation
 pip install ....  --break-system-packages
 ```
 
-The option `--break-system-packages` was required to make users hesitate before 
+The option `--break-system-packages` was added as a requirement to make users hesitate before 
 adding packages not provided by  the "external management":
-_this is unnecessarily scary, as in the case of the winrt packages, no breakage will occur_.
+_this is unnecessarily scary, as in the case of the winrt packages, no breakage can occur_.
 
-If uxplay will be  run with option "`uxplay -ble`" (so it writes data for the Bluetooth beacon in the default BLE 
+UxPlay must  be  run with option "`uxplay -ble`" (so it writes data for the Bluetooth beacon in the default BLE 
 data file `~/.uxplay.ble`), just run ``uxplay-beacon.py`` in a separate terminal.    The python script will start
 Bluetooth LE Service-Discovery advertising when it detects that UxPlay is running by checking if the BLE data file exists, and stop when it no longer detects
 a running UxPlay plus this file (it will restart advertising if UxPlay later reappears).   The script will remain active until stopped with Ctrl+C in its
@@ -1619,6 +1633,9 @@ options.   Get help with `man uxplay-beacon` or ``uxplay-beacon.py --help``.
 
 Options are
 
+* ```<module>``` where "module" is BleuIO or HCI (no intital ``--``) .   Without this option, the default module used will be **BlueZ** (Linux), **winrt** (Windows), **BleuIO** (all other operating systems).
+
+
 * `--file <config file>` read beacon options from ``<config file>`` instead of
 `~/.uxplay.beacon`.
 
@@ -1628,22 +1645,36 @@ it is not given, an address will be obtained automatically (specify the address
 * `--path <BLE data file>`.  This overrides the default choice of BLE data file (``~/.uxplay.ble``) that is monitored by the beacon script.   This also requires
 that uxplay is run with option "`uxplay -ble <BLE data file>`".
 
-The BlueZ/Dbus version has three more options not offered by the Windows version (the Windows operating system chooses their values):
+These are the only options accepted by the **winrt** module on Windows.   The other modules accept
 
 * `--advmin x`, ``--advmax y``.  These controls the interval between BLE advertisement broadcasts.  This interval is in the range
 [x, y], given in units of msecs.   Allowed ranges are 100 <= x <= y <= 10240.  If advmin=advmax, the interval is fixed: if advmin < advmax
 it is chosen flexibly in this range to avoid interfering with other tasks the Bluetooth device is carrying out.   The default values are
 advmin = advmax = 100.   The advertisement is broadcast on all three Bluetooth LE advertising channels: 37,38,39.
 
+On a Windows system, the values of these paramaters are set by the operating system, and cannot be set by users.
+
+The **BlueZ** module (Linux) also accepts
+
 * `--index x` (default x = 0, x >= 0).  This can be used by the DBus to distinguish between  multiple simultaneous instances of uxplay-beacon.py that
 are running to support multiple instances of UxPlay.  Each instance must have its own BLE Data
 file (just as each instance of UxPlay must also have its own MAC address and ports).  _Note:  running multiple beacons simultaneously
 on the same host has not been tested, and this option might not be useful or needed._
 
-While the native macOS and \*BSD Bluetooth stacks
-do not allow unpriviledged users to send "manufacturer-specific" advertisements like the uxplay service discovery
-announcement, this can be achieved using the BleuIO USB device: the BleuIO  module for uxplay-beacon.py is installed with UxPlay
-in all operating systems, including macos and *BSD, while the BlueZ and winrt modules are only installed on Linux and Windows, respectively.
+The **BleuIO** and **HCI** modules accept
+
+* `--device x` which allows overiding automatically-made choices of serial ports (**BleuIO**) or hci device nodes (**HCI**). This 
+is probably only useful if the host system has multiple devices that could be used.
+
+
+The native macOS  Bluetooth stack has no documented way for users to send "manufacturer-specific" Bluetooth LE advertisements (such
+that sent for  AirPlay Service Discovery), and  the only support of uxplay-beacon.py on macOS uses a BleuIO USB serial device.
+However macOS provides a low-level utility BlueTool (found at `/usr/sbin/bluetool`) that can send HCI commands, so
+possibly could be used to adapt the python3  **HCI** module to support macOS as well (_working implementations welcome!_).
+__The recommended and working method on macOS is to use a  BleuIO dongle.__ 
+
+
+
 
 If you wish to test Bluetooth LE Service Discovery on Linux/*BSD, you can disable DNS_SD Service discovery by the avahi-daemon with
 
@@ -1658,11 +1689,8 @@ On Windows, the Bonjour Service is controlled  using **Services Management**: pr
 run `services.msc`, and click on  **Bonjour Service** in the alphabetic list. This
 will show links for it to be stopped and restarted.
 
-For more information, see the [wiki page](https://github.com/FDH2/UxPlay/wiki/Bluetooth_LE_beacon). This page also explains how to setup a BLE
-beacon for UxPlay on Linux by direct accesss to the Bluetooth stack using `hcitool` to send low-level HCI commands, with root privileges.
-This can also be done on FreeBSD using `hccontrol`, and on macOS using ``bluetool``.  **The recommended way to set up  Bluetooth LE
-Service Discovery on macOS or \*BSD is to acquire a BleuIO USB device, which is supported by uxplay-beacon.py  without
-root privileges**.
+For more information on Bluetooth LE support, including HCI commands, see the [wiki page](https://github.com/FDH2/UxPlay/wiki/Bluetooth_LE_beacon).
+
 
 
 * **Note that  Bluetooth LE AirPlay Service Discovery only supports
@@ -1702,7 +1730,10 @@ start, stop, status. You might need to edit the avahi-daemon.conf file
 "disable-publishing" is **not** a selected option). Some systems may
 instead use the mdnsd daemon as an alternative to provide DNS-SD
 service. (FreeBSD offers both alternatives, but only Avahi was tested;
-see [here](https://gist.github.com/reidransom/6033227).)
+see [here](https://gist.github.com/reidransom/6033227),
+or [section 32.8.1 of the FreeBSD Handbook](https://docs.freebsd.org/en/books/handbook/network-servers/#_configuring_and_starting_avahi))
+Note that avahi service is not needed if you instead use a Bluetooth LE beacon (see [above](#bluetooth-le-beacon-setup)) for Service-Discovery.
+
 
 -   **uxplay starts, but either stalls or stops after "Initialized
     server socket(s)" appears (*without the server name showing on the
diff --git a/README.txt b/README.txt
index 37241ab..c8d0b63 100644
--- a/README.txt
+++ b/README.txt
@@ -2,7 +2,7 @@
 
 ### **Now developed at the GitHub site <https://github.com/FDH2/UxPlay> (where ALL user issues should be posted, and latest versions can be found).**
 
--   **NEW in v1.73** (January 2026):
+-   **NEW in v1.73, up to v1.73.5** (March 2026):
 
 -   Some YouTube app HLS videos now offer alternative language tracks
     (generated by AI dubbing). Language choices will be made in order of
@@ -17,22 +17,22 @@
 
 -   Support for **service discovery using a Bluetooth LE "beacon"** for
     both Linux/\*BSD and Windows (as an alternative to
-    Bonjour/Rendezvous DNS-SD service discovery). **This can be used on
-    networks that do not allow the user to run a DNS_SD service.** The
-    user must run a Bluetooth LE "beacon", (a USB 4.0 or later "dongle"
-    can be used). The beacon is managed by a Python3 script
-    `uxplay-beacon.py`: four implementations of Bleutooth LE advertising
-    are available as loadable modules: BlueZ for Linux only, winrt for
-    Windows only, BleuIO for the BlueIO usb-serial dongle (which has its
-    own BlueTooth-LE stack, independent of that of the host system) that
-    runs on all systems including macOS and \*BSD), and a low-level HCI
-    module (Linux and BSD only) that access the Host Contoller Interface
-    (but users need enhanced privileges to use this). The beacon runs
-    independently of UxPlay: while UxPlay is running, it regularly
-    broadcasts a Bluetooth LE ("Low Energy") 46 byte legacy-type
-    advertisement informing nearby iOS/macOS devices of the local IPv4
-    network address of the UxPlay server, and which TCP port to contact
-    UxPlay on. Instructions are [given
+    Bonjour/Rendezvous DNS-SD service discovery) was introduced in v1.73
+    and improved in 1.73.5. This can be used on networks that do not
+    allow the user to run a DNS_SD service.\*\* The user must run a
+    Bluetooth LE "beacon", (Bluetooth 4.0 or later is needed, a cheap
+    USD "dongle" will do.). The beacon is managed by a Python \>= 3.6
+    script `uxplay-beacon.py`. Loadable Python modules provide
+    appropriate Bluetooth LE support for Linux, Windows, and FreeBSD;
+    *macOS is only supported by the BleuIO USB dongle which uniquely has
+    its own Bluetooth LE stack based on a Renesas SoC, and is seen by
+    the host as a serial modem (this can be used on all the operating
+    systems supported by Uxplay, including other BSD variants).* The
+    beacon runs independently of UxPlay. While UxPlay is running, the
+    beacon regularly broadcasts a Bluetooth LE ("Low Energy") 46 byte
+    legacy-type advertisement informing nearby iOS/macOS devices of the
+    local IPv4 network address of the UxPlay server, and which TCP port
+    to contact UxPlay on. Instructions are [given
     below](#bluetooth-le-beacon-setup).
 
 -   option `-vrtp <rest-of-pipeline>` bypasses rendering by UxPlay, and
@@ -1595,35 +1595,61 @@ this to see even more of the GStreamer inner workings.
 
 The python\>=3.6 script for running a Bluetooth LE Service Discovery
 beacon is uxplay-beacon.py. It provides four possible Bluetooth LE
-implementations (loaded as modules): one for Linux systems with D-Bus,
-one for Windows, and one for the [BleuIO (or BleuIO Pro) USB
-dongle](https://www.bleuio.com) with its own on-board Bluetooth-LE Stack
-that does not use the host operating system Bluetooth (the Host sees the
-device as a USB serial modem). This is needed for macOS where the
-operating system does not allow users to send Bluetooth-LE
-advertisements of the type we require. If a BleuIO dongle is available,
-the bleuio version of the python script can be used on many operating
-systems including macOS, Windows and Linux, and perhaps \*BSD (not
-tested): it requires python library `python3-pyserial` to be installed.
+implementations (loaded as modules):
 
-A fourth implementation (module HCI) for Linux or FreeBSD (maybe other
-BSD's too?) requires elevated permissions to access the Host Controller
-Interface. These are granted by adding users to a new group "hciusers"
-that are give permission to call "`sudo -n hcitool/hciconfig/hccontrol`"
-without entering a password: this can be configured by the system
-admistrator using visudo, but has security implications.
+-   **BlueZ** for Linux systems with D-Bus;
 
-On Linux, Bluetooth support (using the offical Linux Bluetooth stack
-BlueZ) must be installed (on Debian-based systems:
+-   **winrt** for Windows;
+
+-   **BleuIO** for the [BleuIO (or BleuIO Pro) USB
+    dongle](https://www.bleuio.com) with its own on-board Bluetooth-LE
+    Stack that does not use the host operating system Bluetooth (the
+    host sees the device as a USB serial modem). This is needed for
+    macOS where the native operating system Bluetooth stack does not
+    allow users to send Bluetooth-LE advertising data of the
+    "manufacturer-specific" type `AdvData=0xFF`. If a BleuIO dongle
+    (currently costs about USD25) is available, the BleuIO version of
+    the python script can be used on many operating systems including
+    macOS, Windows, Linux, FreeBSD, and probably other BSD variants (not
+    tested): it requires python library `python3-pyserial` to be
+    installed. On Linux, users must be members of group `dialout` or
+    sometimes `uucp` (`dialer` on FreeBSD).
+
+-   **HCI** for Linux without D-Bus (uses utiities `hcitool` and
+    `hciconfig`) or FreeBSD (uses `hccontrol`) and requires elevated
+    privileges to access the Host Controller Interface. These privileges
+    can be granted by adding users to a new group "hciusers" that are
+    given permission to call "`sudo -n hci*`" (`hci*` = hcitool,
+    hciconfig or hccontrol) without entering a password: this can be
+    configured by the system administrator using `visudo` (*security
+    implications should be considered*). Use visudo to create a file
+    `hciusers` in `/etc/sudoers.d/` (Linux) or
+    `/usr/local/etc/sudoers.d` (FreeBSD), containing the line
+    "`%hciusers ALL=(ALL) NOPASSWD: <hcitools>`" (where `<hcitools>` is
+    replaced by "`/usr/bin/hcitool, /usr/bin/hciconfig`" (Linux) or
+    "`/usr/sbin/hccontrol`" (FreeBSD). In addition, FreeBSD's
+    `hccontrol` needs a patch to allow generic LE Advertising Data to be
+    input. We have submitted it to FreeBSD as a Pull Request, and you
+    can find it on the \[UxPlay Wiki\]
+    (https://github.com/FDH2/UxPlay/wiki/hccontrol-patch-for-FreeBSD-15.0)
+
+On Linux, Bluetooth support (using the official Linux Bluetooth stack
+BlueZ, and D-Bus) must be installed (on Debian-based systems:
 `sudo apt install bluez bluez-tools`; recent Ubuntu releases provide
-bluez as a snap package). In addition to standard Python3 libraries, you
-may need to install the gi, dbus, and psutil Python libraries used by
-uxplay-beacon.py. On Debian-based systems:
+bluez as a snap package). BlueZ tools 'hcitool' and 'hciconfig' (needed
+if you use the HCI module on Linux) are declared "deprecated" by the
+BlueZ developers: some Linux distributions have removed them from the
+default BleuZ packages, into "extra" packages with names like
+"bluez-deprecated".
+
+In addition to standard Python3 libraries, you may need to install the
+gi, dbus, and psutil Python libraries used by uxplay-beacon.py. On
+Debian-based systems:
 
     sudo apt install python3-gi python3-dbus python3-psutil
 
-If a python3-gi package is not found, install the python3-gobject
-package which provides it.
+If a python3-gi package is available in your Linux distribution, install
+the python3-gobject package which provides it.
 
 For Windows support in the MSYS2 UCRT64 environment, use pacman -S to
 install `mingw-w64-ucrt-x86_64-python`, `*-python-gobject`,
@@ -1640,12 +1666,12 @@ installations (such as the one provided in MSYS2) should be
 
     pip install ....  --break-system-packages
 
-The option `--break-system-packages` was required to make users hesitate
-before adding packages not provided by the "external management": *this
-is unnecessarily scary, as in the case of the winrt packages, no
-breakage will occur*.
+The option `--break-system-packages` was added as a requirement to make
+users hesitate before adding packages not provided by the "external
+management": *this is unnecessarily scary, as in the case of the winrt
+packages, no breakage can occur*.
 
-If uxplay will be run with option "`uxplay -ble`" (so it writes data for
+UxPlay must be run with option "`uxplay -ble`" (so it writes data for
 the Bluetooth beacon in the default BLE data file `~/.uxplay.ble`), just
 run `uxplay-beacon.py` in a separate terminal. The python script will
 start Bluetooth LE Service-Discovery advertising when it detects that
@@ -1665,6 +1691,11 @@ Get help with `man uxplay-beacon` or `uxplay-beacon.py --help`.
 
 Options are
 
+-   `<module>` where "module" is BleuIO or HCI (no intital `--`) .
+    Without this option, the default module used will be **BlueZ**
+    (Linux), **winrt** (Windows), **BleuIO** (all other operating
+    systems).
+
 -   `--file <config file>` read beacon options from `<config file>`
     instead of `~/.uxplay.beacon`.
 
@@ -1679,8 +1710,8 @@ Options are
     This also requires that uxplay is run with option
     "`uxplay -ble <BLE data file>`".
 
-The BlueZ/Dbus version has three more options not offered by the Windows
-version (the Windows operating system chooses their values):
+These are the only options accepted by the **winrt** module on Windows.
+The other modules accept
 
 -   `--advmin x`, `--advmax y`. These controls the interval between BLE
     advertisement broadcasts. This interval is in the range \[x, y\],
@@ -1691,6 +1722,11 @@ version (the Windows operating system chooses their values):
     are advmin = advmax = 100. The advertisement is broadcast on all
     three Bluetooth LE advertising channels: 37,38,39.
 
+On a Windows system, the values of these paramaters are set by the
+operating system, and cannot be set by users.
+
+The **BlueZ** module (Linux) also accepts
+
 -   `--index x` (default x = 0, x \>= 0). This can be used by the DBus
     to distinguish between multiple simultaneous instances of
     uxplay-beacon.py that are running to support multiple instances of
@@ -1699,13 +1735,22 @@ version (the Windows operating system chooses their values):
     *Note: running multiple beacons simultaneously on the same host has
     not been tested, and this option might not be useful or needed.*
 
-While the native macOS and \*BSD Bluetooth stacks do not allow
-unpriviledged users to send "manufacturer-specific" advertisements like
-the uxplay service discovery announcement, this can be achieved using
-the BleuIO USB device: the BleuIO module for uxplay-beacon.py is
-installed with UxPlay in all operating systems, including macos and
-\*BSD, while the BlueZ and winrt modules are only installed on Linux and
-Windows, respectively.
+The **BleuIO** and **HCI** modules accept
+
+-   `--device x` which allows overiding automatically-made choices of
+    serial ports (**BleuIO**) or hci device nodes (**HCI**). This is
+    probably only useful if the host system has multiple devices that
+    could be used.
+
+The native macOS Bluetooth stack has no documented way for users to send
+"manufacturer-specific" Bluetooth LE advertisements (such that sent for
+AirPlay Service Discovery), and the only support of uxplay-beacon.py on
+macOS uses a BleuIO USB serial device. However macOS provides a
+low-level utility BlueTool (found at `/usr/sbin/bluetool`) that can send
+HCI commands, so possibly could be used to adapt the python3 **HCI**
+module to support macOS as well (*working implementations welcome!*).
+**The recommended and working method on macOS is to use a BleuIO
+dongle.**
 
 If you wish to test Bluetooth LE Service Discovery on Linux/\*BSD, you
 can disable DNS_SD Service discovery by the avahi-daemon with
@@ -1721,15 +1766,9 @@ Management**: press "Windows + R" to open the Run dialog, run
 `services.msc`, and click on **Bonjour Service** in the alphabetic list.
 This will show links for it to be stopped and restarted.
 
-For more information, see the [wiki
-page](https://github.com/FDH2/UxPlay/wiki/Bluetooth_LE_beacon). This
-page also explains how to setup a BLE beacon for UxPlay on Linux by
-direct accesss to the Bluetooth stack using `hcitool` to send low-level
-HCI commands, with root privileges. This can also be done on FreeBSD
-using `hccontrol`, and on macOS using `bluetool`. **The recommended way
-to set up Bluetooth LE Service Discovery on macOS or \*BSD is to acquire
-a BleuIO USB device, which is supported by uxplay-beacon.py without root
-privileges**.
+For more information on Bluetooth LE support, including HCI commands,
+see the [wiki
+page](https://github.com/FDH2/UxPlay/wiki/Bluetooth_LE_beacon).
 
 -   **Note that Bluetooth LE AirPlay Service Discovery only supports
     broadcast of IPv4 addresses**.
@@ -1769,7 +1808,11 @@ start, stop, status. You might need to edit the avahi-daemon.conf file
 "disable-publishing" is **not** a selected option). Some systems may
 instead use the mdnsd daemon as an alternative to provide DNS-SD
 service. (FreeBSD offers both alternatives, but only Avahi was tested;
-see [here](https://gist.github.com/reidransom/6033227).)
+see [here](https://gist.github.com/reidransom/6033227), or [section
+32.8.1 of the FreeBSD
+Handbook](https://docs.freebsd.org/en/books/handbook/network-servers/#_configuring_and_starting_avahi))
+Note that avahi service is not needed if you instead use a Bluetooth LE
+beacon (see [above](#bluetooth-le-beacon-setup)) for Service-Discovery.
 
 -   **uxplay starts, but either stalls or stops after "Initialized
     server socket(s)" appears (*without the server name showing on the