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, komplett in Docker, komplett lokal — keine Cloud, keine Telemetrie.

Installation

Du brauchst: einen Linux-Rechner mit Docker und ein optisches Laufwerk.

Welche Distribution, ist gleichgültig — Debian, Ubuntu, Arch, Fedora, openSUSE, Alpine. Rippy bringt alles Nötige (MakeMKV, HandBrake, abcde) in seinen eigenen Containern mit; vom Host braucht es nur Docker und einen Kernel, der das Laufwerk sieht. install.sh erkennt das Paketwerkzeug selbst und nennt dir den passenden Befehl, falls etwas fehlt.

git clone <repo-url> rippy && cd rippy
sudo ./install.sh

Das war es. Am Ende steht die Adresse im Terminal — im Browser öffnen, der Einrichtungs-Assistent übernimmt den Rest.

Zuerst nur nachsehen, ob alles passt, ohne etwas zu ändern:

./install.sh --nur-pruefen

Was install.sh für dich macht (aufklappen)

Es nimmt genau die Schritte ab, an denen man vorher scheitern konnte:

Prüft die Voraussetzungen — Linux, Docker, Compose. Fehlt etwas, steht der Installationsbefehl dabei.
Findet dein Laufwerk selbst. MakeMKV braucht zwei Geräteknoten: /dev/srN und den passenden /dev/sgM. Welche sg-Nummer dazugehört, ist je Rechner anders — das Skript gleicht sie über die SCSI-Adresse ab statt zu raten. (Genau daran ging vorher die Handarbeit schief.)
Legt die Verzeichnisse an (/srv/rippy/media für die Filme, /srv/rippy/makemkv für MakeMKVs Daten).
Richtet die Mount-Propagation ein und macht sie neustart-fest — sonst funktioniert das Einhängen von NAS-Freigaben aus dem UI nach jedem Reboot nicht mehr.
Schreibt die .env mit den gefundenen Werten. Bestehende Werte werden nie überschrieben.
Baut und startet alles.

Das Skript ist wiederholbar: mehrmals ausführen ändert nichts kaputt. Es ist auch der Update-Weg — siehe unten.

Aktualisieren

git pull && sudo ./install.sh

Mit einer Docker-Oberfläche (Dockge, Portainer, Arcane)

Die eine Sache, die du wissen musst: Rippy hat keine fertigen Images in einer Registry. Die drei Dienste api, worker und ui werden aus dem Repo gebaut (build: context: .). Die Compose-Datei allein ist deshalb wertlos — wer sie in ein leeres Verzeichnis kopiert, bekommt sofort „failed to read dockerfile".

Daraus folgt für jede Oberfläche: das Repo muss dort liegen, wo die Oberfläche den Stack baut. Alles andere ist Kleinarbeit.

	kann das Repo selbst holen?	Weg
Shell	—	`git clone` + `sudo ./install.sh`
Dockge	nein	Repo in den Stacks-Ordner klonen
Portainer	ja	Stack aus Repository (Git-URL)
Arcane	nein	Repo auf dem Host, Deploy per Shell

Vorab-Prüfung — braucht kein root, ändert nichts

Egal welche Oberfläche: Führe nach dem Klonen einmal das hier aus. Es sagt dir in fünf Sekunden, ob die Maschine passt — vor allem, welche Geräteknoten dein Laufwerk wirklich hat:

./install.sh --nur-pruefen

Dockge

Dockge verwaltet Stacks als Verzeichnisse. Klone das Repo in den Stacks-Ordner (Standard /opt/stacks, bei dir ggf. anders):

cd /opt/stacks
git clone <repo-url> rippy
cd rippy && ./install.sh --nur-pruefen

Dockge zeigt rippy danach als Stack an, und „Start" baut die Images. Du musst keine Compose-Datei einfügen — die des Repos ist die des Stacks. Lege den Stack also nicht neu in Dockge an, sonst landet eine leere Compose-Datei in einem anderen Ordner und der Bau scheitert.

Portainer

Portainer kann das Repo selbst klonen, das ist hier der bequemste Weg: Stacks → Add stack → Repository, Git-URL eintragen, Compose-Pfad docker-compose.yml. Der Web-Editor und „Upload" funktionieren nicht — beide liefern keinen Build-Kontext.

Die Geräteknoten trägst du als Stack-Umgebungsvariablen ein (statt in eine .env), falls sie von /dev/sr0 und /dev/sg1 abweichen:

OPTICAL_SR=/dev/sr0
OPTICAL_SG=/dev/sg0

Welche es sind, sagt dir auf dem Host lsscsi -g — oder die Vorab-Prüfung oben.

Arcane

Das Repo liegt auf dem Host (z. B. ~/projects/rippy), Arcane verwaltet die Container. Deployt wird per Shell — Arcanes Git-Sync zieht nicht selbstständig:

cd ~/projects/rippy && git pull --ff-only && docker compose up -d --build

Was keine Oberfläche für dich tun kann

Drei Dinge passieren auf dem Host, nicht im Container — deshalb gibt es install.sh überhaupt:

Geräteknoten. MakeMKV braucht /dev/srN und den passenden /dev/sgM; die sg-Nummer ist je Rechner anders. Stimmt sie nicht, startet der Worker-Container gar nicht. Das ist der Fehler, der praktisch immer als erster kommt.
Ablage-Ordner /srv/rippy/media und /srv/rippy/makemkv.
Mount-Propagation (rshared) für das Einhängen von NAS-Freigaben aus dem UI. Auf den meisten systemd-Hosts ist / schon rshared und es ist nichts zu tun — nur wenn docker compose up über „not a shared mount" klagt, braucht es die Shell.

Punkt 1 ist der einzige, der zuverlässig zuschlägt. sudo ./install.sh erledigt alle drei; danach kannst du den Stack dauerhaft über die Oberfläche fahren.

Wenn etwas nicht geht

Die sechs Fälle, die praktisch alles abdecken:

Symptom	Ursache & Lösung
`failed to read dockerfile`	Die Compose-Datei liegt ohne das Repo da. Rippy hat keine Registry-Images, die drei Dienste werden gebaut. Siehe Mit einer Docker-Oberfläche.
Worker-Container startet nicht, `/dev/sgN` nicht gefunden	Die sg-Nummer ist je Rechner anders; die Vorgaben `sr0`/`sg1` passen nur zufällig. `./install.sh --nur-pruefen` sagt dir die richtigen (oder `lsscsi -g`), dann in die `.env` bzw. als Stack-Variablen eintragen. Der Fehler, der praktisch immer als erster kommt.
„Kein optisches Laufwerk gefunden"	In einer VM? Das Laufwerk muss per USB-Passthrough durchgereicht werden, nicht als emuliertes CD-ROM (`media=cdrom`) — das kann keine SCSI-Kommandos, MakeMKV sieht es nie. Proxmox: `qm set <vmid> -usb0 host=<hersteller>:<produkt>,usb3=1`. Auf echter Hardware: `ls /dev/sr*` prüfen.
Build bricht beim MakeMKV-Download ab	Cloudflare drosselt manchmal. Der zuverlässige Weg: Tarballs von makemkv.com/download händisch nach `docker/worker/vendor/` legen, dann `sudo ./install.sh` erneut — der Build nimmt sie von dort und braucht kein Netz. Hast du eine eigene Quelle (Spiegel im LAN), trage sie als `MAKEMKV_URL_FALLBACK` in die `.env` ein; sie wird automatisch versucht, wenn makemkv.com nicht liefert.
Kompression läuft ewig	Deine CPU kann kein AVX2. Rippy zeigt das jetzt selbst an (Einstellungen → System, „Vektorbefehle"). Siehe Rippy schneller machen.
4K-UHD: „The volume key is unknown"	Erwartbar und kein Fehler in Rippy. Siehe 4K-UHD.

Logs ansehen: docker compose logs -f · Status: docker compose ps

Rippy schneller machen

Läuft Rippy in einer virtuellen Maschine, ist das hier der wirksamste Handgriff überhaupt — und er kostet fünf Minuten.

Virtualisierer geben der VM standardmäßig eine generische CPU (bei Proxmox/KVM heißt sie kvm64 bzw. qemu64). Die kann absichtlich nur alte Befehlssätze, damit sich eine VM zwischen verschiedenen Wirten verschieben lässt. Der Preis: kein AVX2 — und genau davon lebt der Video-Encoder x265.

Was das ausmacht, ist auf der Rippy-Maschine gemessen worden: ein 4K-Film in H.265 brauchte 28 bis 55 Stunden, bei voll ausgelasteten Kernen. Mit AVX2 sind typisch 2- bis 4-mal schneller drin.

So stellst du es um (Proxmox):

VM herunterfahren. Ein Neustart von innen genügt nicht — Proxmox übernimmt Hardware-Änderungen nur bei einem echten Stopp.
Im Web-UI: VM auswählen → Hardware → Processors → Doppelklick → Type auf host stellen → OK. Oder auf der Proxmox-Konsole:
```
qm set <vmid> --cpu host
```
VM starten.

Nachprüfen — Rippy sagt es dir selbst: Einstellungen → System, Zeile „Vektorbefehle" beim Worker. Steht dort jetzt avx2 oder avx512f statt sse4_2, hat es geklappt und die amberfarbene Warnung verschwindet. Auf der Kommandozeile: grep -o avx2 /proc/cpuinfo | head -1.

Nachteile von host — der Vollständigkeit halber

Die VM sieht dann die echte CPU. Dadurch lässt sie sich nicht mehr auf einen Wirt mit anderem Prozessor live verschieben. In einem Heim-Cluster mit einem einzigen Wirt ist das ohne Bedeutung. Wer mehrere Wirte hat und Live-Migration nutzt, wählt statt host das neueste Modell, das alle Wirte beherrschen (z. B. x86-64-v3 — das enthält AVX2).

Kein AVX2 möglich? Dann zwei Auswege, beide im UI:

4K nicht komprimieren (Einstellungen → Verarbeitung → Preset für 4K-UHD → „Nicht komprimieren"). Die verlustfreie Datei bleibt stehen: beste Qualität, 20–100 GB je Film. Der Einrichtungs-Assistent wählt das bei schwacher CPU von selbst.
Andere Maschine komprimieren lassen — siehe Weitere Maschinen als Worker.

Der Alltag

Rippen

Disc einlegen. Rippy erkennt sie, zeigt Titel und Poster, du wählst das Ziel — oder du stellst die Vollautomatik an (Einstellungen → Ripping) und es läuft ohne Nachfrage los.

Alle Tonspuren und Untertitel bleiben erhalten (wichtig für Anime/O-Ton).
Nur Hauptfilm auf Wunsch — der längste Titel, Extras bleiben weg.
Serien: Serienname + Staffel angeben → Ablage <Serie>/Season NN, und die Episoden werden per Laufzeitabgleich (TMDB) zu „Serie S01E02.mkv" benannt. Nur bei eindeutiger Zuordnung, sonst bleiben die Namen — mit Log.
Audio-CDs laufen über abcde zu FLAC mit MusicBrainz-Tags.
Schon gerippte Discs erkennt Rippy am Fingerabdruck und warnt.
Vor dem Start wird der freie Platz gegen die Disc-Größe geprüft.

Kompression

Ein eigenes Preset je Disc-Typ (Einstellungen → Verarbeitung) — Rippy erkennt den Typ selbst. Das ist wichtig, weil ein 1080p-Preset eine 4K-UHD stillschweigend herunterrechnet und eine DVD sinnlos hochskaliert.

Jeder Typ kann auch auf „Nicht komprimieren" stehen: dann bleibt der verlustfreie Rip liegen. Sinnvoll für 4K, wenn die Ablage groß genug ist.

Die Rohdatei wird erst nach erfolgreicher Kompression gelöscht („Original behalten" als Option). Fehlgeschlagene Kompressionen lassen sich ohne Neu-Rip erneut anstoßen.

Ablage & Media-Server

Einstellungen → Ripping: dein System wählen (Jellyfin, Emby, Kodi, Plex oder keins). Fertige Rips heißen dann „Titel (Jahr)"; für Jellyfin/Emby/Kodi legt Rippy zusätzlich movie.nfo + poster.jpg dazu. Bei Jellyfin/Emby mit Server-URL + API-Key stößt Rippy nach jedem Rip sofort einen Bibliotheks-Scan an — Disc rein, Film erscheint im Server.

NAS-Freigaben hängst du unter Einstellungen → Speicherziele direkt aus dem UI ein (NFS/SMB). Sie erscheinen sofort in der Ziel-Auswahl und werden beim Start automatisch wieder verbunden. ⚠️ Zugangsdaten liegen unverschlüsselt in der lokalen Datenbank — 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. Rippy erkennt den Dienst an der URL selbst:

Dienst	URL-Beispiel
Discord	`https://discord.com/api/webhooks/…`
Slack	`https://hooks.slack.com/services/…`
ntfy (Handy-Push)	`https://ntfy.sh/mein-geheimes-thema`
Eigenes (Home Assistant, n8n, …)	beliebige HTTPS-URL

4K-UHD

4K braucht zwei Dinge, die normale BD/DVD nicht brauchen: ein LibreDrive-fähiges Laufwerk (MakeMKV-Forum: „Ultimate UHD Drives Flashing Guide") und den Schlüssel dieser Pressung.

Der Schlüssel ist die eigentliche Hürde — aus einem überraschenden Grund. Am 25.07.2026 auf beiden Maschinen 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".

makemkvcon unter Linux holt Disc-Schlüssel nie aus dem Netz. Die Windows-Version tut es.

Gemessen: Linux baute in keinem einzigen Lauf eine Verbindung nach draußen auf — geprüft mit leerem und gefülltem Schlüsselspeicher, mit und ohne --noscan, mit dev: und disc:, und mit erzwungener frischer Prüfung. Dieselbe Disc am selben Laufwerk unter Windows: „Lade aktuelle HK …", Verbindung zum Schlüssel-Server, Disc geht auf. Ein MakeMKV-Update ändert daran nichts, und es ist kein Fehler in Rippy.

Der Weg drumherum (Einstellungen → System):

MakeMKV auf einem Windows-PC installieren (gleicher Beta-Key).
Laufwerk anstecken, Disc einmal öffnen — dabei lädt MakeMKV die Schlüssel nach.
In MakeMKV unter Preferences → General das „MakeMKV data directory" nachschlagen und die Datei _private_data.tar daraus bei Rippy hochladen.

Rippy zeigt an, wie viele Disc-Schlüssel dieser Worker kennt. Steht dort 0, scheitert jede unbekannte UHD. Für neue Discs den Schritt gelegentlich wiederholen. Rippy prüft die Datei und lehnt sie ab, wenn kein einziger Schlüssel drinsteckt — sonst ändert sich nichts und niemand versteht, warum.

Kennt MakeMKV die Pressung selbst nicht, bleibt die KEYDB.cfg als Notnagel (gleicher Tab). Und: AACS-Dumps herunterladen — den Dump legt MakeMKV bei jeder unbekannten Disc selbst ab, und genau den braucht man, wenn man im MakeMKV-Forum um den Schlüssel für eine neue Pressung bittet.

⚠️ Rippy liefert keine Disc-Schlüssel mit, lädt keine herunter und verteilt keine. Rippy hält nur den Platz für eine Datei bereit, die du selbst mitbringst, und zeigt ehrlich an, was dort liegt. Der MakeMKV-Beta-Key ist die Lizenz für die Software — zwei völlig verschiedene Dinge.

⚠️ UHD-Rohdaten sind bis 100 GB groß. Ist die Platte zu klein, lege das Arbeitsverzeichnis (Einstellungen → Verarbeitung) auf eine eingehängte Freigabe. Rippy bricht sonst vor dem Rip mit Klartext ab statt nach 40 GB mit voller Platte.

Weitere Maschinen als Worker

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

Windows (nativ, ohne Docker) — braucht nur Python. Der Installer kommt als fertige .exe von Rippy selbst; Worker-Code und HandBrake holt er zur Laufzeit.
Linux (Docker) — deploy/remote-transcode-worker.yml.

Rippy zeigt für jeden Worker an, was er wirklich kann: Encoder, Kernzahl, Vektorbefehle. Für einen GPU-Worker wichtig: das Bild braucht ein HandBrake mit nvenc_* bzw. qsv_* — die Anzeige nennt HandBrakes ungefilterte Auskunft, damit du das nachprüfen kannst. Das mitgelieferte Linux-Worker-Bild hat keinen Hardware-Encoder.

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

Für Fortgeschrittene

Umgebungsvariablen (.env)

install.sh füllt die hostabhängigen Werte selbst. Alles hier ist optional — UI-Einstellungen überstimmen die Env-Variablen.

Variable	Zweck
`TMDB_API_KEY`	Metadaten (deutsche Texte). Bequemer im Assistenten — beide Key-Arten gehen (v3-Schlüssel und v4-Token)
`OMDB_API_KEY`	zweite Metadaten-Quelle (Fallback)
`THETVDB_API_KEY`	Serien-Fallback
`WORKER_NAME`	Anzeigename des eingebauten Workers (Standard `rippy-hauptworker`)
`MAKEMKV_APP_KEY`	MakeMKV-Beta-Key. Bequemer im UI unter Einstellungen → System — gilt ab dem nächsten Rip, ohne Rebuild
`MAKEMKV_VERSION`	MakeMKV-Version für den Image-Build
`MAKEMKV_URL_BASE`	Download-Quelle für den Build. Normalerweise nichts eintragen — der Standard `makemkv.com/download` liefert (am 25.07.2026 mit HTTP 200 geprüft; `/download/old` gibt 525, ein web.archive.org-Schnappschuss 404)
`MAKEMKV_URL_FALLBACK`	zweite Quelle, die bei Fehlschlag der ersten automatisch versucht wird. Leer = keine. Trage nur ein, was du selbst geprüft hast: eine Adresse, die nicht liefert, lässt die Konfiguration gesund aussehen und den Build später scheitern
`MAKEMKV_DATA_HOST`	Host-Verzeichnis für MakeMKVs Daten (Standard `/srv/rippy/makemkv`) — Schlüsselspeicher, `KEYDB.cfg`, AACS-Dumps. Persistent, überlebt jeden Rebuild
`OPTICAL_SR` / `OPTICAL_SG`	Geräteknoten des Laufwerks. Findet `install.sh` selbst
`POSTGRES_PASSWORD`	DB-Passwort (Standard `rippy`)

Installation ohne install.sh (von Hand)

Falls du jeden Schritt selbst machen willst:

cp .env.example .env
mkdir -p /srv/rippy/media /srv/rippy/makemkv

# Laufwerksknoten ermitteln — die sg-Nummer ist je Host anders!
lsscsi -g            # zeigt Modell + zugehoerigen /dev/sgN
# in die .env: OPTICAL_SR=/dev/sr0  und  OPTICAL_SG=/dev/sgN

# Nur falls 'docker compose up' meldet:
#   "path ... is mounted on / but it is not a shared mount"
mount --bind /srv/rippy/media /srv/rippy/media
mount --make-rshared /srv/rippy/media   # neustart-fest als systemd-.mount-Unit

docker compose up -d --build

Braucht klassisches Linux-Docker mit SYS_ADMIN — nicht Docker Desktop, rootless oder Podman. Die Mount-Propagation ist nur für das Einhängen von NAS-Freigaben aus dem UI nötig; Freigaben auf dem Host einhängen geht immer.

Wie es intern funktioniert

Disc-Wache — ioctl-Polling, kein udev. Im Container läuft kein udevd, die udev-Datenbank ist leer; udevadm info liefert dort prinzipbedingt nichts.
Rip — MakeMKV, verlustfrei. Der einzige Weg durch AACS: HandBrake kann verschlüsselte Discs nicht lesen, deshalb sind es zwingend zwei Stufen.
Kompression — HandBrake als eigener Celery-Task auf eigener Queue, deshalb an andere Maschinen routbar.
Metadaten — Volume-Label → TMDB → OMDb → MyAnimeList, mit Ähnlichkeits-Bewertung und Korrektur-Popup an der Disc-Karte.

Härtung für exponierte Netze

Rippy ist bewusst Heimnetz-only: keine Authentifizierung, und Redis + PostgreSQL veröffentlichen Ports für Remote-Worker. Im vertrauten LAN ein akzeptierter Kompromiss — exponiere Rippy niemals ungeschützt an ein öffentliches Netz.

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

Updates der Werkzeuge

„Auf Updates prüfen" (Einstellungen → System) vergleicht mit makemkv.com und den offiziellen HandBrake-Releases, 12 h gecacht.

MakeMKV aktualisieren: MAKEMKV_VERSION=x.y.z in die .env, dann sudo ./install.sh. Der Beta-Key wechselt etwa monatlich (Forum-Thread t=1053) und wird im UI gepflegt — ohne Rebuild.

HandBrake kommt im Docker-Worker bewusst aus Debian (stabil, hinkt der offiziellen Version hinterher); der native Windows-Worker nutzt die aktuelle.

⚠️ Ein MakeMKV-Update hilft nicht gegen „The volume key is unknown" — MakeMKV liefert überhaupt keine Disc-Schlüssel mit, es holt sie zur Laufzeit, und die Linux-Version holt sie nie. Siehe 4K-UHD.

Entwicklung

CI („Ampel") läuft bei jedem Push: Ruff, pytest, Vite-Build. Es gibt genau einen Branch, main — 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 · Stand: SAVEPOINT.md

Languages

Python 63.7%

TypeScript 32.5%

Shell 2.5%

Dockerfile 1%

CSS 0.2%

README.md Unescape Escape

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