feat(uhd): KEYDB.cfg-Unterstuetzung - MakeMKVs Schluessel-Kanal liefert nichts mehr

4K-UHD scheiterte an "The volume key is unknown for this disc". Am 25.07.2026
im Worker-Container nachgemessen: Laufwerk und MakeMKV sind in Ordnung
(LibreDrive v06.3 / Meldung 1011, Disc wird gelesen, AACS-Dump geschrieben) -
MakeMKV versucht gar nicht erst, online einen Schluessel zu holen. Belege:
_private_data.tar enthaelt nur die Index-Datei und KEINE hkd_*.bin; auch mit
geloeschter update.conf (Meldung 5074 belegt den Web-Kontakt) und mit
app_UpdateEnable="1" kam keiner; hkdata.fairuse.org und hkdata.crabdance.com
loesen weltweit nicht mehr auf (NXDOMAIN gegen Fritz!Box, 8.8.8.8, 1.1.1.1).
Betroffen war Akira UHD (MKB v76, Pressung Dez. 2020) - also gerade KEINE
Neuerscheinung. Der bisherige Fehlertext ("Disc neuer als die
Schluessel-Datenbank, mit einem der naechsten Updates rippbar") war falsch.

Einziger heute funktionierender Weg ist eine vom Nutzer selbst mitgebrachte
KEYDB.cfg. Rippy liefert KEINE Schluessel mit, laedt keine herunter und
verteilt keine - es stellt nur den Platz bereit und zeigt an, was dort liegt.

- Datenverzeichnis persistent gemountet (MAKEMKV_DATA_HOST, Default
  /srv/rippy/makemkv): KEYDB.cfg und AACS-Dumps ueberleben jeden Rebuild.
  Vorher loeschte jeder "up -d --build" beides - inklusive des Dumps, auf den
  die Fehlermeldung selbst verwies.
- entrypoint.sh und tasks.py schreiben settings.conf ergaenzend statt
  zerstoerend. Der entrypoint bricht bei nicht beschreibbarem Verzeichnis
  nicht mehr ab - mit "restart: unless-stopped" waere das ein Crashloop
  gewesen, in dem auch reines DVD-Rippen tot ist.
- Neues Zwillings-Modul makemkv_daten.py (docker/api + docker/worker,
  byteweise identisch; test_zwillinge_sind_byteweise_identisch wacht darueber
  und wurde durch absichtliches Verstellen als wirksam nachgewiesen).
- API: GET/POST/DELETE /system/keydb, GET /system/aacs-dumps(/{dateiname}).
  JSON-Body statt Multipart - python-multipart ist bewusst nicht installiert
  und wuerde die API beim Import toeten. nginx client_max_body_size 64m,
  sonst scheitert der Upload mit 413, bevor die API ihn sieht.
- UI (Einstellungen -> System): Status, Hochladen per Datei-Dialog, Entfernen,
  Dump-Download, KEYDB-Plakette je Worker (nur wo das Verzeichnis wirklich
  gemountet ist - ein Remote-Transcode-Worker truege sonst eine Warnung,
  die ihn nichts angeht).
- parse_msg() + log_cb: MakeMKV-Meldungen landen im Rippy-Log (gedrosselt:
  Code 1003 raus, keine Wiederholungen, max. 40 je Rip). Nebenbei behoben:
  der alte Parser (split(",", 4)[3]) schnitt jede Meldung am ersten Komma ab.
- Fuenf Stellen richtiggestellt, die behaupteten, MakeMKV-Updates braechten
  die neueste Disc-Schluessel-Datenbank mit (UI, Anleitung, README,
  Worker-Dockerfile, makemkv_key.py).

NICHT bewiesen: ein erfolgreicher UHD-Rip - es lag keine KEYDB.cfg mit dem
Akira-Schluessel vor. Belegt sind der Befund und die neue Mechanik. So steht
es auch im SAVEPOINT und in der ROADMAP.

Quellen (AGENTS Regel D):
- Datenverzeichnis + Dateiname GROSS/case-sensitiv:
  https://forum.makemkv.com/forum/viewtopic.php?t=30636
- hkd_*.bin in _private_data.tar:
  https://forum.makemkv.com/forum/viewtopic.php?t=32675
- headless settings.conf / app_UpdateEnable:
  https://forum.makemkv.com/forum/viewtopic.php?t=20364
- KEYDB.cfg-Zeilenformat (libaacs):
  https://github.com/ShiftMediaProject/libaacs/blob/master/KEYDB.cfg
- MSG-/PRGV-Format: https://www.makemkv.com/developers/usage.txt

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

ROADMAP.md

@@ -414,6 +414,65 @@ irrelevant und kann komplett raus."
 
 ---
 
+## Etappe 17 (25.07.2026): 4K-UHD-Schlüssel (KEYDB.cfg)
+
+**Quelle:** Messung am 25.07. live auf der Rippy-VM im Worker-Container.
+Eine 4K-UHD (Akira, MKB v76, Pressung Dezember 2020) scheitert an „The
+volume key is unknown for this disc" — obwohl makemkvcon „Using LibreDrive
+mode (v06.3)" und „Using direct disc access mode" meldet, die Disc liest
+und den AACS-Dump ablegt (Meldung 3332). Das Debug-Log geht ohne einen
+einzigen Netz-Versuch von „Loaded content hash table" direkt auf den
+Fehler; `_private_data.tar` enthielt nur die Index-Datei und keine einzige
+`hkd_*.bin`; auch mit gelöschter `update.conf` (Meldung 5074 belegt den
+Web-Kontakt) und `app_UpdateEnable = "1"` kam kein Schlüssel; die
+Forum-Schlüssel-Server `hkdata.fairuse.org` und `hkdata.crabdance.com`
+lösen weltweit nicht mehr auf. **Fazit: Ein MakeMKV-Update löst das
+nicht** (das behauptete v3.3 — dort richtiggestellt). Der einzige heute
+funktionierende Weg ist eine `KEYDB.cfg` im MakeMKV-Datenverzeichnis.
+
+**Gebaut:**
+- [x] **Persistentes Datenverzeichnis**: `${MAKEMKV_DATA_HOST:-/srv/rippy/makemkv}`
+      vom Host gemountet — Worker `/root/.MakeMKV`, API `/app/makemkv-data`,
+      beide mit `MAKEMKV_DATA_DIR`. `KEYDB.cfg` und AACS-Dumps überleben
+      jeden Rebuild. `.env.example` erklärt die Variable.
+- [x] **entrypoint.sh entschärft**: `settings.conf` wird ergänzt statt
+      überschrieben (der Beta-Key hatte sonst alles andere gelöscht),
+      `app_UpdateEnable = "1"` gesetzt.
+- [x] **Zwillings-Modul `makemkv_daten.py`** (identisch in `docker/api/`
+      und `docker/worker/`) als einzige Wahrheit über das Verzeichnis:
+      Status lesen, Inhalt prüfen, atomar schreiben, löschen, Dumps
+      auflisten — alles reine Funktionen, damit die Ampel sie ohne
+      Postgres/Redis testen kann.
+- [x] **API**: `GET/POST/DELETE /system/keydb`, `GET /system/aacs-dumps`
+      und `GET /system/aacs-dumps/{dateiname}`. Der Inhalt kommt bewusst
+      als JSON-Body — es gibt kein `python-multipart`, ein Endpunkt mit
+      `UploadFile`/`File()` würde die API beim Import töten.
+- [x] **UI (Einstellungen → System)**: Status der `KEYDB.cfg` (Pfad,
+      Größe, Anzahl Disc-Einträge, Datum), Inhalt einfügen, entfernen,
+      AACS-Dumps herunterladen — ohne SSH auf die VM.
+- [x] **MakeMKV redet endlich**: `parse_msg()` in `ripping.py` + Log-Callback
+      in `tasks.py` schreiben MakeMKV-Meldungen ins Rippy-Log (gedrosselt:
+      Code 1003 raus, keine Wiederholungen, max. 40 je Rip). UHD-Fehlertext
+      ehrlich neu geschrieben; `caps.py` meldet `keydb: ja | nein | unbekannt`.
+- [x] **Doku nachgezogen**: README (UHD-Voraussetzungen, System-Panel,
+      `MAKEMKV_DATA_HOST`, Bereitstellung), SAVEPOINT v3.10 inkl.
+      Richtigstellung von v3.3, KONZEPT §8 + §10.
+
+**Offen aus dieser Runde:**
+- [ ] **Der Nachweis mit einer echten `KEYDB.cfg` steht aus.** Zum
+      Zeitpunkt der Änderung lag keine Datei vor, die den Akira-Schlüssel
+      enthält — belegt sind der Befund und die Mechanik, NICHT ein
+      erfolgreicher UHD-Rip.
+- [ ] Damit bleibt auch der volle Transcode-E2E an einer UHD weiter offen
+      (siehe SAVEPOINT v3.7) — an normalen BD/DVD ist die Kette bewiesen.
+
+**Ausdrücklich nicht gebaut (und wird es auch nicht):** Rippy liefert
+keine Disc-Schlüssel mit, lädt keine herunter und verteilt keine. Es
+stellt nur den Platz für eine Datei bereit, die der Nutzer selbst
+mitbringt, und zeigt ehrlich an, was dort liegt.
+
+---
+
 ## Ideen-Katalog (Rest) — bewusst offen
 
 1. **Design 2.0** — an Gemini übergeben (24.07.2026). Vollständiges