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>

SAVEPOINT.md

@@ -1,6 +1,73 @@
 # SAVEPOINT — Rippy
 
-## Aktueller Stand: v3.9 — Windows-Installer als echte .exe (Icon, kein Konsolenfenster) (24.07.2026)
+## Aktueller Stand: v3.10 — 4K-UHD: KEYDB.cfg statt Warten auf MakeMKV (25.07.2026)
+
+- **Der Befund (am 25.07. live auf der VM im Worker-Container
+  nachgemessen — kein Verdacht, alles belegt):** Eine 4K-UHD (Akira,
+  MKB v76, Pressung Dezember 2020) scheitert mit „The volume key is
+  unknown for this disc". **Laufwerk und MakeMKV sind dabei in Ordnung:**
+  makemkvcon meldet „Using LibreDrive mode (v06.3)" und „Using direct
+  disc access mode", liest die Disc und legt den AACS-Dump ab
+  (Meldung 3332). Der Fehler liegt also NICHT an der Hardware.
+- **Die echte Ursache — MakeMKV fragt gar nicht erst:** Das Debug-Log
+  geht ohne einen einzigen Netz-Versuch von „Loaded content hash table"
+  direkt auf „The volume key is unknown". **Beweise:**
+  `/root/.MakeMKV/_private_data.tar` enthielt nur die Index-Datei und
+  KEINE einzige `hkd_*.bin` — es wurde also nie ein Schlüssel geladen.
+  Auch mit erzwungener frischer Prüfung (`update.conf` gelöscht,
+  Meldung 5074 belegt den Web-Kontakt) und mit `app_UpdateEnable = "1"`
+  kam keiner. Und die im MakeMKV-Forum dokumentierten Schlüssel-Server
+  `hkdata.fairuse.org` und `hkdata.crabdance.com` lösen weltweit nicht
+  mehr auf (NXDOMAIN gegen Fritz!Box, 8.8.8.8 und 1.1.1.1).
+- **Richtigstellung zu v3.3 (weiter unten korrigiert):** Dort stand, die
+  Ursache sei „Disc neuer als MakeMKVs Schlüssel-DB" und ein
+  MakeMKV-Update werde das lösen. Das ist widerlegt — es gibt keine
+  nachladbare Schlüssel-Datenbank mehr. **Warten auf ein MakeMKV-Update
+  hilft bei diesem Fehler nicht.**
+- **Der einzige Weg, der heute funktioniert: `KEYDB.cfg`** — GROSS
+  geschrieben (unter Linux case-sensitiv) im MakeMKV-Datenverzeichnis.
+  Rippy macht diesen Weg jetzt begehbar, statt auf MakeMKV zu warten.
+- **Gebaut — persistentes Datenverzeichnis:** `docker-compose.yml` mountet
+  `${MAKEMKV_DATA_HOST:-/srv/rippy/makemkv}` vom Host — im Worker auf
+  `/root/.MakeMKV`, in der API auf `/app/makemkv-data`; beide Container
+  bekommen `MAKEMKV_DATA_DIR`. Damit überleben `KEYDB.cfg` und die
+  AACS-Dumps jeden Rebuild. `entrypoint.sh` schreibt `settings.conf`
+  jetzt ergänzend statt zerstörend (sonst hätte der Beta-Key den Rest
+  überbügelt) und setzt `app_UpdateEnable = "1"`.
+- **Gebaut — eine einzige Wahrheit über das Verzeichnis:** neues
+  Zwillings-Modul `makemkv_daten.py` (identisch in `docker/api/` und
+  `docker/worker/`) mit reinen Helfern — Status lesen, Inhalt prüfen,
+  atomar schreiben, löschen, AACS-Dumps auflisten. Nur reine Funktionen,
+  damit die Ampel sie ohne Postgres/Redis testen kann.
+- **Gebaut — Bedienung im UI:** Einstellungen → System zeigt den
+  `KEYDB.cfg`-Status (Pfad, Größe, Anzahl Disc-Einträge, Datum), nimmt die
+  Datei über einen ganz normalen Datei-Dialog entgegen (der Browser liest
+  sie und schickt den Text als JSON — serverseitig bewusst KEIN
+  Multipart-Upload, es gibt kein `python-multipart`, das würde die API
+  beim Import töten), lehnt
+  unplausiblen Inhalt mit deutschem Klartext ab, kann die Datei wieder
+  entfernen und die AACS-Dumps zum Download anbieten.
+- **Gebaut — man sieht endlich, was MakeMKV sagt:** `parse_msg()` in
+  `ripping.py` plus Log-Callback in `tasks.py` schreiben MakeMKV-Meldungen
+  ins Rippy-Log (gedrosselt: Code 1003 raus, keine Wiederholungen, max. 40
+  je Rip). Der UHD-Fehlertext ist ehrlich neu geschrieben. `caps.py`
+  meldet zusätzlich `keydb: ja | nein | unbekannt` je Worker.
+- **Abgrenzung, die überall durchscheint:** **Rippy liefert KEINE
+  Schlüssel mit, lädt keine herunter und verteilt keine.** Rippy stellt
+  nur den Platz für eine Datei bereit, die der Nutzer selbst mitbringt,
+  und zeigt ehrlich an, was dort liegt. Genau die Grenze zieht schon
+  `docker/api/makemkv_key.py` (Zeile 14) für den Beta-Key: das ist die
+  Software-LIZENZ, nicht das Entschlüsseln oder Verteilen von
+  Disc-Schlüsseln.
+- **⚠️ NOCH NICHT end-to-end bewiesen — ehrlich gesagt:** Zum Zeitpunkt
+  dieser Änderung lag KEINE `KEYDB.cfg` vor, die den Akira-Schlüssel
+  enthält. Belegt sind der Befund oben und die neue Mechanik (Mount,
+  Modul, Endpunkte, UI) — **nicht** ein erfolgreicher UHD-Rip. Der
+  Nachweis steht aus und braucht eine echte Schlüssel-Datei.
+
+---
+
+## Vorheriger Stand: v3.9 — Windows-Installer als echte .exe (Icon, kein Konsolenfenster) (24.07.2026)
 
 - **RippyWorkerSetup.exe** ersetzt den .vbs/.bat-Weg (Commander-Einwand:
   .vbs ist abgekündigt + wird als gefährlich geflaggt). install-gui.ps1 via
@@ -183,16 +250,20 @@ Konvertierung (Infrastruktur steht), AI-Box-NFS-Export, Kodi-Refresh.
 - **UHD-Kette diagnostiziert (Nachtrag, gleicher Tag): Der BU40N-Flash IST
   erledigt** — makemkvcon meldet „Using LibreDrive mode (v06.3)". Der
   Summer-Wars-Fehlschlag lag NICHT am Laufwerk, sondern an „The volume key
-  is unknown": die Disc (MKB v82) ist neuer als MakeMKVs Schlüssel-DB —
-  auf der VM mit 1.17.7 UND der aktuellsten 1.18.4 bewiesen. Konsequenzen:
+  is unknown" — auf der VM mit 1.17.7 UND der aktuellsten 1.18.4
+  reproduziert. Konsequenzen:
   MakeMKV auf **1.18.4** gehoben (Scan-Hänger durch überall genutztes
   --noscan umgangen, auf der BU40N sauber gelaufen; URL-Base → /download),
   run_makemkv reicht kritische Meldungen (volume key/Key abgelaufen) in
   den Fehlertext durch, UHD-Klartext unterscheidet jetzt „Laufwerk kann
-  kein UHD" von „Disc neuer als Key-DB" inkl. Forum-Dump-Hinweis
+  kein UHD" von „Disc-Schlüssel fehlt" inkl. Forum-Dump-Hinweis
   (MakeMKV speichert den AACS-Dump automatisch unter /root/.MakeMKV/).
-  Summer Wars bleibt bis zu einem MakeMKV-Key-Update nicht entschlüsselbar
-  — das ist Stand der Technik, kein Rippy-Bug.
+  **⚠️ Korrigiert am 25.07.2026 (siehe v3.10 ganz oben):** Die hier
+  ursprünglich genannte Erklärung „die Disc ist neuer als MakeMKVs
+  Schlüssel-DB, ein MakeMKV-Update löst das" ist FALSCH. Nachgemessen:
+  MakeMKV hat gar keine nachladbare Schlüssel-DB mehr und versucht auch
+  keinen Online-Abruf; die alten Schlüssel-Server sind tot. Der Weg zum
+  Ziel heißt `KEYDB.cfg`, nicht „warten auf die nächste Version".
 - **Vollautomatik** (Einstellungen → Ripping): Disc erkannt → Rip startet
   ohne Popup in den passenden Schnellwahl-Ordner (Serie/Film/Musik).
 - **Job-Verwaltung**: „Neu komprimieren" nur noch, wenn Rohdaten wirklich