# Moonlight / Apollo auf VM302 — Analyse und Abbruch

**Datum:** 2026-07-20
**System:** VM302 (Windows 11 26100, NVIDIA A40, Kansas City, Proxmox-VM auf gpu1)
**Ergebnis:** Kopplung geloest, Bilduebertragung unbrauchbar, auf Nutzerwunsch abgebrochen

---

## Ausgangslage

Moonlight verweigerte die Kopplung mit "PIN failed", obwohl die PIN nachweislich korrekt war.
Beim PIN-Dialog erschien die Oberflaeche von **Apollo**.

## Befund 1 — Es laeuft Apollo, nicht Sunshine

```
C:\Program Files\Apollo      (16.07.2026 15:48)  <- LAEUFT
C:\Program Files\Sunshine    (16.07.2026 06:35)  <- Dienst gestoppt

PID 46664  C:\Program Files\Apollo\Sunshine.exe   Sitzung 1, SYSTEM
Ports 47984 / 47989 / 47990 / 48010  -> alle bei Apollo
```

**Apollo ist ein Fork von Sunshine** und behaelt den Binaernamen `Sunshine.exe` bei — das macht die
Verwechslung leicht.

> **Fehler in der Analyse:** Zunaechst wurde die Konfiguration unter `C:\Program Files\Sunshine\config\`
> ausgewertet. Die ist ungenutzt. Der Schluss "0 gekoppelte Geraete" war deshalb wertlos.
> **Regel:** Erst feststellen, welcher Prozess die Ports besitzt — dann dessen Konfiguration lesen.

## Befund 2 — Die PIN war nie das Problem

```
[2026-07-20 16:38:06] Warning: Pair attempt failed due to Out of order call to getservercert
```

Kein falscher PIN, sondern ein **haengender Kopplungszustand**: Der Client schickte einen
Kopplungsschritt, bevor der vorherige abgeschlossen war — typisch nach einem abgebrochenen Versuch.

**Loesung:** `Restart-Service ApolloService` raeumt den Zustand im Speicher auf.
Danach klappte die Kopplung im ersten Anlauf.

## Befund 3 — Apollo greift den falschen Bildschirm ab

| Anzeigegeraet | Aufloesung | Bemerkung |
|---|---|---|
| Microsoft Basic Display (QEMU-VGA) | 1280x800 @ **1 Hz** | <- das greift Apollo ab |
| SudoMaker Virtual Display | 640x360 @ 60 Hz | Apollos eigener Treiber |
| Microsoft Remote Display | 1600x1156 @ 66 Hz | RDP-Sitzung |
| **NVIDIA A40** | 1600x1156 @ 66 Hz | **an die RDP-Sitzung gebunden** |

Daraus folgen alle drei Symptome:

- **Kein NVENC** — `Failed to create encoder D3D11 device [0x887A0004]`. Apollo versucht NVENC zuerst,
  scheitert aber, weil der abgegriffene Bildschirm am Microsoft-Basisadapter haengt.
  Fallback: `libx264 [software]`.
- **Ruckeln** — 1 Hz Bildwiederholrate auf dem QEMU-Notfallbildschirm.
- **Mausversatz** — Client und Host arbeiten mit verschiedenen Rastern, absolute Mauskoordinaten
  werden falsch umgerechnet.

## Befund 4 — Die Anwendungen in Moonlight

`apps.json` definiert: `Desktop`, `Remote Desktop Manager`, `Claude Code`, `Hermes`, `Browser`, `PowerShell`.

**`Virtual Display` ist kein Eintrag daraus, sondern Apollos eingebauter Pseudo-Eintrag** — er legt einen
leeren Zusatzbildschirm an und zeigt sonst nichts.

| Gestartet | Ergebnis | Messwert |
|---|---|---|
| `Virtual Display` | schwarz | skip 100 %, 18 kbit/s — leerer Bildschirm |
| `Desktop` | Anmeldebildschirm sichtbar | 371 kbit/s, skip 76 % — echter Inhalt |
| `Desktop` + `always_use_virtual_display: true` | wieder schwarz | zurueckgesetzt |

Die Bitrate ist der schnellste Indikator: unter ~20 kbit/s bei 100 % uebersprungenen Bildbloecken
wird ein statisch schwarzes Bild uebertragen.

## Befund 5 — Der strukturelle Kern

Apollo laeuft als SYSTEM in **Sitzung 1 (Konsole) — dort ist niemand angemeldet.** Der Nutzer arbeitet
in Sitzung 4 ueber RDP. Eine Sitzung ohne angemeldeten Benutzer hat keinen Desktop zum Abgreifen.
Deshalb der Anmeldebildschirm.

**Falle:** Eine Anmeldung als derselbe Benutzer am Konsolen-Anmeldebildschirm wuerde wegen
`fSingleSessionPerUser=1` die bestehende RDP-Sitzung an die Konsole holen — der Nutzer fliegt aus RDP.

**Fuer einen Parallelbetrieb waere noetig:**
1. Ein **eigener Benutzer** fuer die Konsolensitzung (nicht derselbe wie fuer RDP)
2. Das virtuelle Display an den **A40** binden statt an den Basisadapter — erst dann greift NVENC

## Zurueckgenommene Behauptungen

- **"RDP und Moonlight schliessen sich gegenseitig aus."** Falsch. Der Parallelbetrieb ist ueber ein
  separates virtuelles Display ausdruecklich vorgesehen; Apollo hat dafuer `always_use_virtual_display`
  und `headless_mode`. Der Nutzer widersprach aus eigener Erfahrung und hatte recht.
- **"Apollo versucht NVENC gar nicht erst."** Falsch. Es versucht NVENC als erstes und scheitert.
  Die Logzeilen waren durch einen zu engen Filter uebersehen worden.
- **Leerlaufwerte als Dauerzustand.** Der Encoder-Test beim Dienststart sagt nichts ueber den
  Streaming-Betrieb aus, weil das virtuelle Display erst beim Verbindungsaufbau entsteht.

## Endzustand

- Apollo laeuft, **Kopplung bleibt erhalten**
- `always_use_virtual_display` zurueck auf `false`
- Debug-Protokollierung wieder aus
- Sicherung: `sunshine_state.json.bak-vor-vd`
- **RDP bleibt der Zugangsweg**
- Offen: `apps.json` verweist noch auf alte Sunshine-Pfade (`sunshine.ki1.it:47990`)

## Nuetzliche Befehle

```powershell
# Wer besitzt die Streaming-Ports?
Get-NetTCPConnection -LocalPort 47989 -State Listen |
  ForEach-Object { Get-Process -Id $_.OwningProcess }

# Encoder- und Bildschirmwahl im Betrieb
Get-Content "C:\Program Files\Apollo\config\sunshine.log" |
  Where-Object { $_ -match 'Found H.264|Capture size|Device Description|kb/s|skip:' }

# Debug-Protokollierung
Add-Content "C:\Program Files\Apollo\config\sunshine.conf" "`nmin_log_level = debug"
Restart-Service ApolloService
```