Hitonabi
5d9be4d046
Ampel / ampel (push) Successful in 29s
- README: Media-Server-Ablage, Benachrichtigungen (Tabelle je Dienst), System/MakeMKV-Key, UHD-Arbeitsverzeichnis, neuer Abschnitt 'Rippy woanders bereitstellen' (beliebiger Docker-Host, was NICHT mitmuss). - ROADMAP: Etappe 13 (Universal-Komfort-Runde) dokumentiert, erledigte Punkte aus Etappe 11/12 abgehakt, priorisierter Ideen-Katalog. - KONZEPT: Abschnitt 10 'Fortschreibungen' — Media-Server-Neutralitaet erweitert das Jellyfin-Muss (keine Abweichung), Benachrichtigungen, udev->ioctl. - SAVEPOINT v3.2 mit dem Kernbefund: Ampel war seit 23.07. rot, stable hing 10 Commits zurueck (bcrypt/passlib + veralteter Test) — behoben. - AGENTS: Stand-Sektion entschlackt (Details leben im SAVEPOINT). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
9.4 KiB
9.4 KiB
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) | ✔ M | ||
| Rate-Limiting (100/min pro API-Key) | ✔ 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:
- udev-Event → System-Dämon (unabhängig vom API-Container) erkennt Einwurf.
- Device-Resolver (udev-basiert) ermittelt UUID/Serial-Nummer des Laufwerks, erzeugt Symlink
/dev/disc/<uuid>. - Job-Erstellung → Dämon erstellt Celery-Task, übergibt Device-Pfad und Disc-Typ.
- Typ-Erkennung (CD/DVD/Blu-ray) → Auswahl des Ripping-Pfads.
- METADATEN-Lookup im VORFELD:
- DVD/Blu-ray:
makejunglesliest 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.
- DVD/Blu-ray:
- 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).
- CD:
- Post-Processing & Jellyfin-Formatierung:
- Dateien in Jellyfin-konformer Ordnerstruktur.
- NFO-Dateien im Kodi/NFO-Schema.
- Poster/Backdrop/Fanart von TMDB.
- Multi-Disc-Erkennung: Release-Group-Resolver prüft weitere Discs.
- Status-Push: Worker sendet Fortschritt an UI.
- 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: truefür API/Worker (keine Schreibrechte außer tmpfs)tmpfsfü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
- Dashboard — Echtzeit-Kacheln mit Job-Status, Queue-Übersicht.
- Job-Verlauf — Tabelle aller Jobs mit Status, Fortschrittsbalken.
- Metadaten-Preview — Nach udev-Erkennung: Titel, Jahr, Cover, Trackliste, Confidence-Score.
- Job-Detail — Live-Log-Ausgabe, Fortschritt, "Abort".
- Ergebnis-View — Liste gerippter Dateien, Metadaten, Jellyfin-Ordnerstruktur.
- Einstellungen — API-Keys, Transcoding, Backup-Pfade, Jellyfin-Config.
- 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 |
| 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
mediaServerauf 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.