Files

T

Ampel / ampel (push) Successful in 28s

Details

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

12 KiB

Raw Blame History

KONZEPT — Rippy

Automatisches Ripping-System für CD, DVD und Blu-ray, gebaut für Proxmox LXC (Debian 12 Slim). Ziel: Ein modernes, eigenständiges System statt veralteter ARM-Flask-UI.

1. Ziel & Motivation

Der Commander betreibt ein Heimlab mit Proxmox LXC (Debian 12) und PBS-Backup. Das vorhandene Automatic Ripping Machine (ARM) ist funktional, aber das UI (Flask) ist veraltet, es hat keine Echtzeit-Updates (kein SSE/WebSocket), keine JWT-Auth und eine monolithische Architektur.

Rippy ist ein komplett neues System von Grund auf: modulare Multi-Container-Architektur, modernes WebUI, Echtzeit-Jobstatus, sichere Authentifizierung — gebaut als eigenständiges Produkt, nicht als ARM-Fork.

2. Zielgruppe

Commander (Hauptnutzer): Technik-affin, Proxmox-Heimlab, Wert auf eigene Kontrolle und Datenschutz.
Zukünftig: Weitere Heimlab-Nutzer mit ähnlicher Infrastruktur.

3. Kern-Idee

Ein modular aufgebautes System, das bei Disc-Einwurf automatisch den Typ erkennt, vorbereitend Metadaten lookup und Preview bereitstellt, das Medium rippt, Metadaten anreichert und das Ergebnis Jellyfin-konform strukturiert ablegt. Alles über eine REST-API, asynchrone Celery-Jobs, ein React-WebUI.

4. Features

Feature	Muss	Kann	Später
Disc-Erkennung via udev-Event	✔ M
Dynamischer Device-Resolver (UUID/Serial)	✔ M
MakeMKV-Ripping (lossless)	✔ M
Audio-Rip mit abcde + MusicBrainz	✔ M
Metadaten-Lookup VOR dem Ripping (Preview)	✔ M
Jellyfin-Ordnerstruktur & NFO-Generierung	✔ M
Jellyfin-Poster/Backdrop/Fanart Download	✔ M
Jellyfin-kompatible Dateibenennung	✔ M
Video-Metadaten via TMDB API	✔ M
AcoustID-Fingerprinting (chromaprint)	✔ M
Multi-Disc-Set-Handling (Release-Group-Resolver)	✔ M
SQLite-Cache für API-Rate-Limits	✔ M
~~JWT-Auth (Access 15min/Refresh 7 Tage)~~ — GESTRICHEN 24.07.2026, siehe §10
Rate-Limiting (100/min pro Client-IP)	✔ M
Celery-Queue + Redis mit AOF-Persistence	✔ M
React-UI (statisch via Nginx)	✔ M
Proxmox LXC Template + Ansible Playbooks	✔ M
SELinux/AppArmor Profile pro Container	✔ M
MakeMKV als isolierte Black-Box-CLI	✔ M
GPL-v3-Compliance-Checkliste	✔ M
Source-Release-Endpoint	✔ M
HandBrake-Kompression NACH dem Lossless-Rip (Stufe 2)	✔ M
Prometheus+Grafana Monitoring		✔ K
PBS-Snapshot-Backup-Hooks		✔ K
Multi-Disc-Parallelisierung			✔ S
Redis-Cluster (Horizontales Scaling)			✔ S
PWA Mobile-App			✔ S

5. Mechaniken & Ablauf

Roter Faden — was passiert, wenn der Commander eine Disc einlegt:

udev-Event → System-Dämon (unabhängig vom API-Container) erkennt Einwurf.
Device-Resolver (udev-basiert) ermittelt UUID/Serial-Nummer des Laufwerks, erzeugt Symlink /dev/disc/<uuid>.
Job-Erstellung → Dämon erstellt Celery-Task, übergibt Device-Pfad und Disc-Typ.
Typ-Erkennung (CD/DVD/Blu-ray) → Auswahl des Ripping-Pfads.
METADATEN-Lookup im VORFELD:
- DVD/Blu-ray: makejungles liest TOC ohne Ripping.
- Title, Laufzeit, Scene-Labels werden ausgelesen.
- Video-Titel wird gegen TMDB API gegengeprüft → Confidence-Score.
- Audio-Titel wird gegen MusicBrainz gegengeprüft (bei CD).
- Rippy zeigt eine Preview im WebUI: Titel, Jahr, Cover, Trackliste.
- Commander bestätigt oder korrigiert manuell.
Ripping (nach Bestätigung):
- CD: abcde → FLAC, Metadaten via AcoustID + MusicBrainz.
- DVD/Blu-ray: makemkvcon → verlustfreies MKV als ZWISCHENPRODUKT in /app/temp (MakeMKV ist der einzige Weg durch AACS — HandBrake kann verschlüsselte Discs nicht lesen), danach HandBrake-Kompression auf Arbeitsgröße (x265; Commander-Entscheid 23.07.2026: 40-GB-Rohdateien sind kein brauchbares Endprodukt). Roh-Datei wird nach Erfolg gelöscht (Setting keepOriginal behält sie).
Post-Processing & Jellyfin-Formatierung:
- Dateien in Jellyfin-konformer Ordnerstruktur.
- NFO-Dateien im Kodi/NFO-Schema.
- Poster/Backdrop/Fanart von TMDB.
Multi-Disc-Erkennung: Release-Group-Resolver prüft weitere Discs.
Status-Push: Worker sendet Fortschritt an UI.
Abschluss: Job-Ergebnis protokolliert, PBS-Backup-Hook.

6. Architektur & Tech-Stack

Container-Design:

API-Service (FastAPI): JWT-Auth, REST-Endpoints, OpenAPI-Docs, Job-Management.
Worker-Service (Celery + Redis mit AOF-Persistence): Isolierte Ripping-Jobs.
UI-Service (React + Vite): Build-Step → statisch via Nginx.
udev-Daemon: Separater System-Dienst für Disc-Einwurf-Events.

Container-Security:

read_only: true für API/Worker (keine Schreibrechte außer tmpfs)
tmpfs für /app/tmp, /run, /tmp (wichtig für Python __pycache__)
Healthchecks für Postgres/Redis
Separate Volumes für Medien und Temp-Dateien

Neue Worker-Komponenten:

NFO-Generator: .nfo-Dateien im Jellyfin-Kodi-Schema.
TMDB Image-Downloader: poster.jpg, fanart.jpg, backdrop.jpg.
Pre-Scan-Modul: TOC-Lesung ohne Ripping + API-Query.

LXC-Isolation:

Read-only Bind-Mounts für System-Bibliotheken.
Device-Node-Read-Only für /dev/sr*.
SELinux/AppArmor Profile pro Container.
Netzwerk-Policy: UI→API (HTTPS), API↔Worker (mTLS).

Persistenz:

PostgreSQL für Job-Logs, Metadaten, User-Management.
SQLite-Cache für API-Antworten (LRU, 10k Einträge).
NFS/Bind-Mount für Medien-Store.

7. UX-Flow

Dashboard — Echtzeit-Kacheln mit Job-Status, Queue-Übersicht.
Job-Verlauf — Tabelle aller Jobs mit Status, Fortschrittsbalken.
Metadaten-Preview — Nach udev-Erkennung: Titel, Jahr, Cover, Trackliste, Confidence-Score.
Job-Detail — Live-Log-Ausgabe, Fortschritt, "Abort".
Ergebnis-View — Liste gerippter Dateien, Metadaten, Jellyfin-Ordnerstruktur.
Einstellungen — API-Keys, Transcoding, Backup-Pfade, Jellyfin-Config.
Geräte-Verwaltung — Liste Laufwerke, Status, Device-Resolver.

8. Risiken & offene Punkte

Risiko	Status	Behandlung
MakeMKV-Beta-Key-Management	Gelöst	Key-Erneuerung als Cron-Job; DMCA-Ausnahme in DE
Disc-Schlüssel für 4K-UHD (AACS 2.0)	Offen — durch Rippy nicht lösbar	Am 25.07.2026 auf der VM gemessen: MakeMKV holt für unbekannte UHD-Discs keinen Schlüssel mehr (kein Netz-Versuch im Log, keine `hkd_*.bin` im `_private_data.tar`), die dokumentierten Schlüssel-Server sind weltweit tot. Rippy stellt NUR ein persistentes Datenverzeichnis für eine vom Nutzer selbst mitgebrachte `KEYDB.cfg` bereit und gibt die AACS-Dumps heraus — es liefert, lädt und verteilt keine Schlüssel. Siehe §10 (25.07.2026)
LXC-Device-Node-Änderungen	Gelöst	udev-Resolver (UUID/Serial)
Pending-Queue / State-Manager	Gelöst	Redis mit AOF-Persistence
Hybrid-Discs	Offen	MVP erkennt nur Standard; als "Kann" notiert
LXC-Device-Passthrough	Gelöst	Read-only Bind-Mounts; udev-Daemon unabhängig
Rate-Limits der Metadaten-APIs	Gelöst	SQLite-Cache (LRU, 10k Einträge), exponential backoff
GPL-v3-Compliance	Gelöst	Checkliste, Source-Release-Endpoint, Black-Box-Trennung
Redis Single-Instance	Offen	MVP mit Single-Instance; Cluster als "Später"
TMDB-Matching-Fehler bei Nischentiteln	Offen	Pre-Scan Confidence-Score + manueller Korrektur-Mechanismus
NFO-Format-Abhängigkeit von Jellyfin-Version	Hinweis	Kodi/NFO-Schema (stabil, gut dokumentiert)
Pre-Scan-Latenz (5–15s)	Hinweis	Akzeptabel für Heim-Use-Case; parallelisierbar
TMDB-Bildrechte	Gelöst	TMDB API-ToS erlaubt private Nutzung

9. Härtetest-Dokumentation

Erster Haertetest (Advocatus Diaboli, GLM-4.7-Flash): 5 BLOCKER gefunden: MakeMKV-Key-Management, LXC-Device-Resolver, Pending-Queue, Hybrid-Discs, Bind-Mount-Performance.

Runde 1 (5 Rollen):

DevOps: Multi-Container-Architektur, Proxmox-HA-Template, Resource-Limits, Restart-Policy.
Security: JWT-Refresh-Token, Rate-Limiting, mTLS, SELinux/AppArmor.
Software Architekt: udev-basierter Device-Resolver, Unix-Socket, State-Manager.
Media Metadata: AcoustID-Fingerprinting, Multi-Disc-Set-Handling, SQLite-Cache.
Legal: GPL-v3-Checkliste, MakeMKV-Black-Box-Trennung, Source-Release-Endpoint.

Zweiter Haertetest (Advocatus Diaboli, GLM-4.7-Flash): 5 HINWEISE (keine BLOCKER): React als Build-Step+Statisch (korrigiert), Redis-AOF-Persistence (integriert), Read-only vs. Write-Konflikt (nicht relevant), Redis-Cluster (als "Später" notiert), Cold-Boot-Problematik (udev-Daemon gelöst).

Dritte Iteration — Commander-Feedback:

Metadaten-Lookup VOR dem Ripping
100% Jellyfin-Kompatibilität
Metadaten-Preview im UI
Neue Risiken: TMDB-Matching-Fehler (mit Fallback), NFO-Format-Abhängigkeit (Hinweis), Pre-Scan-Latenz (Hinweis)

Ergebnis: Konzept ist wasserdicht für MVP-Phase.

10. Konzept-Fortschreibungen (dokumentierte Erweiterungen, keine Abweichungen)

24.07.2026 — Media-Server-Neutralität: Die Jellyfin-Muss-Features (Ordnerstruktur, NFO, Poster) bleiben vollständig bestehen; sie sind jetzt über das Setting mediaServer auf Emby und Kodi ausgeweitet (identisches Kodi-NFO-Schema) und für Plex auf die reine Benennung reduziert. Jellyfin bleibt Referenz- und Empfehlungssystem im Einrichtungs-Assistenten.
24.07.2026 — Benachrichtigungen: Webhook bei Job-Ende (Discord/Slack/ ntfy/generisch) als gebautes Feature — im UX-Flow Punkt 10 („Abschluss") war das als Protokollierung angelegt, jetzt meldet Rippy aktiv.
23./24.07.2026 — udev → ioctl: Der im Konzept beschriebene udev-Daemon ist im Container prinzipbedingt nicht lauffähig; die Disc-Wache pollt per Kernel-ioctl (3 s) — gleiches Verhalten, universell lauffähig.
24.07.2026 — AUTH GESTRICHEN (Commander-Entscheid): Das Muss-Feature „JWT-Auth" ist komplett entfernt (Endpoints, auth.py, Abhängigkeiten, Env-Pflicht). Begründung: Rippy läuft ausschließlich im Heimnetz, das UI hatte nie einen Login-Flow — die Auth-Oberfläche war Placebo und die passlib/bcrypt-Abhängigkeit hat die CI-Ampel gebrochen. Rate-Limiting (pro IP) bleibt. Wer Rippy je nach außen öffnet, stellt einen Reverse-Proxy mit eigener Auth davor (z. B. Authelia/Caddy basicauth).
25.07.2026 — 4K-UHD-Disc-Schlüssel: Rippy stellt Platz bereit, keine Schlüssel: Das Muss-Feature „MakeMKV-Ripping (lossless)" bleibt unverändert; ergänzt wird nur ein persistentes MakeMKV-Datenverzeichnis (MAKEMKV_DATA_HOST, im Worker /root/.MakeMKV, in der API /app/makemkv-data) samt Bedienung im UI. Begründung: Am 25.07.2026 auf der VM nachgemessen — MakeMKV versucht bei einer unbekannten UHD-Disc gar keinen Online-Abruf mehr, und die früher genutzten Schlüssel-Server sind weltweit tot; der einzige heute funktionierende Weg ist eine KEYDB.cfg im Datenverzeichnis. Rippy liefert und verteilt KEINE Disc-Schlüssel und lädt auch keine herunter — es hält nur den Platz für eine Datei bereit, die der Nutzer selbst mitbringt, zeigt ehrlich an, was dort liegt, und gibt die AACS-Dumps heraus, die MakeMKV ohnehin selbst schreibt. Das ist genau die Grenze, die docker/api/makemkv_key.py in Zeile 14 zieht: die kostenlose Beta-LIZENZ der Software ist etwas anderes als das Entschlüsseln oder Verteilen von Disc-Schlüsseln.
24.07.2026 — Serien-Flow: Staffel-Ablage /Season NN plus Episoden-Zuordnung per Laufzeitabgleich (TMDB) — erfüllt Etappe-12-Ziel „Serien-Episoden-Erkennung" in der ersten Ausbaustufe (nur bei EINDEUTIGER Zuordnung wird umbenannt).

12 KiB Raw Blame History Unescape Escape