Hitonabi
29444805a8
Ampel / ampel (push) Successful in 28s
Beim Aufraeumen der VM-.env aufgefallen und nachgemessen (25.07.2026):
https://www.makemkv.com/download HTTP 200 <- Repo-Standard
https://www.makemkv.com/download/old HTTP 525 (Cloudflare)
web.archive.org-Schnappschuss HTTP 404 <- stand in der VM-.env
Die VM zeigte also auf eine KAPUTTE Adresse. Aufgefallen ist es nie, weil dort
die vendor/-Tarballs liegen und der Download-Zweig gar nicht erreicht wird.
Nimm die Tarballs weg, und jeder Bau scheitert mit 404 - waehrend die
Konfiguration gesund aussieht. Genau diese Sorte Fehler ist bei einer Uebergabe
teuer, weil sie erst beim Fremden zuschlaegt.
## Bereinigt (auf Commander-Wunsch, Sicherung liegt auf der VM)
.env.sicherung-vor-aufraeumen-20260725 angelegt, dann:
- MAKEMKV_URL_BASE raus -> es gilt der Compose-Standard, der liefert.
Von Docker gegengeprueft: MAKEMKV_URL_BASE: https://www.makemkv.com/download
- JWT_SECRET_KEY raus -> Ueberrest der in v3.4 ausgebauten Anmeldung, wirkungslos.
## Fallbacks BEHALTEN, aber echt gemacht (Commander-Vorgabe)
Vorher war der "Fallback" eine Zeile, die man von Hand eintragen musste - und
die hier ins Leere zeigte. Jetzt eine automatische Kette:
1. vendor/-Tarballs (braucht kein Netz, zuverlaessigster Weg)
2. MAKEMKV_URL_BASE
3. MAKEMKV_URL_FALLBACK (NEU, wird automatisch versucht wenn 2 versagt)
Stufe 3 ist ABSICHTLICH leer vorbelegt. Es gibt derzeit keine belegbare zweite
Quelle (siehe Messung oben), und eine einzutragen, die nicht liefert, waere
schlimmer als keine - genau das lag auf der VM vor. Wer eine eigene Quelle hat
(Spiegel im LAN), traegt sie ein und sie wird automatisch genutzt.
Scheitert alles, nennt die Fehlermeldung jetzt die beiden Wege, die
FUNKTIONIEREN, statt nur einen curl-Rueckgabewert zu hinterlassen.
## Geprueft, beide Zweige
- vendor-Pfad: Bau durch, 828 MB
- Download-Pfad: im FREMDEN Klon ohne Tarballs gebaut - Bau durch, 777 MB,
makemkvcon liegt unter /usr/local/bin/. Die leere Fallback-Stufe wird
korrekt uebersprungen, "Erste Quelle lieferte nicht" erschien nicht.
docker compose config validiert. README und .env.example nennen die gemessenen
HTTP-Antworten, damit niemand wieder eine 404-Adresse als Fallback eintraegt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
377 lines
16 KiB
Markdown
377 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. 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](#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` | 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`) |
|
||
|
||
</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)
|