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>

README.md

@@ -74,9 +74,26 @@ NICHT als emuliertes CD-ROM (`media=cdrom`), das kann keine SCSI-Kommandos.
    nur die Benennung. **Jellyfin/Emby**: Server-URL + API-Key eintragen,
    dann stößt Rippy nach jedem fertigen Rip sofort einen Bibliotheks-Scan
    an — Disc rein, Film erscheint im Server.
-5. **4K-UHD**: braucht ein LibreDrive-fähiges Laufwerk (MakeMKV-Forum:
-   „Ultimate UHD Drives Flashing Guide"). Normale BD/DVD gehen mit jedem
-   Laufwerk. ⚠️ UHD-Rohdaten sind bis 100 GB groß — wenn die Platte der
+5. **4K-UHD**: braucht **zwei** Dinge — ein LibreDrive-fähiges Laufwerk
+   (MakeMKV-Forum: „Ultimate UHD Drives Flashing Guide") **und** einen
+   passenden Disc-Schlüssel. Normale BD/DVD gehen mit jedem Laufwerk und
+   ohne Schlüssel-Datei.
+   **Der Schlüssel ist heute die eigentliche Hürde.** Am 25.07.2026 auf
+   der Rippy-VM gemessen (Akira UHD, MKB v76, Pressung Dezember 2020):
+   Laufwerk und MakeMKV waren in Ordnung — „Using LibreDrive mode
+   (v06.3)", die Disc wurde gelesen — und trotzdem kam „The volume key is
+   unknown for this disc". MakeMKV versucht dabei **gar nicht mehr**,
+   online einen Schlüssel zu holen, und die früher genutzten
+   Schlüssel-Server (`hkdata.fairuse.org`, `hkdata.crabdance.com`) lösen
+   weltweit nicht mehr auf. Ein MakeMKV-Update ändert daran nichts.
+   Der einzige Weg, der heute funktioniert, ist eine Datei **`KEYDB.cfg`**
+   (GROSS geschrieben — Linux unterscheidet Groß- und Kleinschreibung) im
+   MakeMKV-Datenverzeichnis. Die legst du unter **Einstellungen → System**
+   ab (siehe unten).
+   ⚠️ **Rippy liefert keine Schlüssel mit, lädt keine herunter und
+   verteilt keine.** Rippy stellt nur den Platz für eine Datei bereit, die
+   du selbst mitbringst, und zeigt dir ehrlich an, was dort liegt.
+   ⚠️ UHD-Rohdaten sind bis 100 GB groß — wenn die Platte der
    Rippy-Maschine dafür zu klein ist, lege das **Arbeitsverzeichnis**
    (Einstellungen → Verarbeitung) auf eine eingehängte Freigabe, z. B.
    `/app/media/nas-arbeit`. Rippy bricht sonst VOR dem Rip mit einer
@@ -106,7 +123,7 @@ fehlgeschlagen, abgebrochen) und erkennt den Dienst an der URL selbst:
 | ntfy (Handy-Push) | `https://ntfy.sh/mein-geheimes-thema` | Roh-Text + Titel |
 | Eigenes (HA, n8n, …) | beliebige HTTPS-URL | `{"title","message","level"}` |
 
-## System, MakeMKV-Beta-Key & Updates
+## System, MakeMKV-Beta-Key, Disc-Schlüssel & Updates
 
 **Einstellungen → System** zeigt die Werkzeug-Versionen jedes Workers
 (MakeMKV, HandBrake), den Key-Status und den freien Speicherplatz. Der
@@ -114,11 +131,37 @@ MakeMKV-Beta-Key (wechselt ~monatlich, Forum-Thread t=1053) wird hier im
 UI eingetragen und gilt ab dem **nächsten Rip** — ohne Rebuild, ohne
 Neustart; er schlägt den Key aus der `.env`.
 
+**Disc-Schlüssel (`KEYDB.cfg`)** — im selben Tab, nur für 4K-UHD nötig:
+
+- **Status**: Rippy zeigt, ob eine `KEYDB.cfg` im MakeMKV-Datenverzeichnis
+  liegt, mit Pfad, Größe, Anzahl der Disc-Einträge und Änderungsdatum.
+- **Hochladen**: Knopf „KEYDB.cfg hochladen", dann deine eigene Datei im
+  Datei-Dialog auswählen — mehr ist nicht zu tun. Rippy prüft den Inhalt
+  auf Plausibilität und lehnt Unsinn (leere Datei, versehentlich geladene
+  HTML-Fehlerseite) mit einer deutschen Klartext-Meldung ab, statt ihn
+  stillschweigend zu speichern.
+- **Entfernen**: ein Knopf, die Datei ist wieder weg.
+- **AACS-Dumps herunterladen**: MakeMKV legt bei jeder unbekannten Disc
+  selbst einen Dump ab. Genau den braucht man, wenn man im MakeMKV-Forum
+  um den Schlüssel für eine neue Pressung bittet — hier holst du ihn dir
+  aus dem Container, ohne SSH.
+
+Der Beta-Key ist die **Lizenz für die Software**; die `KEYDB.cfg` sind
+**Disc-Schlüssel** — zwei völlig verschiedene Dinge. **Rippy liefert und
+lädt keine Disc-Schlüssel**, es hält nur ein persistentes Verzeichnis
+dafür bereit (`MAKEMKV_DATA_HOST`, siehe Tabelle unten) — rebuild-fest,
+damit deine Datei einen `docker compose build` überlebt.
+
 **Updates:** „Auf Updates prüfen" vergleicht mit makemkv.com und den
 offiziellen HandBrake-Releases (12 h gecacht). MakeMKV-Update ohne
 Code-Änderung: `MAKEMKV_VERSION=x.y.z` in die `.env`, dann
-`docker compose build worker && docker compose up -d worker` — neue
-Versionen bringen auch die neueste Disc-Schlüssel-Datenbank mit.
+`docker compose build worker && docker compose up -d worker`.
+⚠️ **Richtigstellung (25.07.2026):** Hier stand früher, neue MakeMKV-
+Versionen brächten „auch die neueste Disc-Schlüssel-Datenbank mit". Das
+ist widerlegt — auf der VM nachgemessen: MakeMKV holt für eine unbekannte
+UHD-Disc keinen Schlüssel mehr, weder mitgeliefert noch aus dem Netz. Ein
+Update lohnt für Programmfehler und neue Laufwerke, hilft aber NICHT
+gegen „The volume key is unknown". Dafür brauchst du die `KEYDB.cfg`.
 HandBrake kommt im Docker-Worker bewusst aus Debian (stabil, hinkt der
 offiziellen Version hinterher); der native Windows-Worker nutzt die
 aktuelle Version direkt.
@@ -153,6 +196,7 @@ bleibt All-in-one.
 | `THETVDB_API_KEY` | optional | Serien-Fallback |
 | `MAKEMKV_APP_KEY` | optional | MakeMKV-Beta-Key (Forum); DVDs gehen ohne — bequemer: im UI unter Einstellungen → System pflegen |
 | `MAKEMKV_URL_BASE` | optional | alternative Download-Quelle für den Image-Build |
+| `MAKEMKV_DATA_HOST` | optional | Host-Verzeichnis für MakeMKVs Daten (Default `/srv/rippy/makemkv`) — hier liegen deine `KEYDB.cfg` und die AACS-Dumps; persistent, überlebt jeden Rebuild |
 | `OPTICAL_SR` | je Host | Host-Pfad des CD-ROM-Knotens (Default `/dev/sr0`) — siehe „Laufwerk anpassen" |
 | `OPTICAL_SG` | je Host | Host-Pfad des sg-Knotens des Laufwerks (Default `/dev/sg1`; oft `/dev/sg0`) |
 | `POSTGRES_PASSWORD` | optional | DB-Passwort (Default `rippy`) — für exponierte Umgebungen ein starkes Passwort setzen |
@@ -181,6 +225,11 @@ Voraussetzungen auf dem Ziel-Host:
    ```
    (reboot-fest als systemd-`.mount`-Unit persistieren.) Braucht einen klassischen
    Linux-Docker-Host mit `SYS_ADMIN` — nicht Docker-Desktop/rootless/Podman.
+4. MakeMKV-Datenverzeichnis anlegen: `mkdir -p /srv/rippy/makemkv` (oder
+   eigenen Pfad über `MAKEMKV_DATA_HOST` in der `.env`). Dort liegen
+   MakeMKVs Programmzustand, die AACS-Dumps und — falls du 4K-UHD rippst —
+   deine eigene `KEYDB.cfg`. Das Verzeichnis gehört dem Host, damit ein
+   `docker compose build` deine Datei nicht wegwirft.
 
 Dann wie im Schnellstart: klonen, `.env` füllen, `docker compose up -d
 --build`, `http://<host>` öffnen — der Einrichtungs-Assistent führt durch