Hitonabi
ca91e5b693
Ampel / ampel (push) Successful in 28s
Commander-Rueckmeldung: "Das Docker Deployment ist mir zu kompliziert." Zu
Recht - die Installation war eine Checkliste aus sechs Schritten, von denen
zwei nur mit Fachwissen zu schaffen waren.
## Neu: sudo ./install.sh
Nimmt genau die Schritte ab, an denen man scheitern konnte:
1. Prueft Voraussetzungen (Linux, Docker, Compose) und nennt bei jedem Mangel
den Installationsbefehl.
2. FINDET DAS LAUFWERK SELBST. Das war der schlimmste Punkt: MakeMKV braucht
ZWEI Geraeteknoten, und die sg-Nummer ist je Host anders. Das Skript gleicht
sie ueber die SCSI-Adresse in /sys ab statt zu raten. Auf der VM
gegengeprueft: sr0 -> 3:0:0:0, sg1 -> 3:0:0:0, also dasselbe Geraet -
korrekt als /dev/sr0 + /dev/sg1 erkannt.
3. Legt Ablage- und MakeMKV-Verzeichnis an.
4. Richtet die Mount-Propagation ein UND macht sie per systemd-.mount-Unit
neustart-fest. Vorher stand in der README nur "reboot-fest persistieren" -
ohne zu sagen wie; nach einem Reboot scheiterte das Einhaengen von
NAS-Freigaben aus dem UI stillschweigend.
5. Schreibt die .env, ueberschreibt aber NIE einen bestehenden Wert.
6. Baut und startet, und nennt bei Fehlschlag die drei haeufigsten Ursachen
mit Diagnosebefehl.
Wiederholbar (mehrfach ausfuehren aendert nichts kaputt) und damit auch der
Update-Weg: git pull && sudo ./install.sh
## Zwei Fallgruben, die beim Testen auffielen - beide meine eigenen
- --nur-pruefen verlangte root und brach ab. Ein Pruef-Modus, der nichts
aendert, darf daran nicht scheitern - sonst kann man vor der Installation
nicht nachsehen, ob alles passt. Behoben.
- .env.example hatte OPTICAL_SG=/dev/sg1 UNKOMMENTIERT vorbelegt. Damit haette
der Installer den erkannten Wert nicht eingetragen ("steht schon drin") und
auf jedem fremden Host still eine kaputte Konfiguration hinterlassen - genau
das, was er verhindern soll. Beide Geraetezeilen sind jetzt auskommentiert;
Compose hat ohnehin Vorgaben. Dazu eine Gegenprobe im Skript: zeigt ein
wirksamer Wert auf ein Geraet, das es hier nicht gibt (".env von einem
anderen Rechner"), wird das benannt statt kryptisch von Docker gemeldet.
## README neu aufgebaut
Vorher 293 Zeilen, in denen der Schnellstart zwischen lsscsi, sg-Knoten,
USB-Passthrough und mount --make-rshared begraben war. Jetzt: Installation in
zwei Zeilen oben, dann eine Tabelle "Wenn etwas nicht geht" mit den vier
Faellen, die praktisch alles abdecken. Alles Technische steht darunter in
aufklappbaren Abschnitten - inklusive der Handarbeits-Variante fuer die, die
sie wollen.
NEU und ausdruecklich gewuenscht: Abschnitt "Rippy schneller machen" mit dem
VM-CPU-Typ. Erklaert, warum Virtualisierer eine generische CPU ohne AVX2
geben, was das kostet (gemessene 28-55 h je 4K-Film), die genauen Schritte in
Proxmox (herunterfahren - Hardware/Processors/Type auf 'host' - starten, bzw.
qm set <vmid> --cpu host), warum ein Neustart von innen NICHT genuegt, und wie
man nachprueft: Rippy zeigt die Vektorbefehle seit v3.14 selbst an. Dazu der
Nachteil (keine Live-Migration auf andere CPUs) und die Alternative x86-64-v3
fuer Cluster.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
376 lines
16 KiB
Markdown
376 lines
16 KiB
Markdown
# 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, komplett
|
||
in Docker, komplett lokal — keine Cloud, keine Telemetrie.
|
||
|
||
---
|
||
|
||
## Installation
|
||
|
||
Du brauchst: einen **Linux-Rechner mit Docker** und ein **optisches Laufwerk**.
|
||
|
||
```bash
|
||
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:
|
||
|
||
```bash
|
||
./install.sh --nur-pruefen
|
||
```
|
||
|
||
<details>
|
||
<summary><b>Was <code>install.sh</code> für dich macht</b> (aufklappen)</summary>
|
||
|
||
Es nimmt genau die Schritte ab, an denen man vorher scheitern konnte:
|
||
|
||
1. **Prüft die Voraussetzungen** — Linux, Docker, Compose. Fehlt etwas, steht
|
||
der Installationsbefehl dabei.
|
||
2. **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.)
|
||
3. **Legt die Verzeichnisse an** (`/srv/rippy/media` für die Filme,
|
||
`/srv/rippy/makemkv` für MakeMKVs Daten).
|
||
4. **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.
|
||
5. **Schreibt die `.env`** mit den gefundenen Werten. Bestehende Werte werden
|
||
**nie** überschrieben.
|
||
6. **Baut und startet** alles.
|
||
|
||
Das Skript ist **wiederholbar**: mehrmals ausführen ändert nichts kaputt. Es
|
||
ist auch der Update-Weg — siehe unten.
|
||
|
||
</details>
|
||
|
||
### Aktualisieren
|
||
|
||
```bash
|
||
git pull && sudo ./install.sh
|
||
```
|
||
|
||
---
|
||
|
||
## Wenn etwas nicht geht
|
||
|
||
Die vier Fälle, die praktisch alles abdecken:
|
||
|
||
| Symptom | Ursache & Lösung |
|
||
|---|---|
|
||
| **„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. Tarballs von makemkv.com/download händisch nach `docker/worker/vendor/` legen, dann `sudo ./install.sh` erneut — der Build nimmt sie dann von dort. |
|
||
| **Kompression läuft ewig** | Deine CPU kann kein AVX2. Rippy zeigt das jetzt selbst an (Einstellungen → System, „Vektorbefehle"). Siehe **[Rippy schneller machen](#rippy-schneller-machen)**. |
|
||
| **4K-UHD: „The volume key is unknown"** | Erwartbar und **kein Fehler in Rippy**. Siehe **[4K-UHD](#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):**
|
||
|
||
1. VM **herunterfahren.** Ein Neustart von innen genügt nicht — Proxmox
|
||
übernimmt Hardware-Änderungen nur bei einem echten Stopp.
|
||
2. Im Web-UI: VM auswählen → **Hardware** → **Processors** → Doppelklick →
|
||
**Type** auf **`host`** stellen → OK.
|
||
Oder auf der Proxmox-Konsole:
|
||
```bash
|
||
qm set <vmid> --cpu host
|
||
```
|
||
3. 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`.
|
||
|
||
<details>
|
||
<summary>Nachteile von <code>host</code> — der Vollständigkeit halber</summary>
|
||
|
||
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).
|
||
|
||
</details>
|
||
|
||
**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](#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):
|
||
|
||
1. MakeMKV auf einem **Windows-PC** installieren (gleicher Beta-Key).
|
||
2. Laufwerk anstecken, Disc **einmal öffnen** — dabei lädt MakeMKV die
|
||
Schlüssel nach.
|
||
3. 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
|
||
|
||
<details>
|
||
<summary><b>Umgebungsvariablen (.env)</b></summary>
|
||
|
||
`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` | alternative Download-Quelle für den Build |
|
||
| `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`) |
|
||
|
||
</details>
|
||
|
||
<details>
|
||
<summary><b>Installation ohne install.sh (von Hand)</b></summary>
|
||
|
||
Falls du jeden Schritt selbst machen willst:
|
||
|
||
```bash
|
||
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.
|
||
|
||
</details>
|
||
|
||
<details>
|
||
<summary><b>Wie es intern funktioniert</b></summary>
|
||
|
||
1. **Disc-Wache** — ioctl-Polling, kein udev. Im Container läuft kein udevd,
|
||
die udev-Datenbank ist leer; `udevadm info` liefert dort prinzipbedingt
|
||
nichts.
|
||
2. **Rip** — MakeMKV, verlustfrei. Der einzige Weg durch AACS: HandBrake kann
|
||
verschlüsselte Discs nicht lesen, deshalb sind es zwingend zwei Stufen.
|
||
3. **Kompression** — HandBrake als eigener Celery-Task auf eigener Queue,
|
||
deshalb an andere Maschinen routbar.
|
||
4. **Metadaten** — Volume-Label → TMDB → OMDb → MyAnimeList, mit
|
||
Ähnlichkeits-Bewertung und Korrektur-Popup an der Disc-Karte.
|
||
|
||
</details>
|
||
|
||
<details>
|
||
<summary><b>Härtung für exponierte Netze</b></summary>
|
||
|
||
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.
|
||
|
||
</details>
|
||
|
||
<details>
|
||
<summary><b>Updates der Werkzeuge</b></summary>
|
||
|
||
„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](#4k-uhd).
|
||
|
||
</details>
|
||
|
||
---
|
||
|
||
## 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](AGENTS.md) · Konzept: [KONZEPT.md](KONZEPT.md) ·
|
||
Fahrplan: [ROADMAP.md](ROADMAP.md) · Stand: [SAVEPOINT.md](SAVEPOINT.md)
|