Leopoldadmin/hms-mediaengine
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity
Files
v1.0.0-installers
hms-mediaengine/_entwicklung/STATUS.md
T
HMS MediaEngine Agent 362e089be0 AUFGERAUMT: Root auf 10 sichtbare Elemente reduziert 
Der Nutzer hat recht: Der Ordner war voller Entwicklungs-Muell.
Jetzt ist sauber getrennt:

ROOT (was der Nutzer sieht und braucht):
- run.py                     = das Programm
- hms_app/                   = der Anwendungscode
- HMS MediaEngine.app        = macOS Doppelklick-Starter
- HMS-Start.vbs              = Windows Doppelklick-Starter
- HMS-Install.vbs             = Windows Erst-Installation
- HMS-Mac-Install.command     = macOS Homebrew-Installation
- HMS-Portable-Install.command = macOS Portable-Installation (16GB-Fix)
- installer_gui.py           = grafischer Installer
- launcher.pyw + launcher_core.py = interne Start-Logik
- LIESMICH.txt               = 10-Zeilen-Kurzanleitung
- .gitignore

_entwicklung/ (alles andere, NICHT benoetigt):
- packages/ apps/ native/ plugins/ tools/ schemas/ tests/ docs/
  build/ fixture_profiles/
- PLAN.md STATUS.md ERRORS.md TEST_REPORT.md CHANGELOG.md README.md
- pyproject.toml uv.lock setup_*.sh/ps1 make_mac_app.py

Diese Trennung gilt ab sofort fuer alle Commits. Der Nutzer kann
_entwicklung/ loeschen wenn er Platz braucht - die App laeuft ohne.

Verifiziert: App startet nach Aufraeumen unveraendert (Health 200).
2026-09-11 23:44:06 +02:00

8.2 KiB
Raw Permalink Blame History

STATUS

Stand: 2026-09-11

Aktuelle Phase

Phase 1 – Fundament und Netzwerkbasis unter der Build-first-Strategie (ADR-0008): Die Phasen 1–5 werden plattformneutral vollständig gebaut; Gate 0 und alle renderer-nahen Abnahmen werden gesammelt in einem späteren Windows-Durchlauf validiert. Auftraggeber-Freigabe für die Reihenfolgeabweichung vom 2026-09-11, dokumentiert in ADR-0008 gemäß PLAN.md §1.

Letzter grüner Commit

  • siehe git log und TEST_REPORT.md – jede Etappe endet mit grünem pytest und Ruff und wird sofort nach Forgejo gepusht.

Bestandene Gates

  • keine; Gate 0 bleibt offen bis zum Windows-Hardware-Durchlauf (Testplan in ADR-0008)

Arbeitsweise (ADR-0008)

  • Build-first: plattformneutral fertig bauen, Hardware-Validierung gesammelt am Ende (Windows-Durchlauf).
  • Kein Gate wird als grün gemeldet, solange der Windows-Durchlauf offen ist.
  • Renderer-Nähe ausschließlich über den Backend-Vertrag (§12.6); Korrekturen bleiben lokal im Adapter.

Laufende Arbeit

Phase 0 (abgeschlossen, soweit ohne Hardware möglich):

  • Repository, Pflichtdokumente, ADRs 0001–0003
  • GStreamer-Pin 1.28.6, Kernpakete, Control Core, Renderer-Spike
  • Beispielplugins (Passthrough, Gaussian Blur mit 3 AQ-Varianten), Tools
  • 121 Unit-/Integrationstests grün, Ruff grün (Belege: TEST_REPORT.md)

Phase 1 (plattformneutral abgeschlossen, ADR-0008):

  • IPC-Verbindung Control Core ↔ Renderer: Handshake (hello/welcome), vollständiger Snapshot nach Verbindung, Deltas mit monotoner Revision, Command-Acks idempotent über message_id, Heartbeat 500 ms in beide Richtungen, Re-Sync nach Reconnect, ausschließlich Loopback (§6.2)
  • SQLite-Persistenz (WAL, Migrationen mit Backup, Integritätscheck, Projekt-/Einstellungs-/Plugin-Status-CRUD, §24)
  • Launcher/Supervisor: echte Kindprozesse, portable Umgebung, freie Portwahl, kontrolliertes Beenden (terminate→kill) mit Recovery- Markierung, Restart-Policy mit Crashloop-Erkennung (§6.1A, §26.2, §26.4)
  • Cluster-Nachrichtenhülle: Pflichtfelder, Sequenzen, Revisionen, Trace-ID, Idempotenz-Tracker mit vorwärts-only-Statuskette (§6.5)
  • Node-Registry: online/degraded/stale/offline über Schwellen, UI-Kategorien discovered/paired/unknown/incompatible/offline, Doppel-Node-ID-Fehler, IP-Wechsel erhält node_id (§6.3, §6.5)
  • Paarung: kurzlebige PIN (TTL 120 s, Versuchslimit), sichtbarer Fingerprint, Token nur als Hash mit Scopes read/control/content_sync/ admin, Ablauf und sofortiger Widerruf (§6.3, §27.1, ADR-0010)
  • Discovery-Modell: mDNS-Service _hmsmedia._tcp.local. mit TXT ohne Secrets, Capability-Digest, persistente manuelle Fallback-Liste (ADR-0009)
  • Node-Identität + Rollen in der App-Verkabelung: Control Core lädt persistente node_id (Launcher/Produktion) bzw. Dev-ephemeral, Registry registriert die eigene Node, Endpunkte /system/identity und /cluster/nodes nach UI-Kategorien (§3.6, §6.3, §27.1)
  • mDNS-Echtnetz-Betrieb mit zeroconf auf Zielsystemen (Modell fertig; Multicast-Test gehört zu Gate 1, ADR-0009)

Phase 2 (im Bau):

  • Domänenmodell: Project/Composition/Layer/Source/EffectInstance/ MediaAsset/OutputSurface/PresetScene mit Validierungen (§10.1)
  • Medien-Engine: PlaybackController (Play/Pause/Stop/Retrigger, Loop/ Once/Ping-Pong, In/Out, ±4x Speed, Ende-Ereignis), PreloadSlot für atomaren Clipwechsel, MediaLibrary mit Duplikaterkennung und Bank- Slots, ContentManifest mit SHA-256 und Chunk-Hashes (§12, §13, §6.4)
  • Project-State-Store mit monotonen Revisionen, Snapshot/Delta (neu/geändert/gelöscht), Szenenaktivierung als Zielzustand, Projekt-/Livezustand getrennt (§6.4, §24.2, §18.1)
  • Servergruppen + Zielrouting: All/Node/Output/Group, Zielregeln selected/tag_query/all, Commit-Vorschau (§6.3, §10.1, §17.5)
  • Clock-Offset-/Drift-Messung: RTT-Min-Filter (≤2× Min), Drift erst ab 1 s Fenster, Showzeit→lokale-Zeit-Abbildung (§6.4)
  • zeitgestempelte Preset-Aktivierung: Vorlauf 200 ms, Arm/Execute/ Ack, FAILED bei fehlender Arm-Bestätigung (§6.5)
  • Renderer-Anbindung: RemoteStateMirror (Renderer) + RendererStateLink (Control Core) über IPC; Pflicht-Snapshot nach (Re-)Connect, danach Deltas (neu/geändert/gelöscht), Deltas vor Snapshot abgelehnt, Duplikate idempotent; End-to-End-Integrationstest über echtes TCP-Loopback ohne Mocks (§6.2, §6.4)

Phase 3 (plattformneutral abgeschlossen, ADR-0008):

  • Plugin-Lifecycle-Manager: Zustandsgraph discovered→validated→ installed→enabled→compiled→active mit quarantined/incompatible, Show-Lock-Schutz (§14.5, §14.6, §26.3), Versionsupdate-Zyklus
  • Alle 10 Pflicht-Generatoren (§15.1): solid, gradient, checker_grid, stripes_chaser, noise_clouds, plasma, wave_bars, shapes, drops_ripples, starfield – je HLSL/GLSL/GLES + AQ-Varianten
  • Alle 14 Pflicht-Filter (§15.2): transform2d, color_adjust, gradient_map, blur_sharpen (separabel 2-Pass), pixelate_quantize, mirror_tile, kaleidoscope, wave_displace, rgb_split, glow_bloom, edge_emboss, vignette, strobe_pulse (Safety ≤2 Hz), feedback_trails
  • SDK-Dokumentation: 7 Dateien in docs/plugin-sdk/ (Manifest-Referenz, Shader-Vertrag, DMX-Slots, Lifecycle, AQ, Beispiel-Walkthrough)
  • Golden-Image-Tests-Infrastruktur (Ausführung auf Windows-Hardware)
  • Backend-Adapter: Shader-Loader für D3D11/GL/GLES (Rust, ADR-0004)

Phase 4 (im Bau):

  • Fixture-Engine Master32: 32-Kanal-Dekodierung mit 16-Bit-Werten, Blackout/Freeze, Flanken-Trigger, reservierte Kanäle neutral (§16.3)
  • Fixture-Engine Layer64: 64-Kanal-Dekodierung mit modusabhängigem Source-Block, Load/Commit-Semantik mit pending selection, Pickup/Takeover, Retrigger, FX1/FX2 P1–P8 (§16.4, §16.5)
  • Speed-Mapping §16.6: Mittelpunkt=Pause, ±4×, definierter 1×-Wert 40960, monoton; ursprünglicher Implementierungsfehler korrigiert
  • UniversePlan: kollisionsfreie Bereiche je Node, Überschneidung = Blocker, Preflight (§16.2)
  • Fixture-Verkabelung: Fixture-Engine an Art-Net-Receiver und Parameter-Engine anbinden (Layer-Komposition je Universe)
  • Patchverwaltung + Patch-Export mit Node-ID/Universe (§16.2)
  • Kanalliste-Export (CSV existiert; PDF/GDTF folgt in Phase 4 Rest)

Phase 5 (im Bau):

  • ADR-0006: React mit Vite im statischen SPA-Modus
  • Workspace-Layout §17.2: Statusleiste, Werkzeugleiste, Layer-Tabelle, Inspector, rechte Seitenleiste, Fußleiste mit Setup/Live-Lock
  • Layer-Tabelle §17.3: alle 10 Pflichtspalten, 7 Zustände mit Glyph+Farbe+Text, Pfeiltasten-Navigation, echter parameter.set
  • Inspector §17.4: 7 Tabs, Zahlenfelder mit Tippen/Ziehen/Tastatur
  • Design-Tokens §17.6: alle als CSS-Variablen
  • WebSocket: Snapshot→Delta, Reconnect mit Backoff
  • Projekt-/Layer-API im Control Core (echte Daten statt Demo-Seed)
  • Media-Browser, DMX-Patch-Seite, Presets, Diagnostics
  • Playwright-Referenz-Screenshots (§17.10)
  • Auth für LAN-Zugriff (§17.9)

Nächste drei Aufgaben

  1. Windows-Testdurchlauf vorbereiten: Checkliste ADR-0008 auf Zielsystem
  2. SBOM und Lizenzverzeichnis erzeugen (§30.1)
  3. Playwright-Referenz-Screenshots für visuelle Abnahme (§17.10)

Ausstehende Hardware-Validierung (ADR-0008 Testplan)

Nur auf echtem Windows mit GPU messbar; nichts davon gilt als erledigt:

  • D3D11-Hardwaredecode aktiv; D3D11Memory durchgängig ohne CPU-Rundweg
  • Framezeit p50/p95/p99; DMX → sichtbarer Frame p95 ≤ 2 Frames
  • Adaptive-Quality-Wechsel ohne Stall; Golden Images; Shader-Compile auf GPU
  • Portable Onefolder-Ausgabe auf sauberem Rechner (§29.6)
  • Rust-Renderkern-Kompilierung und GStreamer-Plugin-Bindung (ADR-0004)

Bekannte Blocker

  • Windows-Referenzhardware fehlt in der Entwicklungsumgebung (Linux-Container, CPU-only) – Kernblocker, durch ADR-0008 gemanagt.
  • Rust-Toolchain (cargo) fehlt im Container: Rust-Quellcode wird entwickelt, das Kompilierungsgate erfolgt im Windows-Durchlauf.
  • pnpm fehlt im Container: wird für Phase 5 über Node-Corepack aktiviert (kein Installationsblocker).
Reference in New Issue View Git Blame Copy Permalink