README update for v1.73.5

This commit is contained in:
F. Duncanh
2026-03-19 03:49:29 -04:00
parent 6d0ff39bf7
commit 3d71c13136
3 changed files with 291 additions and 173 deletions

View File

@@ -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 class="uri">https://github.com/FDH2/UxPlay</a> (where ALL user issues
should be posted, and latest versions can be found).</strong></h3> should be posted, and latest versions can be found).</strong></h3>
<ul> <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 <li><p>Some YouTube app HLS videos now offer alternative language tracks
(generated by AI dubbing). Language choices will be made in order of (generated by AI dubbing). Language choices will be made in order of
preferences set with option -lang (or by environment variable $LANGUAGE, 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> and Video to mp4 file (new option -mp4 [fn]).</p></li>
<li><p>Support for <strong>service discovery using a Bluetooth LE <li><p>Support for <strong>service discovery using a Bluetooth LE
“beacon”</strong> for both Linux/*BSD and Windows (as an alternative to “beacon”</strong> for both Linux/*BSD and Windows (as an alternative to
Bonjour/Rendezvous DNS-SD service discovery). <strong>This can be used Bonjour/Rendezvous DNS-SD service discovery) was introduced in v1.73 and
on networks that do not allow the user to run a DNS_SD service.</strong> improved in 1.73.5. This can be used on networks that do not allow the
The user must run a Bluetooth LE “beacon”, (a USB 4.0 or later “dongle” user to run a DNS_SD service.** The user must run a Bluetooth LE
can be used). The beacon is managed by a Python3 script “beacon”, (Bluetooth 4.0 or later is needed, a cheap USD “dongle” will
<code>uxplay-beacon.py</code>: four implementations of Bleutooth LE do.). The beacon is managed by a Python &gt;= 3.6 script
advertising are available as loadable modules: BlueZ for Linux only, <code>uxplay-beacon.py</code>. Loadable Python modules provide
winrt for Windows only, BleuIO for the BlueIO usb-serial dongle (which appropriate Bluetooth LE support for Linux, Windows, and FreeBSD;
has its own BlueTooth-LE stack, independent of that of the host system) <em>macOS is only supported by the BleuIO USB dongle which uniquely has
that runs on all systems including macOS and *BSD), and a low-level HCI its own Bluetooth LE stack based on a Renesas SoC, and is seen by the
module (Linux and BSD only) that access the Host Contoller Interface host as a serial modem (this can be used on all the operating systems
(but users need enhanced privileges to use this). The beacon runs supported by Uxplay, including other BSD variants).</em> The beacon runs
independently of UxPlay: while UxPlay is running, it regularly independently of UxPlay. While UxPlay is running, the beacon regularly
broadcasts a Bluetooth LE (“Low Energy”) 46 byte legacy-type broadcasts a Bluetooth LE (“Low Energy”) 46 byte legacy-type
advertisement informing nearby iOS/macOS devices of the local IPv4 advertisement informing nearby iOS/macOS devices of the local IPv4
network address of the UxPlay server, and which TCP port to contact 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> <h1 id="bluetooth-le-beacon-setup">Bluetooth LE beacon setup</h1>
<p>The python&gt;=3.6 script for running a Bluetooth LE Service <p>The python&gt;=3.6 script for running a Bluetooth LE Service
Discovery beacon is uxplay-beacon.py. It provides four possible Discovery beacon is uxplay-beacon.py. It provides four possible
Bluetooth LE implementations (loaded as modules): one for Linux systems Bluetooth LE implementations (loaded as modules):</p>
with D-Bus, one for Windows, and one for the <a <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 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 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 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 is needed for macOS where the native operating system Bluetooth stack
send Bluetooth-LE advertisements of the type we require. If a BleuIO does not allow users to send Bluetooth-LE advertising data of the
dongle is available, the bleuio version of the python script can be used “manufacturer-specific” type <code>AdvData=0xFF</code>. If a BleuIO
on many operating systems including macOS, Windows and Linux, and dongle (currently costs about USD25) is available, the BleuIO version of
perhaps *BSD (not tested): it requires python library the python script can be used on many operating systems including macOS,
<code>python3-pyserial</code> to be installed.</p> Windows, Linux, FreeBSD, and probably other BSD variants (not tested):
<p>A fourth implementation (module HCI) for Linux or FreeBSD (maybe it requires python library <code>python3-pyserial</code> to be
other BSDs too?) requires elevated permissions to access the Host installed. On Linux, users must be members of group <code>dialout</code>
Controller Interface. These are granted by adding users to a new group or sometimes <code>uucp</code> (<code>dialer</code> on
“hciusers” that are give permission to call FreeBSD).</p></li>
<code>sudo -n hcitool/hciconfig/hccontrol</code>” without entering a <li><p><strong>HCI</strong> for Linux without D-Bus (uses utiities
password: this can be configured by the system admistrator using visudo, <code>hcitool</code> and <code>hciconfig</code>) or FreeBSD (uses
but has security implications.</p> <code>hccontrol</code>) and requires elevated privileges to access the
<p>On Linux, Bluetooth support (using the offical Linux Bluetooth stack Host Controller Interface. These privileges can be granted by adding
BlueZ) must be installed (on Debian-based systems: 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, FreeBSDs
<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 <code>sudo apt install bluez bluez-tools</code>; recent Ubuntu releases
provide bluez as a snap package). In addition to standard Python3 provide bluez as a snap package). BlueZ tools hcitool and hciconfig
libraries, you may need to install the gi, dbus, and psutil Python (needed if you use the HCI module on Linux) are declared “deprecated” by
libraries used by uxplay-beacon.py. On Debian-based systems:</p> 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> <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 <p>If a python3-gi package is available in your Linux distribution,
package which provides it.</p> install the python3-gobject package which provides it.</p>
<p>For Windows support in the MSYS2 UCRT64 environment, use pacman -S to <p>For Windows support in the MSYS2 UCRT64 environment, use pacman -S to
install <code>mingw-w64-ucrt-x86_64-python</code>, install <code>mingw-w64-ucrt-x86_64-python</code>,
<code>*-python-gobject</code>, <code>*-python-psutil</code>, and <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” <p>For python &gt;= 3.11, the pip commands on “externally-managed”
python installations (such as the one provided in MSYS2) should be</p> python installations (such as the one provided in MSYS2) should be</p>
<pre><code>pip install .... --break-system-packages</code></pre> <pre><code>pip install .... --break-system-packages</code></pre>
<p>The option <code>--break-system-packages</code> was required to make <p>The option <code>--break-system-packages</code> was added as a
users hesitate before adding packages not provided by the “external requirement to make users hesitate before adding packages not provided
management”: <em>this is unnecessarily scary, as in the case of the by the “external management”: <em>this is unnecessarily scary, as in the
winrt packages, no breakage will occur</em>.</p> case of the winrt packages, no breakage can occur</em>.</p>
<p>If uxplay will be run with option “<code>uxplay -ble</code>” (so it <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 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 <code>~/.uxplay.ble</code>), just run <code>uxplay-beacon.py</code> in a
separate terminal. The python script will start Bluetooth LE 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> or <code>uxplay-beacon.py --help</code>.</p>
<p>Options are</p> <p>Options are</p>
<ul> <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 <li><p><code>--file &lt;config file&gt;</code> read beacon options from
<code>&lt;config file&gt;</code> instead of <code>&lt;config file&gt;</code> instead of
<code>~/.uxplay.beacon</code>.</p></li> <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 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> with option “<code>uxplay -ble &lt;BLE data file&gt;</code>”.</p></li>
</ul> </ul>
<p>The BlueZ/Dbus version has three more options not offered by the <p>These are the only options accepted by the <strong>winrt</strong>
Windows version (the Windows operating system chooses their values):</p> module on Windows. The other modules accept</p>
<ul> <ul>
<li><p><code>--advmin x</code>, <code>--advmax y</code>. These controls <li><code>--advmin x</code>, <code>--advmax y</code>. These controls the
the interval between BLE advertisement broadcasts. This interval is in interval between BLE advertisement broadcasts. This interval is in the
the range [x, y], given in units of msecs. Allowed ranges are 100 &lt;= range [x, y], given in units of msecs. Allowed ranges are 100 &lt;= x
x &lt;= y &lt;= 10240. If advmin=advmax, the interval is fixed: if &lt;= y &lt;= 10240. If advmin=advmax, the interval is fixed: if advmin
advmin &lt; advmax it is chosen flexibly in this range to avoid &lt; advmax it is chosen flexibly in this range to avoid interfering
interfering with other tasks the Bluetooth device is carrying out. The with other tasks the Bluetooth device is carrying out. The default
default values are advmin = advmax = 100. The advertisement is broadcast values are advmin = advmax = 100. The advertisement is broadcast on all
on all three Bluetooth LE advertising channels: 37,38,39.</p></li> three Bluetooth LE advertising channels: 37,38,39.</li>
<li><p><code>--index x</code> (default x = 0, x &gt;= 0). This can be </ul>
used by the DBus to distinguish between multiple simultaneous instances <p>On a Windows system, the values of these paramaters are set by the
of uxplay-beacon.py that are running to support multiple instances of 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 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). instance of UxPlay must also have its own MAC address and ports).
<em>Note: running multiple beacons simultaneously on the same host has <em>Note: running multiple beacons simultaneously on the same host has
not been tested, and this option might not be useful or not been tested, and this option might not be useful or
needed.</em></p></li> needed.</em></li>
</ul> </ul>
<p>While the native macOS and *BSD Bluetooth stacks do not allow <p>The <strong>BleuIO</strong> and <strong>HCI</strong> modules
unpriviledged users to send “manufacturer-specific” advertisements like accept</p>
the uxplay service discovery announcement, this can be achieved using <ul>
the BleuIO USB device: the BleuIO module for uxplay-beacon.py is <li><code>--device x</code> which allows overiding automatically-made
installed with UxPlay in all operating systems, including macos and choices of serial ports (<strong>BleuIO</strong>) or hci device nodes
*BSD, while the BlueZ and winrt modules are only installed on Linux and (<strong>HCI</strong>). This is probably only useful if the host system
Windows, respectively.</p> 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 <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> can disable DNS_SD Service discovery by the avahi-daemon with</p>
<pre><code>$ sudo systemctl mask avahi-daemon.socket <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> <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 in the alphabetic list. This will show links for it to be stopped and
restarted.</p> 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 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 page</a>.</p>
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>
<ul> <ul>
<li><strong>Note that Bluetooth LE AirPlay Service Discovery only <li><strong>Note that Bluetooth LE AirPlay Service Discovery only
supports broadcast of IPv4 addresses</strong>.</li> 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 systems may instead use the mdnsd daemon as an alternative to provide
DNS-SD service. (FreeBSD offers both alternatives, but only Avahi was DNS-SD service. (FreeBSD offers both alternatives, but only Avahi was
tested; see <a 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> <ul>
<li><strong>uxplay starts, but either stalls or stops after “Initialized <li><strong>uxplay starts, but either stalls or stops after “Initialized
server socket(s)” appears (<em>without the server name showing on the server socket(s)” appears (<em>without the server name showing on the

105
README.md
View File

@@ -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).** ### **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 - 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 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 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 - 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 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.**
later "dongle" can be used). The beacon is managed by a Python3 script `uxplay-beacon.py`: four implementations of Bleutooth LE advertising are available The user must run a Bluetooth LE "beacon", (Bluetooth 4.0 or later is needed, a cheap USD "dongle" will do.). The
as loadable modules: BlueZ for Linux only, winrt for Windows only, BleuIO beacon is managed by a Python >= 3.6 script `uxplay-beacon.py`. Loadable Python modules provide appropriate Bluetooth LE support for Linux, Windows,
for the BlueIO usb-serial dongle (which has its own BlueTooth-LE stack, independent of that of the 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 system) that runs on all systems including macOS and *BSD), and a low-level HCI module (Linux and BSD only) that 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
access the Host Contoller Interface (but users need enhanced privileges to use this). The beacon of UxPlay. While UxPlay is running, the beacon regularly broadcasts a Bluetooth LE ("Low Energy") 46 byte
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 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 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). are [given below](#bluetooth-le-beacon-setup).
@@ -1560,29 +1559,44 @@ GStreamer inner workings.
# Bluetooth LE beacon setup # Bluetooth LE beacon setup
The python>=3.6 script for running a Bluetooth LE Service Discovery beacon is uxplay-beacon.py. 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, It provides four possible Bluetooth LE implementations (loaded as modules):
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.
A fourth implementation (module HCI) for Linux or FreeBSD (maybe other BSD's too?) requires elevated permissions to access the Host * **BlueZ** for Linux systems with D-Bus;
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 * **winrt** for Windows;
using visudo, but has security implications.
* **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 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: uxplay-beacon.py. On Debian-based systems:
``` ```
sudo apt install python3-gi python3-dbus python3-psutil 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 For Windows support in the MSYS2 UCRT64 environment, use pacman -S to
install `mingw-w64-ucrt-x86_64-python`, ``*-python-gobject``, 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 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": 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 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 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 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 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 * `--file <config file>` read beacon options from ``<config file>`` instead of
`~/.uxplay.beacon`. `~/.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 * `--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>`". 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 * `--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 [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 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. 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 * `--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 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 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._ 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 The **BleuIO** and **HCI** modules accept
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 * `--device x` which allows overiding automatically-made choices of serial ports (**BleuIO**) or hci device nodes (**HCI**). This
in all operating systems, including macos and *BSD, while the BlueZ and winrt modules are only installed on Linux and Windows, respectively. 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 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 run `services.msc`, and click on **Bonjour Service** in the alphabetic list. This
will show links for it to be stopped and restarted. 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 For more information on Bluetooth LE support, including HCI commands, see the [wiki page](https://github.com/FDH2/UxPlay/wiki/Bluetooth_LE_beacon).
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**.
* **Note that Bluetooth LE AirPlay Service Discovery only supports * **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 "disable-publishing" is **not** a selected option). Some systems may
instead use the mdnsd daemon as an alternative to provide DNS-SD instead use the mdnsd daemon as an alternative to provide DNS-SD
service. (FreeBSD offers both alternatives, but only Avahi was tested; 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 - **uxplay starts, but either stalls or stops after "Initialized
server socket(s)" appears (*without the server name showing on the server socket(s)" appears (*without the server name showing on the

View File

@@ -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).** ### **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 - Some YouTube app HLS videos now offer alternative language tracks
(generated by AI dubbing). Language choices will be made in order of (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 - Support for **service discovery using a Bluetooth LE "beacon"** for
both Linux/\*BSD and Windows (as an alternative to both Linux/\*BSD and Windows (as an alternative to
Bonjour/Rendezvous DNS-SD service discovery). **This can be used on Bonjour/Rendezvous DNS-SD service discovery) was introduced in v1.73
networks that do not allow the user to run a DNS_SD service.** The and improved in 1.73.5. This can be used on networks that do not
user must run a Bluetooth LE "beacon", (a USB 4.0 or later "dongle" allow the user to run a DNS_SD service.\*\* The user must run a
can be used). The beacon is managed by a Python3 script Bluetooth LE "beacon", (Bluetooth 4.0 or later is needed, a cheap
`uxplay-beacon.py`: four implementations of Bleutooth LE advertising USD "dongle" will do.). The beacon is managed by a Python \>= 3.6
are available as loadable modules: BlueZ for Linux only, winrt for script `uxplay-beacon.py`. Loadable Python modules provide
Windows only, BleuIO for the BlueIO usb-serial dongle (which has its appropriate Bluetooth LE support for Linux, Windows, and FreeBSD;
own BlueTooth-LE stack, independent of that of the host system) that *macOS is only supported by the BleuIO USB dongle which uniquely has
runs on all systems including macOS and \*BSD), and a low-level HCI its own Bluetooth LE stack based on a Renesas SoC, and is seen by
module (Linux and BSD only) that access the Host Contoller Interface the host as a serial modem (this can be used on all the operating
(but users need enhanced privileges to use this). The beacon runs systems supported by Uxplay, including other BSD variants).* The
independently of UxPlay: while UxPlay is running, it regularly beacon runs independently of UxPlay. While UxPlay is running, the
broadcasts a Bluetooth LE ("Low Energy") 46 byte legacy-type beacon regularly broadcasts a Bluetooth LE ("Low Energy") 46 byte
advertisement informing nearby iOS/macOS devices of the local IPv4 legacy-type advertisement informing nearby iOS/macOS devices of the
network address of the UxPlay server, and which TCP port to contact local IPv4 network address of the UxPlay server, and which TCP port
UxPlay on. Instructions are [given to contact UxPlay on. Instructions are [given
below](#bluetooth-le-beacon-setup). below](#bluetooth-le-beacon-setup).
- option `-vrtp <rest-of-pipeline>` bypasses rendering by UxPlay, and - 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 The python\>=3.6 script for running a Bluetooth LE Service Discovery
beacon is uxplay-beacon.py. It provides four possible Bluetooth LE beacon is uxplay-beacon.py. It provides four possible Bluetooth LE
implementations (loaded as modules): one for Linux systems with D-Bus, implementations (loaded as modules):
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.
A fourth implementation (module HCI) for Linux or FreeBSD (maybe other - **BlueZ** for Linux systems with D-Bus;
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.
On Linux, Bluetooth support (using the offical Linux Bluetooth stack - **winrt** for Windows;
BlueZ) must be installed (on Debian-based systems:
- **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 `sudo apt install bluez bluez-tools`; recent Ubuntu releases provide
bluez as a snap package). In addition to standard Python3 libraries, you bluez as a snap package). BlueZ tools 'hcitool' and 'hciconfig' (needed
may need to install the gi, dbus, and psutil Python libraries used by if you use the HCI module on Linux) are declared "deprecated" by the
uxplay-beacon.py. On Debian-based systems: 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 sudo apt install python3-gi python3-dbus python3-psutil
If a python3-gi package is not found, install the python3-gobject If a python3-gi package is available in your Linux distribution, install
package which provides it. the python3-gobject package which provides it.
For Windows support in the MSYS2 UCRT64 environment, use pacman -S to For Windows support in the MSYS2 UCRT64 environment, use pacman -S to
install `mingw-w64-ucrt-x86_64-python`, `*-python-gobject`, 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 pip install .... --break-system-packages
The option `--break-system-packages` was required to make users hesitate The option `--break-system-packages` was added as a requirement to make
before adding packages not provided by the "external management": *this users hesitate before adding packages not provided by the "external
is unnecessarily scary, as in the case of the winrt packages, no management": *this is unnecessarily scary, as in the case of the winrt
breakage will occur*. 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 the Bluetooth beacon in the default BLE data file `~/.uxplay.ble`), just
run `uxplay-beacon.py` in a separate terminal. The python script will run `uxplay-beacon.py` in a separate terminal. The python script will
start Bluetooth LE Service-Discovery advertising when it detects that 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 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>` - `--file <config file>` read beacon options from `<config file>`
instead of `~/.uxplay.beacon`. instead of `~/.uxplay.beacon`.
@@ -1679,8 +1710,8 @@ Options are
This also requires that uxplay is run with option This also requires that uxplay is run with option
"`uxplay -ble <BLE data file>`". "`uxplay -ble <BLE data file>`".
The BlueZ/Dbus version has three more options not offered by the Windows These are the only options accepted by the **winrt** module on Windows.
version (the Windows operating system chooses their values): The other modules accept
- `--advmin x`, `--advmax y`. These controls the interval between BLE - `--advmin x`, `--advmax y`. These controls the interval between BLE
advertisement broadcasts. This interval is in the range \[x, y\], 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 are advmin = advmax = 100. The advertisement is broadcast on all
three Bluetooth LE advertising channels: 37,38,39. 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 - `--index x` (default x = 0, x \>= 0). This can be used by the DBus
to distinguish between multiple simultaneous instances of to distinguish between multiple simultaneous instances of
uxplay-beacon.py that are running to support multiple 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 *Note: running multiple beacons simultaneously on the same host has
not been tested, and this option might not be useful or needed.* not been tested, and this option might not be useful or needed.*
While the native macOS and \*BSD Bluetooth stacks do not allow The **BleuIO** and **HCI** modules accept
unpriviledged users to send "manufacturer-specific" advertisements like
the uxplay service discovery announcement, this can be achieved using - `--device x` which allows overiding automatically-made choices of
the BleuIO USB device: the BleuIO module for uxplay-beacon.py is serial ports (**BleuIO**) or hci device nodes (**HCI**). This is
installed with UxPlay in all operating systems, including macos and probably only useful if the host system has multiple devices that
\*BSD, while the BlueZ and winrt modules are only installed on Linux and could be used.
Windows, respectively.
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 If you wish to test Bluetooth LE Service Discovery on Linux/\*BSD, you
can disable DNS_SD Service discovery by the avahi-daemon with 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. `services.msc`, and click on **Bonjour Service** in the alphabetic list.
This will show links for it to be stopped and restarted. This will show links for it to be stopped and restarted.
For more information, see the [wiki For more information on Bluetooth LE support, including HCI commands,
page](https://github.com/FDH2/UxPlay/wiki/Bluetooth_LE_beacon). This see the [wiki
page also explains how to setup a BLE beacon for UxPlay on Linux by page](https://github.com/FDH2/UxPlay/wiki/Bluetooth_LE_beacon).
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**.
- **Note that Bluetooth LE AirPlay Service Discovery only supports - **Note that Bluetooth LE AirPlay Service Discovery only supports
broadcast of IPv4 addresses**. 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 "disable-publishing" is **not** a selected option). Some systems may
instead use the mdnsd daemon as an alternative to provide DNS-SD instead use the mdnsd daemon as an alternative to provide DNS-SD
service. (FreeBSD offers both alternatives, but only Avahi was tested; 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 - **uxplay starts, but either stalls or stops after "Initialized
server socket(s)" appears (*without the server name showing on the server socket(s)" appears (*without the server name showing on the