hermes-erkenntnisse/streaming/2026-07-20-Moonlight-Apollo-VM302.md
Code-Barby 99926aaf69 Doku 2026-07-20: Moonlight/Apollo-Analyse (abgebrochen) + Verbindungs-Wahrheit
- Apollo statt Sunshine: wer die Ports besitzt, bestimmt welche Konfiguration gilt
- PIN-Fehler war haengender Kopplungszustand, kein falscher PIN
- Kein NVENC weil QEMU-VGA statt A40 abgegriffen wird
- Tailscale laeuft != Tailscale wird benutzt
- Eigene Messfehler dokumentiert
2026-07-20 17:48:00 +02:00

124 lines
5.3 KiB
Markdown

# 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
```