From 70ff22b848e8111dc5c3a65ad87211646738cb39 Mon Sep 17 00:00:00 2001 From: vibesoftwarecoder Date: Thu, 10 Sep 2026 10:42:51 -0500 Subject: [PATCH] release: 6.3.4 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit app/version.txt 6.3.3 -> 6.3.4, plus notes. The tag must equal v or the release build fails on purpose, so the bump comes first. Ships two merged commits: 00e256a4 (seats are found by probing the seat port block instead of asking the MultiSeat service at 127.0.0.1, which could only ever work with Moonlight running on the host) and 1c5f5395 (the PR build pipeline trimmed to the jobs that pass). ⛔ The notes lead with the fact that the discovery change has NEVER BEEN RUN. It compiles under Qt 5.14.1 and Qt 6, and the host side is confirmed -- a seat answers /serverinfo with the name discovery looks for -- but no client has executed this code. The machine it was written on has no Qt toolchain. The plausible failure is client-side: discovery reads the host list every 15s while other paths write to it under a write lock on a thread pool. A pull model was chosen specifically to avoid deadlocking against that, but designed-around is not tested. The notes say so, name the symptom to watch for, and point at 6.3.3 as the way back. Understating that would be the wrong trade for a client binary people install. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01SQvL62WkT8xDWXqyjFCGDw --- app/version.txt | 2 +- docs/release-notes/6.3.4.md | 55 +++++++++++++++++++++++++++++++++++++ 2 files changed, 56 insertions(+), 1 deletion(-) create mode 100644 docs/release-notes/6.3.4.md diff --git a/app/version.txt b/app/version.txt index 7849b73dc..8ac3c4451 100644 --- a/app/version.txt +++ b/app/version.txt @@ -1 +1 @@ -6.3.3 +6.3.4 diff --git a/docs/release-notes/6.3.4.md b/docs/release-notes/6.3.4.md new file mode 100644 index 000000000..6f256e331 --- /dev/null +++ b/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.