hermes-erkenntnisse/streaming/2026-07-20-Moonlight-Apollo-VM302.md

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

# 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