Rippy — die All-in-one Disc-Ripping-Maschine

Disc rein → automatisch erkannt (Titel, Poster, Metadaten) → verlustfrei gerippt (MakeMKV) → auf Arbeitsgröße komprimiert (HandBrake) → fertig abgelegt, wo DU willst (lokal, NAS, jede Freigabe). Modernes Web-UI, Echtzeit-Fortschritt, komplett in Docker, komplett lokal.

Schnellstart

Voraussetzungen: Docker + Docker Compose, ein optisches Laufwerk am Host.

git clone <repo-url> rippy && cd rippy
cp .env.example .env          # optional: API-Keys — geht auch später im UI
mkdir -p /srv/rippy/media     # Ablage-Basis (anpassbar in docker-compose.yml)
docker compose up -d --build

Dann http://<host> öffnen — der Einrichtungs-Assistent startet beim ersten Mal automatisch (API-Keys, Verarbeitung, erkannte Hardware).

Laufwerk anpassen

Der Worker braucht zwei Host-Geräteknoten: den CD-ROM-Knoten (meist /dev/sr0) und den passenden SCSI-Generic-Knoten (/dev/sgN) — MakeMKV spricht Laufwerke über die sg-Schicht an. Die sg-Nummer ist je Host anders (auf frischen Systemen oft /dev/sg0).

Ermitteln, welche Knoten dein Blu-ray/DVD-Laufwerk hat:

lsscsi -g          # zeigt Modell + zugehörigen /dev/sgN
# oder: ls -la /sys/class/scsi_generic/

Dann in der .env eintragen (Defaults passen für den Ursprungs-Host):

OPTICAL_SR=/dev/sr0    # CD-ROM-Knoten deines Laufwerks
OPTICAL_SG=/dev/sg0    # sg-Knoten deines Laufwerks

docker compose up -d nutzt diese Werte. (Für Feineinstellungen geht weiterhin eine docker-compose.override.yml mit eigenen devices:-Einträgen.)

Laufwerk in einer VM? Per USB-Passthrough anhand der Vendor-ID durchreichen (Proxmox: qm set <vmid> -usb0 host=xxxx:yyyy,usb3=1) — NICHT als emuliertes CD-ROM (media=cdrom), das kann keine SCSI-Kommandos.

Wie es funktioniert

1. Disc-Wache (ioctl-Polling, kein udev-Gefrickel) erkennt Einlegen, identifiziert die Disc (Volume-Label → TMDB → OMDb-Fallback) und zeigt sie mit Poster auf dem Dashboard. Klick auf einen Job-Titel öffnet die Detail-Ansicht (Poster, Jahr, Beschreibung, Ablagepfad).
2. Rip (MakeMKV, verlustfrei — der einzige Weg durch AACS): Ziel wählst du beim Start (Filme/Serien/Musik/eigener Pfad, inkl. Netzwerk-Ziele) — oder du stellst die Vollautomatik an (Einstellungen → Ripping) und der Rip startet ohne Nachfrage in den passenden Schnellwahl-Ordner. Optional nur Hauptfilm (längster Titel, Extras bleiben weg). Bereits gerippte Discs erkennt Rippy am Fingerabdruck und warnt. Vor dem Start prüft Rippy den freien Platz gegen die Disc-Größe. Alle Tonspuren und Untertitel bleiben erhalten (wichtig für Anime/O-Ton). Audio-CDs laufen über abcde → FLAC + MusicBrainz. Serien: Im Dialog „Serien" wählen → Serienname + Staffel angeben — Ablage wird <Serie>/Season NN, und die Episoden werden nach dem Rip per Laufzeitabgleich (TMDB) automatisch zu „Serie S01E02.mkv" benannt (nur bei eindeutiger Zuordnung — sonst bleiben die Namen, mit Log).
3. Kompression (HandBrake, eigener Job auf eigener Queue): x265/x264, Preset im UI wählbar; Rohdatei wird erst nach Erfolg gelöscht („Original behalten" als Option). Fehlgeschlagene Kompressionen lassen sich ohne Neu-Rip neu anstoßen.
4. Media-Server-Ablage: Unter Einstellungen → Ripping (oder im Einrichtungs-Assistenten) wählst du dein System — Jellyfin, Emby, Kodi, Plex oder keins. Fertige Rips heißen dann „Titel (Jahr)" statt Job-UUID; für Jellyfin/Emby/Kodi legt Rippy zusätzlich movie.nfo + poster.jpg dazu (Kodi-NFO-Schema, lesen alle drei nativ). Plex nutzt 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 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 Klartext-Meldung ab statt nach 40 GB mit voller Platte.

Speicherziele (NAS, Freigaben)

Unter Einstellungen → Speicherziele hängst du NFS- oder SMB-Freigaben direkt aus dem UI ein — sie erscheinen sofort in der Ziel-Auswahl beim Rippen und werden beim Start automatisch wieder verbunden. Technik: der api-Container läuft mit CAP_SYS_ADMIN und einem rshared-Bind auf /srv/rippy/media, Mounts propagieren zu allen Containern. ⚠️ Zugangsdaten liegen unverschlüsselt in der lokalen Postgres-DB — bewusster Heimnetz-Kompromiss; lege fürs NAS einen eigenen, eingeschränkten Benutzer an.

Benachrichtigungen

Einstellungen → Benachrichtigungen: eine Webhook-URL eintragen, „Test senden" drücken, speichern — fertig. Rippy meldet Job-Ende (fertig, fehlgeschlagen, abgebrochen) und erkennt den Dienst an der URL selbst:

Dienst	URL-Beispiel	Format
Discord	https://discord.com/api/webhooks/…	{"content": …}
Slack	https://hooks.slack.com/services/…	{"text": …}
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, Disc-Schlüssel & Updates

Einstellungen → System zeigt die Werkzeug-Versionen jedes Workers (MakeMKV, HandBrake), den Key-Status und den freien Speicherplatz. Der 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. ⚠️ 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.

Verarbeitung & Hardware

Einstellungen → Verarbeitung zeigt ehrlich an, welche Encoder deine Worker WIRKLICH haben (CPU x264/x265, VAAPI bei AMD/Intel-GPU, NVENC bei NVIDIA) — jeder Worker meldet seine Fähigkeiten selbst beim Start.

Optional: weitere Maschinen als Transcode-Worker

Die Kompression läuft als eigener Celery-Task auf der Queue transcode — JEDE Maschine im Netz kann sie übernehmen. Einstellungen → Worker zeigt für beide Varianten einen Copy-Paste-Befehl:

• Linux (Docker): deploy/remote-transcode-worker.yml
• Windows (nativ, ohne Docker): braucht nur Python 3.10+ — der Installer (install.ps1) kommt von der Rippy-Instanz selbst (/api/worker-setup/windows), lädt Worker-Code und HandBrakeCLI automatisch und erzeugt eine start-worker.bat (optional -Autostart).

Ohne Zusatz-Worker macht der eingebaute CPU-Worker alles selbst — Rippy bleibt All-in-one.

Umgebungsvariablen (.env)

Variable	Pflicht	Zweck
TMDB_API_KEY	empfohlen	Metadaten (deutsche Texte) — alternativ im UI/Wizard; beide Key-Arten gehen (v3-Schlüssel und v4-Token)
WORKER_NAME	optional	Anzeigename des eingebauten Workers (Standard: rippy-hauptworker)
OMDB_API_KEY	optional	zweite Metadaten-Quelle (Fallback)
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

UI-Einstellungen (Wizard/Settings) überstimmen die Env-Variablen.

Rippy woanders bereitstellen

Rippy ist reines Docker Compose — es läuft auf jedem Linux-Host mit Docker, nicht nur auf der Original-VM. Es gibt (noch) keine fertigen Registry-Images; gebaut wird beim ersten up direkt aus dem Repo.

Voraussetzungen auf dem Ziel-Host:

1. Linux (x86_64) mit Docker + Compose-Plugin.
2. Ein optisches Laufwerk, das der Host sieht (ls /dev/sr* /dev/sg*). In einer VM: per USB-Passthrough (Vendor-ID) durchreichen, NICHT als emuliertes CD-ROM — siehe „Laufwerk anpassen" oben.
3. Ablage-Basis anlegen: mkdir -p /srv/rippy/media (oder Pfad in docker-compose.yml anpassen). Der Bind nutzt shared/slave-Propagation (fürs In-UI-Einhängen von NAS-Freigaben). Auf den meisten systemd-Linux-Hosts ist / schon rshared, dann ist nichts zu tun. Bricht docker compose up mit „path … is mounted on / but it is not a shared mount" ab, einmalig:

   sudo mount --bind /srv/rippy/media /srv/rippy/media
   sudo mount --make-rshared /srv/rippy/media
   

   (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 den Rest (API-Keys, Media-Server, Verarbeitung). Updates: git pull && docker compose up -d --build.

Nicht mitnehmen musst du: Gitea, Arcane, den CI-Runner — das ist die Entwicklungs-Infrastruktur DIESER Installation, nicht Teil von Rippy.

Härtung für fremde/exponierte Netze

Rippy ist bewusst Heimnetz-only: Es hat keine Authentifizierung, und Redis + PostgreSQL veröffentlichen Ports auf allen Interfaces (für Remote-Worker). Im vertrauten LAN ist das ein akzeptierter Kompromiss — exponiere Rippy niemals ungeschützt an ein unsicheres oder öffentliches Netz. Wer es weiter absichern will:

• Zugriff kapseln: API (:8000) und UI hinter einen Reverse-Proxy mit Auth (Basic-/Forward-Auth) legen oder nur über VPN erreichbar machen; Port 8000 nicht auf 0.0.0.0 binden.
• DB/Broker abschotten: POSTGRES_PASSWORD in der .env auf ein starkes Passwort setzen; die Ports 5432/6379 nur an ein internes/VPN-Interface binden (z. B. "10.0.0.5:5432:5432") statt an 0.0.0.0; Redis mit --requirepass <geheim> starten und das Passwort in REDIS_URL ergänzen.
• CORS: main.py erlaubt aktuell * (nötig, weil UI und API getrennte Ports sind) — hinter einem Proxy auf die echte UI-Herkunft einschränken.
• NAS-Zugangsdaten liegen bewusst im Klartext in der DB — ein weiterer Grund, den DB-Port nie offen ins unsichere Netz zu hängen.

Entwicklung

CI („Ampel") läuft bei jedem Push: Ruff, pytest, Vite-Build. Es gibt genau einen Branch, main (Single Source of Truth) — die Ampel prüft nur, deployt wird direkt aus main. Rot heißt: nicht deployen. Regeln für Beiträge: AGENTS.md · Konzept: KONZEPT.md · Fahrplan: ROADMAP.md