Hitonabi
e032a9df1c
- jobs.meta (Migration in beiden db.py): Disc-Metadaten wandern in den Job —
Quelle fuer Job-Detail-Popup (GET /jobs/{id}/detail), Ordner-Benennung, NFO.
- medien.py (Worker, mit Tests): Zielordner 'Titel (Jahr)' statt Job-UUID;
movie.nfo/tvshow.nfo (Kodi-Schema, kodi.wiki/view/NFO_files) + poster.jpg
fuer jellyfin/emby/kodi; plex nur Benennung; Kollision -> Job-ID-Suffix.
- notify.py (identisch in API+Worker, mit Tests): Webhook bei Job-Ende —
Discord ({content}, discord.com/developers), Slack ({text},
api.slack.com/messaging/webhooks), ntfy (Rohtext + ?title=, docs.ntfy.sh),
generisches JSON. Vorher war das Setting ein Placebo: nichts sendete je.
POST /notifications/test beweist die Anbindung sofort.
- mounts.py: NT_STATUS-Fehler -> handelbarer Klartext (ACCESS_DENIED ohne
Credentials = Gast-Abfrage verweigert), Timeout-Meldung, mount-Hinweis
bei error(13). Mit Tests.
- tasks.py: Platz-Check per Disc-Groesse (ioctl BLKGETSIZE64) VOR dem Rip;
Arbeitsverzeichnis workDir (unter /app/media, z.B. NAS) statt fix
/app/temp/raw — 4K-UHD-Rohdaten (bis 100 GB) sprengen sonst die VM-Platte;
MakeMKV-Key aus UI-Settings (~/.MakeMKV/settings.conf, Format wie
entrypoint.sh) gilt ab dem naechsten Rip ohne Rebuild.
- caps.py: Werkzeug-Versionen (MakeMKV aus ENV MAKEMKV_VERSION im Image,
makemkvcon hat keinen --version-Schalter lt. usage.txt; HandBrakeCLI
--version lt. handbrake.fr/docs) + Key-Quelle; workers.info-Spalte.
- /browse liefert jetzt auch DATEIEN (Name + Groesse) — der 'leere'
bluray-Ordner war voll, der Browser zeigte nur Unterordner.
- GET /system/info: Versionen, Plattenplatz, Key-/Webhook-Status.
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.
- Rip (MakeMKV, verlustfrei — der einzige Weg durch AACS): Ziel wählst du beim Start (Filme/Serien/Musik/eigener Pfad, inkl. Netzwerk-Ziele). 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.
- 4K-UHD: braucht ein LibreDrive-fähiges Laufwerk (MakeMKV-Forum: „Ultimate UHD Drives Flashing Guide"). Normale BD/DVD gehen mit jedem Laufwerk.
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.
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 — alternativ im UI/Wizard eintragbar |
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 |
MAKEMKV_URL_BASE |
optional | alternative Download-Quelle für den Image-Build |
UI-Einstellungen (Wizard/Settings) überstimmen die Env-Variablen.
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