Hitonabi
0935766f61
Ampel / ampel (push) Successful in 28s
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>
205 lines
12 KiB
Markdown
205 lines
12 KiB
Markdown
# 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:**
|
||
|
||
1. **udev-Event** → System-Dämon (unabhängig vom API-Container) erkennt Einwurf.
|
||
2. **Device-Resolver** (udev-basiert) ermittelt UUID/Serial-Nummer des Laufwerks, erzeugt Symlink `/dev/disc/<uuid>`.
|
||
3. **Job-Erstellung** → Dämon erstellt Celery-Task, übergibt Device-Pfad und Disc-Typ.
|
||
4. **Typ-Erkennung** (CD/DVD/Blu-ray) → Auswahl des Ripping-Pfads.
|
||
5. **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.
|
||
6. **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).
|
||
7. **Post-Processing & Jellyfin-Formatierung**:
|
||
- Dateien in Jellyfin-konformer Ordnerstruktur.
|
||
- NFO-Dateien im Kodi/NFO-Schema.
|
||
- Poster/Backdrop/Fanart von TMDB.
|
||
8. **Multi-Disc-Erkennung**: Release-Group-Resolver prüft weitere Discs.
|
||
9. **Status-Push**: Worker sendet Fortschritt an UI.
|
||
10. **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
|
||
|
||
1. **Dashboard** — Echtzeit-Kacheln mit Job-Status, Queue-Übersicht.
|
||
2. **Job-Verlauf** — Tabelle aller Jobs mit Status, Fortschrittsbalken.
|
||
3. **Metadaten-Preview** — Nach udev-Erkennung: Titel, Jahr, Cover, Trackliste, Confidence-Score.
|
||
4. **Job-Detail** — Live-Log-Ausgabe, Fortschritt, "Abort".
|
||
5. **Ergebnis-View** — Liste gerippter Dateien, Metadaten, Jellyfin-Ordnerstruktur.
|
||
6. **Einstellungen** — API-Keys, Transcoding, Backup-Pfade, Jellyfin-Config.
|
||
7. **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 <Serie>/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).
|