Tearing down a seat interrupts a standalone Apollo's stream (encoder restart)

[vibesoftwarecoder]

Summary

Tearing down a seat interrupts an in-progress stream on a standalone/console Apollo. The console Apollo tears down its encoder, re-enumerates the GPU, rebuilds its capture pipeline and creates a new encoder — roughly a one-second stall for whoever is watching.

This contradicts what CLAUDE.md promises under "Coexistence with a standalone Apollo":

MultiSeat is self-contained and non-destructive: it works out of the box whether or not the host already runs a standalone Apollo (e.g. for the main console account).

The three guarantees listed there (own binary, own port range, never kills a non-MultiSeat Apollo) all hold. They just do not cover this: we never touch the other Apollo's process, but we do disturb its capture.

Evidence

Measured on the reference host while a Moonlight client was connected to the console Apollo. Two seat teardowns, two encoder restarts, sub-second correlation each time:

MultiSeat: seat torn down	Console Apollo: encoder teardown
08:45:13	08:45:12.674
09:00:35	09:00:34.484

Console Apollo log around the second one:

[09:00:34.484]: Info: Starting async encoder teardown
[09:00:34.544]: Info: Async encoder teardown complete
[09:00:35.108]: Info:
Device Description : NVIDIA GeForce RTX 3080
...
Capture size       : 1920x1080
[09:00:35.109]: Info: Desktop resolution [1920x1080]
[09:00:35.138]: Info: Creating encoder [hevc_nvenc]

That is a full capture-pipeline rebuild, not a parameter change.

Mechanism

The console Apollo on this host is headless, so it runs on its own SudoVDA display (\.\DISPLAY30) captured via DXGI desktop duplication.

SeatManager.TeardownSeatInternalAsync calls _apolloManager.Stop(seat), and the seat's Apollo removes the SudoVDA display it created on the way out. SessionLauncher.LogoffSession follows shortly after. Either is a desktop topology change, and a topology change invalidates an existing DXGI duplication (DXGI_ERROR_ACCESS_LOST), which is exactly what would force the console Apollo to rebuild.

Worth noting VirtualDisplayManager.DestroyDisplayAsync is not the culprit — it is bookkeeping only and says so:

/// Release the virtual display assignment for a seat.
/// Does not destroy the underlying SudoVDA driver display.

What I did not establish

• Provisioning appears not to do this. Seats provisioned at 08:44:18 and 09:00:14 produced no encoder restart in the console Apollo. So on this evidence it is removal, not addition, that hurts — but that is two samples, not a controlled test.
• The precise trigger is inferred, not proven. I have not separated "seat Apollo exits and drops its display" from "RDP session logs off" — both happen within a second of each other in the teardown path, and either could be the topology change that matters.
• Unknown whether a seat's Apollo suffers the same thing when a different seat is torn down. If it does, this is not only a coexistence bug but a multi-seat one, and considerably more serious.

Why it matters

The whole point of the coexistence guarantees is that someone can run MultiSeat on a machine they also game on. A one-second freeze in the console player's stream every time a seat goes away is a poor experience, and it is invisible from the MultiSeat side — nothing logs it, and the operator tearing a seat down has no idea they just interrupted someone.

It also has a practical consequence for anyone developing on this project: routine seat churn during testing degrades a stream that someone else is using on the same box.

Possible directions

Not investigated, in rough order of appeal:

1. Find out whether the removal can be made quieter — e.g. whether ordering the teardown so the RDP session logs off before the seat's Apollo exits produces one topology change instead of two.
2. Warn rather than fix. Detect a connected client on a non-MultiSeat Apollo and log a warning (or refuse without a flag) when tearing down a seat. Cheap, honest, and removes the "invisible" part even if the stall stays.
3. Establish whether seat-to-seat interference exists, since that would change the priority entirely.

Documentation should be corrected either way — the non-destructive claim needs this exception stated.

[vibesoftwarecoder]

Measured this today. Seat-to-seat interference does not exist — the blast radius is the console Apollo only.

Method

Two seats on one host, with the console Apollo watched throughout as a positive control: this issue already establishes that a seat teardown makes it rebuild its encoder, so if the console reacts in the same measurement window and the other seat does not, the instrument is demonstrably working rather than just silent.

Seat A (Gaming, session 6, Apollo pid 77964, portBase 48100) provisioned first and left running. Then seat B provisioned and torn down underneath it, sampling after each event: A's Apollo pid, bytes appended to A's apollo.log, and a TLS request to A's web UI.

Result

event	seat A	console Apollo
provision seat B	pid alive, 0 bytes logged, web UI 200	0 bytes
tear down seat B	pid alive, nothing logged, web UI 200	1900 bytes — encoder teardown + full rebuild
tear down seat A	—	1900 bytes — encoder teardown + full rebuild

The console side, on both teardowns:

Info: Starting async encoder teardown
Info: Async encoder teardown complete
Device Description : NVIDIA GeForce RTX 3080
Capture size       : 1920x1080
Info: Display refresh rate [60Hz]

Seat A's log did grow by 69 bytes during seat B's teardown, but that was entirely my own health probe — two Web UI: [127.0.0.1] -- redirecting lines from the TLS check. Discounting those, seat A logged nothing at all in response to either event.

What this means for the issue

• Provisioning disturbs nobody. Not the console, not another seat. Only teardown is destructive.
• Only the console Apollo reacts to a teardown, and it does so reproducibly — three times today.
• Seats are isolated from each other. A seat's Apollo does not notice another seat's virtual display appearing or detaching.

That lowers the severity meaningfully. The damage is bounded to a host that runs a standalone Apollo alongside MultiSeat, and it does not compound as seats are added — a busy multi-seat host churning seats does not degrade its own seats. It stays a real bug for the coexistence guarantee this project documents, but it is not the multi-seat-wide problem it could have been.

One caveat on scope: no Moonlight client was connected during this run, so this measures whether the other seat's Apollo is disturbed, not whether an in-flight stream on it would visibly stall. Given seat A logged nothing whatsoever — no capture reinit, no display change — there is nothing for a stream to have stalled on.

[vibesoftwarecoder]

Decomposed the teardown to find which step the console Apollo is actually reacting to. The premise in the issue body is wrong, and the correction matters for whether this is fixable.

The premise to correct

This issue says teardown "detaches its VDD" and that the console Apollo reacts to that. There is no seat VDD to detach.

Measured today with a Moonlight client connected to a seat (see #15): a seat's SudoVDA display is created but never becomes active, because the RDP indirect display already owns the session's display topology. The seat streams the RDP surface instead.

During this whole decomposition the count of active SudoVDA displays stayed at 1, and that 1 is the console Apollo's own display. It never changed.

What actually triggers it

Teardown runs: Apollo stop -> close ports -> destroy display -> disconnect session -> logoff. Performing those separately, with the console Apollo's log watched after each:

step	console Apollo	active SudoVDA
stop the seat's Apollo	no reaction (0 bytes)	1 -> 1
kill mstsc (session -> Disconnected)	reacted (1900 bytes, encoder rebuild)	1 -> 1
log the seat session off	reacted (1900 bytes, encoder rebuild)	1 -> 1

So a second Apollo starting or stopping is not the problem. The console Apollo is reacting to the RDP session's display appearing and disappearing.

That connects this issue to #15: because seats stream the RDP surface rather than a virtual display, seat session churn is display-topology churn, and any Apollo on the host sees it as a display change.

Caveats

The health check interfered in steps 2 and 3. After mstsc was killed it logged session 14 is Disconnected — reconnecting and started a new mstsc, so each of those steps contains both the action and MultiSeat's reconnect. Disconnect and reconnect cannot yet be told apart.

That confound does not apply to a real teardown: the seat is in TearingDown, which IsWorthChecking excludes, so no reconnect happens. All four full-teardown measurements produced exactly one 1900 ms-scale rebuild rather than two, which suggests disconnect and logoff collapse into a single reaction.

Method note for anyone reproducing: a first attempt stopped the MultiSeat service to keep the health check out of the way. That invalidates the run, because service shutdown calls TeardownAllAsync and performs the teardown before any step executes. Leave the service running and read its event log instead.

Timing, measured with a client actually connected to the console Apollo:

08:12:25.572  Starting async encoder teardown
08:12:25.679  Async encoder teardown complete
08:12:26.261  Creating encoder [hevc_nvenc]

689 ms, and it recovers on its own.

Where this leaves the issue

Probably not fixable on our side. Seats require RDP sessions, those sessions must eventually end, and a session ending is a legitimate Windows display change that any Apollo on the host will notice. There is no VDD detach to defer or reorder, which was the fix this issue implied.

Severity remains low: it only affects hosts running a standalone Apollo alongside MultiSeat, it does not compound with seat count (see the seat-to-seat isolation measurement above), and the stall is sub-second and self-recovering.

Leaving this open as a documented limitation rather than closing it, in case someone sees a way to make Apollo tolerate a display change it does not own.

[vibesoftwarecoder]

Two of this issue's own proposed directions are now done — the warning (direction 2) and the documentation correction. The stall itself is unchanged, so this stays open.

A bug found on the way, worth its own note

The warning needed a way to tell whether the standalone Apollo has a client. HostApolloInfo.Streaming already existed for exactly that, so I checked it before building on it.

It was wrong, and wrong in the common direction.

now                     08:05:42
apollo log last written 07:39:47    <- encoder created, never torn down
encode (pid 10988)      15.9% -> 15.8% -> 15.8%   sustained
serverinfo              state = SUNSHINE_SERVER_FREE, currentgame = 0

A client had been streaming the desktop for 26 minutes. serverinfo's state and currentgame describe a launched application, not a client session — so streaming the plain desktop, which is what a console Apollo is usually for, reports FREE for the entire session.

/api/host had therefore been telling the dashboard "not streaming" the whole time the host was streaming. That is a pre-existing bug independent of this issue.

Fixed in #50: Streaming is now per-process GPU video encode OR the serverinfo signal, read through the same WMI GPU engine counters GpuMonitor already uses. Per process, never the GPU total — RustDesk encodes too. Verified in both directions: False while idle, True during a live stream where serverinfo still insisted otherwise.

⛔ Built on the old signal, the warning this issue asked for would have been silently dead for desktop streaming.

The warning

SeatManager now logs before tearing a seat down when the standalone Apollo is streaming, naming the ~690 ms stall and that it recovers on its own. It runs before the lifecycle gate is acquired, so it adds no latency under the lock, and it can never block or fail a teardown — a seat that would not tear down because a status query timed out is a worse bug than the one being reported.

What has not changed

The stall. The decomposition above still stands: stopping a seat's Apollo causes no reaction at all, and ending the seat's RDP session is the topology change any Apollo on the host reacts to. A seat is an RDP session, so there is nothing to defer or reorder. Direction 1 has no room to work in.

CLAUDE.md's non-destructive coexistence claim now states the exception, and names session churn as the cause rather than a second Apollo — the intuitive guess, and this issue's original premise, both wrong.

Still unverified

That the warning emits during a real teardown, and stays quiet when nothing is streaming. The signal it reads is verified both ways; the emission is not — that needs seat churn, and the host has been streaming. I will follow up here once it is checked rather than leave it on reasoning.

[vibesoftwarecoder]

Verified on the reference host. I said I would follow up rather than leave the emission on reasoning, so:

The warning fires, and fires early

08:49:09.933  RDP session 8 created          <- provisioning
08:49:14.985  seat Apollo started
08:49:23.503  warning fired
08:49:24.661  Apollo: Creating encoder       <- 1.2s AFTER the warning
08:49:25.099  Session 8 logged off
08:49:25.100  seat torn down

Seat 51cb4fb7...: tearing down while the standalone Apollo (PID 10988, GamingDesktop)
is streaming. Ending this seat's RDP session changes the desktop topology...

Correct PID, correct hostname, 1.2 seconds ahead of the stall — which was the point of placing it before the lifecycle gate. Also verified silent in the other direction: a provision/teardown cycle with nothing streaming produced no warning at all.

This issue overstates the impact, and so did my warning

The rebuild took 266 ms, against the 690 ms recorded here on 2026-09-04. More to the point, the person actually streaming did not notice it.

The issue body calls it "a one-second freeze" and "a poor experience". On this evidence that is too strong. The warning has been reworded from "stall for about a second" to "hitch for a few hundred milliseconds", and CLAUDE.md now carries both measurements.

⚠️ One person's perception on one LAN is not proof it is always imperceptible — a busier GPU or a tighter client could feel it. But "a few hundred milliseconds, usually unnoticed" is what the evidence supports, and the severity assessment here should probably come down accordingly.

Provisioning is clean — the original observation holds

Under "What I did not establish" this issue notes provisioning appeared not to trigger a rebuild, on two samples. That holds. The RDP session was created at 08:49:09.933 with no encoder activity anywhere near it; the only rebuild in the window sits between the warning and the logoff.

I briefly read the log as showing a provisioning rebuild and was wrong — that came from eyeballing a log tail rather than correlating it against the service timeline. Correcting it here so the mistake does not outlive the check.

One thing unexplained

A second encoder rebuild at 08:49:31.996, seven seconds after teardown completed, with no MultiSeat activity anywhere near it. Could be the client, could be a delayed topology settle. Recorded rather than guessed at, in case it means something to someone later.

Still open: the stall itself is unchanged and remains unfixable here, for the reasons already established.