MoonlightVibe 6.3.4

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.