.NEW in v1.73, up to v1.73.6 (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 the first choice, if available, then Spanish (“es”),
etc. $LANGUAGE has the same format: -lang (by itself)
suppresses playing of dubbed audio if $LANGUAGE is set.
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) was introduced in v1.73 and
improved in 1.73.4 - 1.73.6. 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.
option -vrtp <rest-of-pipeline> bypasses
rendering by UxPlay, and instead transmits rtp packets of decrypted h264
or h265 video to an external renderer (e.g. OBS Studio) at an address
specified in rest-of-pipeline. Similarly,
-artp <rest-of-pipeline> forwards decoded audio as
L16 RTP packets. Both options can be used together to forward video and
audio (as separate concurrent streams) to external applications. See Usage for more details and sample Gstreamer receiver
pipelines.
(for Linux/*BSD Desktop Environments using D-Bus). New option
-scrsv <n> provides screensaver inhibition (e.g., to
prevent screensaver function while watching mirrored videos without
keyboard or mouse activity): n = 0 (off) n=1 (on while streaming video)
n=2 (always on while UxPlay is running). Tested on
Gnome/KDE/Cinnamon/Mate/Xfce 4: may need adjustment for other Desktop
Environments (please report). (watch output of dbus-monitor
to verify that inhibition is working). Might not work on
Wayland.
option -ca (with no filename given) will now render Apple Music
cover art (in audio-only mode) inside UxPlay. (-ca
<filename> will continue to export cover art for
display by an external viewer).
Improved Support for (YouTube) HLS (HTTP Live Streaming) video with the new “-hls” option (introduced in 1.71).* Only streaming from the YouTube iOS app (in "m3u8" protocol) is currently supported: (streaming using the AirPlay icon in a browser window is not yet supported).Click on the airplay icon in the YouTube app to stream video. Please report any issues with this new feature of UxPlay.
The default video player for HLS is GStreamer playbin v3: use “-hls 2” to revert to the older GStreamer player playbin v2 if some videos fail to play.
user-requested features: added support for setting a password (as an alternative to on-screen pin codes) to control client access (-pw option, see “man pw” or this README for details); added support for setting initial client audio-streaming volume (-vol option), and output of audio-mode metadata to file (for display by some external process, -md option).
Note: AirPlay2 multi-room audio streaming is not supported: use shairport-sync for that.
.
Install uxplay on Debian-based Linux systems with
“sudo apt install uxplay”; on FreeBSD with
“sudo pkg install uxplay”; on OpenBSD with
“doas pkg_add uxplay”. Also available on Arch-based systems
through AUR. Since v. 1.66, uxplay is now also packaged in RPM format by
Fedora 38 (“sudo dnf install uxplay”).
For other RPM-based distributions which have not yet packaged UxPlay, a RPM “specfile” uxplay.spec is now provided with recent releases (see their “Assets”), and can also be found in the UxPlay source top directory. See the section on using this specfile for building an installable RPM package.
If your distribution does not supply UxPlay, or you want the latest version, it is very easy to build it yourself: see the very detailed instructions for building UxPlay from source. later in this document.
(On Linux and *BSD): if a firewall is active on the server
hosting UxPlay, make sure the default network port (UDP 5353) for
mDNS/DNS-SD queries is open (see Troubleshooting below for more details);
also open three UDP and three TCP ports for Uxplay, and use the “uxplay
-p man uxplay” or
“uxplay -h”).
Even if you install your distribution’s pre-compiled uxplay binary package, you may need to read the instructions below for running UxPlay to see which of your distribution’s GStreamer plugin packages you should also install.
For Audio-only mode (Apple Music, etc.) best quality is obtained with the option “uxplay -async”, but there is then a 2 second latency imposed by iOS. Use option “uxplay -ca” to display any “Cover Art” that accompanies the audio.
If you are using UxPlay just to mirror the client’s screen (without showing videos that need audio synchronized with video), it is best to use the option “uxplay -vsync no”.
Add any UxPlay options you want to use as defaults to a startup
file ~/.uxplayrc (see “man uxplay” or
“uxplay -h” for format and other possible locations; the
location can also be set with “uxplay -rc location”). In
particular, if your system uses PipeWire audio or Wayland video systems,
you may wish to add “as pipewiresink” or “vs waylandsink” as defaults to
the file. (Output from terminal commands “ps waux | grep pulse” or
“pactl info” will contain “pipewire” if your Linux/BSD system uses
it).
For Linux/*BSD systems using D-Bus, the option
-scrsv 1 inhibits the screensaver while there is video
activity on UxPlay (-scrsv 2 inhibits it whenever UxPlay is
running).
For Linux systems using systemd, there is a
systemd service file uxplay.service
found in the UxPlay top directory of the distribution, and also
installed in <DOCDIR>/uxplay/systemd/ (where DOCDIR
is usually /usr/local/share/doc), that allows users to
start their own instance of UxPlay as a rootless daemon: it should
either be added to the directory /etc/systemd/user, or the user can just
create their own systemd directory ~/.config/systemd/user/
and then copy uxplay.service into it. To save uxplay terminal output to
a file ~/uxplay.log, uncomment the StandardOutput entry in
uxplay.service. Then
systemctl --user [start/stop/enable/disable/status] uxplay
can be used to control the daemon. If it is enabled, the daemon will start at the user’s first login and stop when they no longer have any open sessions. See https://www.baeldung.com/linux/systemd-create-user-services for more about systemd user services. If more than one user might simultaneously run uxplay this way, they should specify distinct -p and -m options (ports and deviceID) in their startup files. Note: it is NOT recommended to run UxPlay as a root service.
On Raspberry Pi: models using hardware h264 video decoding by the Broadcom GPU (models 4B and earlier) may require the uxplay option -bt709. If you use Ubuntu 22.10 or earlier, GStreamer must be patched to use hardware video decoding by the Broadcom GPU (also recommended but optional for Raspberry Pi OS (Bullseye): the patched GStreamer does not need option ” -bt709`“. The need for -bt709 when hardware video decoding is used seems to have reappeared starting with GStreamer-1.22.
If UxPlay is used in a public space, there are security options for requiring an AppleTV-style one-time pin (displayed on the terminal) to be entered, or a password, and for barring/permitting client access by their device ID. See options -pin, -reg, -pw, -restrict, -allow, -block.
This project is a GPLv3 open source unix AirPlay2 Mirror server for Linux, macOS, and *BSD. It was initially developed by antimof using code from OpenMAX-based RPiPlay, which in turn derives from AirplayServer, shairplay, and playfair. (The antimof site is no longer involved in development, but periodically posts updates pulled from the new main UxPlay site).
UxPlay is tested on a number of systems, including (among others) Debian (10 “Buster”, 11 “Bullseye”, 12 “Bookworm”), Ubuntu (20.04 LTS, 22.04 LTS, 23.04 (also Ubuntu derivatives Linux Mint, Pop!_OS), Red Hat and clones (Fedora 38, Rocky Linux 9.2), openSUSE Leap 15.5, Mageia 9, OpenMandriva “ROME”, PCLinuxOS, Arch Linux, Manjaro, and should run on any Linux system. Also tested on macOS Catalina and Ventura (Intel) and Sonoma (M2), FreeBSD 14.0, Windows 10 and 11 (64 bit).
On Raspberry Pi 4 model B, it is tested on Raspberry Pi OS (Bullseye and Bookworm) (32- and 64-bit), Ubuntu 22.04 LTS and 23.04, Manjaro RPi4 23.02, and (without hardware video decoding) on openSUSE 15.5. Also tested on Raspberry Pi Zero 2 W, 3 model B+, and now 5.
Its main use is to act like an AppleTV for screen-mirroring (with audio) of iOS/iPadOS/macOS clients (iPhone, iPod Touch, iPad, Mac computers) on the server display of a host running Linux, macOS, or other unix (and now also Microsoft Windows). UxPlay supports Apple’s AirPlay2 protocol using “Legacy Protocol”, but some features are missing. (Details of what is publicly known about Apple’s AirPlay 2 protocol can be found here, here and here; see also pyatv which could be a resource for adding modern protocols.) While there is no guarantee that future iOS releases will keep supporting “Legacy Protocol”, iOS 17 continues support.
The UxPlay server and its client must be on the same local area network, on which a Bonjour/Zeroconf mDNS/DNS-SD server is also running (only DNS-SD “Service Discovery” service is strictly necessary, it is not necessary that the local network also be of the “.local” mDNS-based type). On Linux and BSD Unix servers, this is usually provided by Avahi, through the avahi-daemon service, and is included in most Linux distributions (this service can also be provided by macOS, iOS or Windows servers). There is now an alternative Service discovery method, using a Bluetooth LE “beacon” See below for instructions.
Connections to the UxPlay server by iOS/MacOS clients can be
initiated both in AirPlay Mirror mode (which streams
lossily-compressed AAC audio while mirroring the client screen, or in
the alternative AirPlay Audio mode which streams Apple
Lossless (ALAC) audio without screen mirroring. In
Audio mode, metadata is displayed in the uxplay
terminal; if UxPlay option -ca <name> is used, the
accompanying cover art is also output to a periodically-updated file
<name>, and can be viewed with a (reloading) graphics
viewer of your choice. Switching between
Mirror and Audio modes
during an active connection is possible: in Mirror
mode, stop mirroring (or close the mirror window) and start an
Audio mode connection, switch back by initiating
a Mirror mode connection; cover-art display
stops/restarts as you leave/re-enter Audio
mode.
Note that Apple video-DRM (as found in “Apple TV app” content on the client) cannot be decrypted by UxPlay, and the Apple TV app cannot be watched using UxPlay’s AirPlay Mirror mode (only the unprotected audio will be streamed, in AAC format).
With the new “-hls” option, UxPlay now also supports non-Mirror AirPlay video streaming (where the client controls a web server on the AirPlay server that directly receives HLS content to avoid it being decoded and re-encoded by the client). This currently only supports streaming of YouTube videos. Without the -hls option, using the icon for AirPlay video in apps such as the YouTube app will only send audio (in lossless ALAC format) without the accompanying video.
UxPlay uses GStreamer “plugins” for rendering audio and video. This means that video and audio are supported “out of the box”, using a choice of plugins. AirPlay streams video in h264 format: gstreamer decoding is plugin agnostic, and uses accelerated GPU hardware h264 decoders if available; if not, software decoding is used.
VA-API for Intel and AMD integrated graphics, NVIDIA with “Nouveau” open-source driver
With an Intel or AMD GPU, hardware decoding with the open-source VA-API gstreamer plugins is preferable. (Newer “va” versions of these plugins with names like “vah264dec” are recommended instead of older “vaapi” ones named like “vaapih264dec”.) The open-source “Nouveau” drivers for NVIDIA graphics are also in principle supported: see here, but this requires VAAPI to be supplemented with firmware extracted from the proprietary NVIDIA drivers.
NVIDIA with proprietary drivers
The nvh264dec plugin (included in
gstreamer1.0-plugins-bad since GStreamer-1.18.0) can be used for
accelerated video decoding on the NVIDIA GPU after NVIDIA’s CUDA driver
libcuda.so is installed. For GStreamer-1.16.3 or earlier,
the plugin is called nvdec, and must be built
by the user.
Video4Linux2 support for h264 hardware decoding on Raspberry Pi (Pi 4B and older)
Raspberry Pi (RPi) computers (tested on Pi 4 Model B) can now run UxPlay using software video decoding, but hardware-accelerated h264/h265 decoding by firmware in the Pi’s Broadcom 2835 GPU is prefered. UxPlay accesses this using the GStreamer-1.22 Video4Linux2 (v4l2) plugin; Uses the out-of-mainline Linux kernel module bcm2835-codec maintained by Raspberry Pi, so far only included in Raspberry Pi OS, and two other distributions (Ubuntu, Manjaro) available with Raspberry Pi Imager. (For GStreamer < 1.22, see the UxPlay Wiki). Pi model 5 has no support for hardware H264 decoding, as its CPU is powerful enough for satisfactory software H264 decoding
Support for h265 (HEVC) hardware decoding on Raspberry Pi (Pi 4 model B and Pi 5)
These Raspberry Pi models have a dedicated HEVC decoding block (not the GPU), with a driver “rpivid” which is not yet in the mainline Linux kernel (but is planned to be there in future). Unfortunately it produces decoded video in a non-standard pixel format (NC30 or “SAND”) which will not be supported by GStreamer until the driver is in the mainline kernel; without this support, UxPlay support for HEVC hardware decoding on Raspberry Pi will not work.
UxPlay’s GPLv3 license does not have an added “GPL exception” explicitly allowing it to be distributed in compiled form when linked to OpenSSL versions prior to v. 3.0.0 (older versions of OpenSSL have a license clause incompatible with the GPL unless OpenSSL can be regarded as a “System Library”, which it is in *BSD). Many Linux distributions treat OpenSSL as a “System Library”, but some (e.g. Debian) do not: in this case, the issue is solved by linking with OpenSSL-3.0.0 or later.
Either download and unzip UxPlay-master.zip, or (if git is installed): “git clone https://github.com/FDH2/UxPlay”. You can also download a recent or earlier version listed in Releases.
(Adapt these instructions for non-Debian-based Linuxes or *BSD; for macOS, see specific instruction below). See Troubleshooting below for help with any difficulties.
You need a C/C++ compiler (e.g. g++) with the standard development
libraries installed. Debian-based systems provide a package
“build-essential” for use in compiling software. You also need
pkg-config: if it is not found by “which pkg-config”,
install pkg-config or its work-alike replacement pkgconf. Also make sure
that cmake>=3.10 is installed: “sudo apt install cmake”
(add build-essential and pkg-config (or
pkgconf) to this if needed).
Make sure that your distribution provides OpenSSL 1.1.1 or later, and libplist 2.0 or later. (This means Debian 10 “Buster” based systems (e.g, Ubuntu 18.04) or newer; on Debian 10 systems “libplist” is an older version, you need “libplist3”.) If it does not, you may need to build and install these from source (see instructions at the end of this README).
If you have a non-standard OpenSSL installation, you may need to set
the environment variable OPENSSL_ROOT_DIR (e.g. ,
“export OPENSSL_ROOT_DIR=/usr/local/lib64” if that is where
it is installed). Similarly, for non-standard (or multiple) GStreamer
installations, set the environment variable GSTREAMER_ROOT_DIR to the
directory that contains the “…/gstreamer-1.0/” directory of the
gstreamer installation that UxPlay should use (if this is e.g.
“~/my_gstreamer/lib/gstreamer-1.0/”, set this location with
“export GSTREAMER_ROOT_DIR=$HOME/my_gstreamer/lib”).
In a terminal window, change directories to the source directory of the downloaded source code (“UxPlay-*”, “*” = “master” or the release tag for zipfile downloads, “UxPlay” for “git clone” downloads), then follow the instructions below:
Note: By default UxPlay will be built with
optimization for the computer it is built on; when this is not the case,
as when you are packaging for a distribution, use the cmake option
-DNO_MARCH_NATIVE=ON.
If you use X11 Windows on Linux or *BSD, and wish to toggle in/out of
fullscreen mode with a keypress (F11 or Alt_L+Enter) UxPlay needs to be
built with a dependence on X11. Starting with UxPlay-1.59, this will be
done by default IF the X11 development libraries are
installed and detected. Install these with
“sudo apt install libx11-dev”. If GStreamer < 1.20 is
detected, a fix needed by screen-sharing apps (e.g., Zoom) will
also be made.
-DNO_X11_DEPS=ON.sudo apt install libssl-dev libplist-dev“. (unless
you need to build OpenSSL and libplist from source).sudo apt install libavahi-compat-libdnssd-devsudo apt install libgstreamer1.0-dev libgstreamer-plugins-base1.0-dev.
(*Skip if you built Gstreamer from source)cmake . (For a cleaner build, which is useful if
you modify the source, replace this by
“mkdir build; cd build; cmake ..”: you can then delete
the contents of the build directory if needed, without
affecting the source.) Also add any cmake “-D” options
here as needed (e.g, -DNO_X11_DEPS=ON or
-DNO_MARCH_NATIVE=ON).makesudo make install (you can afterwards uninstall with
sudo make uninstall in the same directory in which this was
run).This installs the executable file “uxplay” to
/usr/local/bin, (and installs a manpage to somewhere
standard like /usr/local/share/man/man1 and README files to
somewhere like /usr/local/share/doc/uxplay). (If “man
uxplay” fails, check if $MANPATH is set: if so, the path to the manpage
(usually /usr/local/share/man/) needs to be added to $MANPATH .) The
uxplay executable can also be found in the build directory after the
build process, if you wish to test before installing (in which case the
GStreamer plugins must first be installed).
**For those with RPM-based distributions, a RPM spec file uxplay.spec is also available: see Building an installable rpm package.
Red Hat, or clones like CentOS (now continued as Rocky Linux or Alma Linux): (sudo dnf install, or sudo yum install) openssl-devel libplist-devel avahi-compat-libdns_sd-devel gstreamer1-devel gstreamer1-plugins-base-devel (+libX11-devel for fullscreen X11) (some of these may be in the “CodeReady” add-on repository, called “PowerTools” by clones)
Mageia, PCLinuxOS, OpenMandriva: Same as Red Hat, except for name changes: (Mageia) “gstreamer1.0-devel”, “gstreamer-plugins-base1.0-devel”; (OpenMandriva) “libopenssl-devel”, “gstreamer-devel”, “libgst-plugins-base1.0-devel”. PCLinuxOS: same as Mageia, but uses synaptic (or apt) as its package manager.
openSUSE: (sudo zypper install) libopenssl-3-devel (formerly libopenssl-devel) libplist-2_0-devel (formerly libplist-devel) avahi-compat-mDNSResponder-devel gstreamer-devel gstreamer-plugins-base-devel (+ libX11-devel for fullscreen X11).
Arch Linux (Also available as a package in AUR): (sudo pacman -Syu) openssl libplist avahi gst-plugins-base.
FreeBSD: (sudo pkg install) libplist gstreamer1. Either avahi-libdns or mDNSResponder must also be installed to provide the dns_sd library. OpenSSL is already installed as a System Library.
OpenBSD: (doas pkg_add) libplist gstreamer1-plugins-base. avahi-libs must also be installed to provide the dns_sd library; (avahi-main must also be installed). OpenSSL is already installed as a System Library.
First-time RPM builders should first install the rpm-build and
rpmdevtools packages, then create the rpmbuild tree with
“rpmdev-setuptree”. Then download and copy uxplay.spec into
~/rpmbuild/SPECS. In that directory, run
“pmdev-spectool -g -R uxplay.spec” to download the
corresponding source file uxplay-*.tar.gz into
~/rpmbuild/SOURCES (“rpmdev-spectool” may also be just
called “spectool”); then run “rpmbuild -ba uxplay.spec”
(you will need to install any required dependencies this reports). This
should create the uxplay RPM package in a subdirectory of
~/rpmbuild/RPMS. (uxplay.spec is tested on
Fedora 38, Rocky Linux 9.2, openSUSE Leap 15.5, Mageia 9, OpenMandriva,
PCLinuxOS; it can be easily modified to include dependency lists for
other RPM-based distributions.)
Next install the GStreamer plugins that are needed with
sudo apt install gstreamer1.0-<plugin>. Values of
<plugin> required are:
Debian-based distributions split some of the plugin packages into smaller pieces: some that may also be needed include “gl” for OpenGL support (this provides the “-vs glimagesink” videosink, which can be very useful in many systems (including Raspberry Pi), and should always be used when using h264/h265 decoding by a NVIDIA GPU), “gtk3” (which provides the “-vs gtksink” videosink), and “x” for X11 support, although these may already be installed. If sound is not working, “alsa”“,”pulseaudio”, or “pipewire” plugins may need to be installed, depending on how your audio is set up.
A package “vaapi” is available for hardware-accelerated h264 video decoding by Intel or AMD graphics (but not for use with NVIDIA using proprietary drivers). However this package contains older drivers (vaapisink, vaapih264dec, etc) that are no longer developed, and should not be installed unless these needed. The “va” plugins (vah264dec, etc.) that replace the “vaapi” plugins are provided in “plugins-bad”: and use standard videosinks (xvimagesink, glimagesink, etc.) instead of the special videosink “vaapisink” used by “vaapi” plugins.
Also install “gstreamer1.0-tools” to get the utility gst-inspect-1.0 for examining the GStreamer installation.
In some cases, because of patent issues, the libav plugin feature avdec_aac needed for decoding AAC audio in mirror mode is not provided in the official distribution: get it from community repositories for those distributions. _Note: the (deprecated) “vaapi” packages listed below are no longer recommended: newer “va” versions of the VA-API plugins for Intel/AMD graphics are provided by *-plugins-bad._
Red Hat, or clones like CentOS (now continued as Rocky Linux or Alma Linux): Install gstreamer1-libav gstreamer1-plugins-bad-free (deprecated: gstreamer1-vaapi for Intel/AMD graphics). In recent Fedora, gstreamer1-libav is renamed gstreamer1-plugin-libav. To get avdec_aac, install packages from rpmfusion.org: (get ffmpeg-libs from rpmfusion; on RHEL or clones, but not recent Fedora, also get gstreamer1-libav from there).
Mageia, PCLinuxOS, OpenMandriva: Install gstreamer1.0-libav gstreamer1.0-plugins-bad (deprecated: gstreamer1.0-vaapi for Intel/AMD graphics). On Mageia, to get avdec_aac, install ffmpeg from the “tainted” repository, (which also provides a more complete gstreamer1.0-plugins-bad).
openSUSE: Install gstreamer-plugins-libav gstreamer-plugins-bad (deprecated: gstreamer-plugins-vaapi for Intel/AMD graphics). To get avdec_aac, install libav* packages for openSUSE from Packman “Essentials”; recommendation: after adding the Packman repository, use the option in YaST Software management to switch all system packages for multimedia to Packman).
Arch Linux Install gst-plugins-good gst-plugins-bad gst-libav (deprecated: gstreamer-vaapi for Intel/AMD graphics).
FreeBSD: Install gstreamer1-libav, gstreamer1-plugins, gstreamer1-plugins-* (* = core, good, bad, x, gtk, gl, vulkan, pulse, v4l2, …), (deprecated: gstreamer1-vaapi for Intel/AMD graphics).
OpenBSD: Install gstreamer1-libav, gstreamer-plugins-* (* = core, bad, base, good).
Since UxPlay-1.64, UxPlay can be started with options read from a
configuration file, which will be the first found of (1) a file with a
path given by environment variable $UXPLAYRC, (2)
~/.uxplayrc in the user’s home directory (“~”), (3)
~/.config/uxplayrc. The format is one option per line,
omitting the initial "-" of the command-line option. Lines
in the configuration file beginning with "#" are treated as
comments and ignored.
Run uxplay in a terminal window. On some systems,
you can specify fullscreen mode with the -fs option, or
toggle into and out of fullscreen mode with F11 or (held-down left
Alt)+Enter keys. Use Ctrl-C (or close the window) to terminate it when
done.
If the UxPlay server is not seen by the iOS client’s drop-down
“Screen Mirroring” panel, check that your DNS-SD server (usually
avahi-daemon) is running: do this in a terminal window with
systemctl status avahi-daemon. If this shows the
avahi-daemon is not running, control it with
sudo systemctl [start,stop,enable,disable] avahi-daemon (on
non-systemd systems, such as *BSD, use
sudo service avahi-daemon [status, start, stop, restart, ...]).
If UxPlay is seen, but the client fails to connect when it is selected,
there may be a firewall on the server that prevents UxPlay from
receiving client connection requests unless some network ports are
opened: if a firewall is active, also open UDP port 5353 (for
mDNS queries) needed by Avahi. See Troubleshooting below for help with this or
other problems.
Note that there is now an alternative Service Discovery method using a Bluetooth LE beacon. See the instructions on Bluetooth beacon setup.
Unlike an Apple TV, the UxPlay server does not by default require
clients to initially “pair” with it using a pin code displayed by the
server (after which the client “trusts” the server, and does not need to
repeat this). Since v1.67, Uxplay offers such “pin-authentication” as an
option: see “-pin” and “-reg” in Usage for details, if you wish to use it. Some
clients with MDM (Mobile Device Management, often present on
employer-owned devices) are required to use pin-authentication: UxPlay
will provide this even when running without the pin option.
Password authentication (-pw pwd) is also offered as an
alternative solution to pin codes: users need to know the password
pwd and enter it on their iOS/macOS device to access UxPlay,
when prompted (if pwd is not set, a displayed random pin code
must be entered at each new connection.)
By default, UxPlay is locked to its current client until that
client drops the connection; since UxPlay-1.58, the option
-nohold modifies this behavior so that when a new client
requests a connection, it removes the current client and takes over.
UxPlay 1.66 introduces a mechanism ( -restrict,
-allow <id>, -block <id>) t