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>
2026-07-25 01:26:08 +02:00
parent f74f4e54f6
commit 0935766f61
23 changed files with 1717 additions and 69 deletions
@@ -20,6 +20,7 @@ import shutil
 import requests

 import db
+import makemkv_daten
 import medien
 import notify
 from celery_app import celery_app
@@ -147,15 +148,26 @@ def _makemkv_key_anwenden(einstellungen: dict) -> None:

    Damit ist der Monats-Key ohne Rebuild/Neustart aktualisierbar
    (Einstellungen → System). Format wie entrypoint.sh: settings.conf.
+
+    Ergänzend statt überschreibend (Befund 25.07.2026): das Datenverzeichnis
+    ist jetzt persistent, und hier stand vorher ein open(..., "w") — das warf
+    vor JEDEM Rip alles andere aus der settings.conf, z. B. app_UpdateEnable
+    aus dem entrypoint. Beide Schreiber müssen gleich arbeiten, sonst kommt
+    der Fehler beim nächsten Rip still zurück.
    """
    key = (einstellungen.get("makemkvAppKey") or "").strip()
    if not key:
        return
-    ordner = os.path.expanduser("~/.MakeMKV")
+    pfad = os.path.join(makemkv_daten.DATEN_DIR, "settings.conf")
    try:
-        os.makedirs(ordner, exist_ok=True)
-        with open(os.path.join(ordner, "settings.conf"), "w") as f:
-            f.write(f'app_Key = "{key}"\n')
+        os.makedirs(makemkv_daten.DATEN_DIR, exist_ok=True)
+        try:
+            with open(pfad, encoding="utf-8", errors="replace") as f:
+                alt = f.read()
+        except OSError:
+            alt = ""
+        with open(pfad, "w", encoding="utf-8", newline="\n") as f:
+            f.write(makemkv_daten.settings_conf_zusammenfuehren(alt, key))
    except OSError as e:
        db.add_log("warning", "worker", f"MakeMKV-Key konnte nicht gesetzt werden: {e}")

@@ -344,6 +356,22 @@ def rip_disc(self, device_path: str, job_id: str, target_dir: str = None):
        )
        db.update_job(job_id, progress=progress)

+    # MakeMKV-Meldungen ins Log (Befund 25.07.2026): Bis dahin überlebte NUR
+    # die letzte Zeile ("Failed to open disc"), und die sagt nichts. Dass
+    # MakeMKV bei der UHD-Disc nicht einmal versucht, einen Schlüssel zu
+    # holen, war deshalb nur per Hand-Lauf im Container zu sehen.
+    # Gedrosselt, weil das UI global nur die letzten 200 Zeilen zeigt: jede
+    # Meldung höchstens einmal, insgesamt höchstens MAX_MELDUNGEN je Rip.
+    # Code 1003 ist MakeMKVs eigenes DEBUG-Rauschen (am 25.07. beobachtet).
+    MAX_MELDUNGEN = 40
+    gesehen = set()
+
+    def melde_makemkv(code: int, text: str):
+        if code == 1003 or len(gesehen) >= MAX_MELDUNGEN or text in gesehen:
+            return
+        gesehen.add(text)
+        db.add_log("info", "makemkv", f"Job {job_id}: {text[:300]}")
+
    einstellungen = db.get_settings()
    ist_video = disc_type in ("dvd", "bluray", "uhd")
    transcode_an = ist_video and einstellungen.get("transcodeEnabled", True)
@@ -411,6 +439,7 @@ def rip_disc(self, device_path: str, job_id: str, target_dir: str = None):
            output_dir=raw_dir,
            nur_hauptfilm=nur_hauptfilm,
            titel_liste=titel_liste,
+            log_cb=melde_makemkv,
        )
    else:
        ergebnis = rip_video(
@@ -418,26 +447,43 @@ def rip_disc(self, device_path: str, job_id: str, target_dir: str = None):
            progress_cb=fortschritt, output_dir=final_dir,
            nur_hauptfilm=nur_hauptfilm,
            titel_liste=titel_liste,
+            log_cb=melde_makemkv,
        )

-    # UHD-Fehler in Klartext übersetzen — "Failed to open disc" allein hilft
-    # niemandem. Zwei bekannte Ursachen (Befunde 24.07., Summer-Wars-UHD):
-    if ergebnis.get("status") == "error" and disc_type == "uhd":
+    # MakeMKV-Fehler in Klartext übersetzen — "Failed to open disc" allein
+    # hilft niemandem.
+    if ergebnis.get("status") == "error":
        fehler_text = ergebnis.get("error") or ""
        if "volume key is unknown" in fehler_text:
-            # LibreDrive lief bereits — MakeMKV kennt nur den Disc-Schlüssel
-            # nicht: Version zu alt ODER Disc neuer als die Key-Datenbank.
+            # Befund 25.07.2026, im Worker nachgemessen (Akira UHD, MKB v76,
+            # Pressung Dez. 2020): Laufwerk und MakeMKV sind in Ordnung —
+            # MakeMKV fragt online gar nicht erst nach einem Schlüssel, und
+            # der Online-Kanal liefert auch nichts mehr. Der alte Text hier
+            # ("Disc neuer als die Schlüssel-Datenbank, mit einem der
+            # nächsten Updates rippbar") war schlicht falsch und hat in die
+            # falsche Richtung geschickt. Details: makemkv_daten.py.
+            keydb = makemkv_daten.keydb_status()
            ergebnis["error"] += (
-                " — Klartext: Das Laufwerk liest die Disc (LibreDrive OK), "
-                "aber MakeMKV kennt den Schlüssel dieser Disc nicht. Erst "
-                "prüfen: MakeMKV aktuell? (Einstellungen → System; Update = "
-                "Image-Rebuild). Ist es aktuell, ist die Disc neuer als die "
-                "Schlüssel-Datenbank — MakeMKV hat einen AACS-Dump unter "
-                "/root/.MakeMKV/ im Worker gespeichert; im MakeMKV-Forum "
-                "(Bereich 'Ultra HD Blu-ray') einreichen, mit einem der "
-                "nächsten Updates ist die Disc dann rippbar."
+                " — Klartext: Laufwerk und Rippy sind in Ordnung, MakeMKV "
+                "liest die Disc. Es kennt nur den Schlüssel dieser Pressung "
+                "nicht und holt ihn auch nicht mehr online nach — MakeMKVs "
+                "Schlüssel-Kanal liefert nichts mehr (am 25.07.2026 im "
+                "Worker nachgemessen). Abhilfe: eine KEYDB.cfg unter "
+                "Einstellungen → System hochladen; sie wirkt ab dem nächsten "
+                "Rip. "
+                + (
+                    "Aktuell liegt dort keine KEYDB.cfg."
+                    if not keydb.get("vorhanden")
+                    else "Es liegt bereits eine KEYDB.cfg dort — sie kennt "
+                    "diese Pressung offenbar nicht; eine neuere Fassung "
+                    "kann helfen."
+                )
+                + " Den AACS-Dump dieser Disc bewahrt Rippy jetzt dauerhaft "
+                "auf; er steht unter Einstellungen → System zum Download "
+                "bereit (für die Einreichung im MakeMKV-Forum, Bereich "
+                "'Ultra HD Blu-ray')."
            )
-        elif "Failed to open disc" in fehler_text:
+        elif disc_type == "uhd" and "Failed to open disc" in fehler_text:
            ergebnis["error"] += (
                " — 4K-UHD erkannt: Das Laufwerk kann UHD-Discs vermutlich "
                "nicht entschlüsseln. Dafür ist eine LibreDrive-Firmware nötig "