Cloudflare drosselte am 24.07. wiederholt GENAU die BuildKit-Downloads (ausserhalb des Builds gingen dieselben URLs mit 200 durch) — drei Deploy-Anlaeufe starben an curl exit 22. Zwei Gegenmittel: - curl --retry 5 --retry-delay 15 --retry-all-errors im Download-RUN (curl-Doku; --retry-all-errors wiederholt auch bei 4xx/5xx) - Lokal-Mirror-Rezept im Kommentar: Tarballs von Hand laden, per nginx:alpine servieren, MAKEMKV_URL_BASE aufs LAN zeigen — so wurde der 1.18.4-Build auf der VM letztlich gebaut. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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 # JWT_SECRET_KEY eintragen (openssl rand -hex 32)
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
Standard ist /dev/sr0 (+ /dev/sg1 für den Worker — MakeMKV spricht
Laufwerke über die SCSI-Generic-Schicht an). Andere Geräte? Lege eine
docker-compose.override.yml an:
services:
api:
devices: ["/dev/sr1:/dev/sr0"]
worker:
devices: ["/dev/sr1:/dev/sr0", "/dev/sg2:/dev/sg1"]
Welche sg-Nummer dein Laufwerk hat, verrät lsscsi -g oder
ls -la /sys/class/scsi_generic/.
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
- 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).
- 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. 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.
- 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.
- 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.
- 4K-UHD: braucht ein LibreDrive-fähiges Laufwerk (MakeMKV-Forum:
„Ultimate UHD Drives Flashing Guide"). Normale BD/DVD gehen mit jedem
Laufwerk. ⚠️ 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
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. Nur die MakeMKV-Version
steckt im Image: docker compose build worker && docker compose up -d worker.
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: GPU-Maschine im Netz als Transcode-Worker
Die Kompression läuft als eigener Celery-Task auf der Queue transcode —
JEDE Maschine im Netz kann sie übernehmen (siehe
deploy/remote-transcode-worker.yml). Ohne Zusatz-Worker macht der
eingebaute CPU-Worker alles selbst — Rippy bleibt All-in-one.
Umgebungsvariablen (.env)
| Variable | Pflicht | Zweck |
|---|---|---|
JWT_SECRET_KEY |
✔ | Signierschlüssel (openssl rand -hex 32) |
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 |
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:
- Linux (x86_64) mit Docker + Compose-Plugin.
- 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. - Ablage-Basis anlegen:
mkdir -p /srv/rippy/media(oder Pfad indocker-compose.ymlanpassen — muss ein rshared-fähiger Bind sein).
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.
Entwicklung
CI („Ampel") läuft bei jedem Push: Ruff, pytest, Vite-Build. Grün auf
main wird automatisch auf stable befördert — deploye von stable.
Regeln für Beiträge: AGENTS.md · Konzept: KONZEPT.md ·
Fahrplan: ROADMAP.md