release: 6.3.4

app/version.txt

@@ -1 +1 @@
-6.3.3
+6.3.4

docs/release-notes/6.3.4.md

@@ -0,0 +1,55 @@
+**Seats now appear on their own, from any machine. Before this they only ever appeared if Moonlight
+was running on the streaming host itself.**
+
+## What was wrong
+
+Seat discovery asked the MultiSeat service for the seat list at `http://127.0.0.1:9550`. On the host
+that works. On anything else — a handheld, a laptop, another PC — `127.0.0.1` is *that* device,
+which runs no MultiSeat service. The request failed and the failure was swallowed on purpose, so no
+seats appeared, no error was shown, and nothing was logged to explain it.
+
+Even had the request succeeded, every seat was reported at `127.0.0.1`, which would have been just
+as unreachable.
+
+## What happens now
+
+Seats are found by checking the ports they use on hosts you already have. A seat's Apollo answers on
+its own port with a name like `MultiSeat-Gaming-1`, which is exactly what happens when you add one
+by hand — that path always worked; discovery simply was not using it.
+
+This needs nothing from the host: no API key on the client, and MultiSeat's dashboard does not have
+to be reachable over the network. If you have the streaming host in your list, its seats should
+appear within about fifteen seconds of being provisioned.
+
+## If a seat still does not appear
+
+Add it manually at the host's address and the seat's port. The first seat uses **48100**, and each
+further seat is thirty higher — 48130, 48160, 48190.
+
+That is also the answer if the host has changed its port settings. Discovery checks the default
+ports, and nothing advertises a custom range, so a host configured differently still needs its seats
+added by hand.
+
+## ⛔ Please read this before updating
+
+**This change has never been run.** It compiles for Windows, macOS and Linux, and the host side is
+confirmed working — a seat really does answer with the name discovery looks for — but no one has
+watched a client find a seat with it. The machine it was written on has no Qt toolchain, so a build
+could not be tested there.
+
+The realistic failure is on the client: discovery reads your host list every fifteen seconds while
+other parts of the app may be writing to it. That was designed around deliberately, but designed
+around is not the same as tested.
+
+**If Moonlight hangs on startup or when adding a host after updating, this is the first thing to
+suspect.** 6.3.3 does not contain this change and is a safe place to go back to.
+
+## Also in this release
+
+The pull request build pipeline has been trimmed to the jobs that actually work. It had failed on
+every run since May, and a check that is always red teaches people to ignore the ones that matter.
+The builds that produce releases were never part of that and are unchanged.
+
+## Unchanged
+
+Everything else. No streaming, decoding, input or audio behaviour differs from 6.3.3.