fix(transcode): "Abbrechen" wirkt sofort statt erst beim naechsten Prozent

Fund des Commanders am laufenden Akira-Job (Nachtrag im vorigen Savepoint):
Job stand auf 'canceling', HandBrake lief weiter. Gemessen 3,4 Minuten
zwischen Anforderung (18:30:17) und Bestaetigung (18:33:38) - bei langsamerem
Fortschritt entsprechend mehr.

Ursache genau wie dort beschrieben: Der Abbruch wurde nur in
datei_fortschritt geprueft, und diese Closure stieg oben sofort wieder aus,
wenn sich die Prozentzahl nicht geaendert hatte ("if gesamt == letzter[0]:
return"). Bei einem Prozent je halber Stunde hing der Abbruch also an einem
Ereignis, das eine halbe Stunde lang nicht eintrat.

run_handbrake bekommt jetzt einen eigenen abbruch_cb neben progress_cb -
dasselbe Muster, das run_makemkv schon fuer log_cb benutzt, und aus
demselben Grund: der Fortschritts-Kanal verwirft Aufrufe. Er wird bei JEDER
Ausgabezeile aufgerufen und im Worker auf 5 s gedrosselt.

Nebeneffekt, der genauso wichtig ist: Er greift auch waehrend des
Scan-Durchlaufs, der ueberhaupt keine Encode-Prozente liefert. Dort war ein
Abbruch vorher grundsaetzlich unmoeglich - und seit die Prozent-Regex den
Scan korrekt ignoriert, waere das sonst sogar schlimmer geworden.

Die Leseschleife ist als _handbrake_schleife() herausgezogen, damit die
Reihenfolge (Abbruch VOR Fortschritt) ohne echtes HandBrake pruefbar ist.
Der Test belegt: zwei Scan-Zeilen genuegen fuer den Abbruch, es muss NICHT
auf eine Encode-Zeile gewartet werden.

Savepoint nachgezogen: Der Encode laeuft nicht mehr, ein Deploy ist
gefahrlos moeglich, und die alte "SOFORT ENTSCHEIDEN"-Passage (Platte
laeuft voll, wenn der Job fertig wird) ist damit gegenstandslos. Neu darin:
die drei Wege fuer UHD, und die Warnung, dass eine /proc-Suche nach
"HandBrake" die eigene Shell mittrifft - zwei Fehlalarme in dieser Sitzung.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

.env.example

@@ -33,6 +33,13 @@ OMDB_API_KEY=
 # nächsten Rip, ohne Neustart, und schlägt diesen Env-Wert).
 MAKEMKV_APP_KEY=
 
+# MakeMKV-Datenverzeichnis auf dem HOST (bleibt über Rebuilds hinweg erhalten).
+# Hier hinein gehört die KEYDB.cfg für 4K-UHD-Discs; hier landen auch die
+# AACS-Dumps fehlgeschlagener Discs. Beides ist ab Einstellungen → System
+# im Browser erreichbar — dieser Pfad ist nur für den Fall, dass du die
+# Dateien direkt auf der Maschine anfassen willst.
+#MAKEMKV_DATA_HOST=/srv/rippy/makemkv
+
 # MakeMKV-Version fürs Worker-Image (Einstellungen → System meldet Updates).
 # Update: Version hier anheben, dann auf der Rippy-Maschine
 #   docker compose build worker && docker compose up -d worker

AGENTS.md

@@ -55,10 +55,32 @@ Bibliotheks-APIs: `--help`/Doku prüfen und die Fundstelle im Commit nennen.
 - Kein Proxmox-LXC-Nesting-Workaround — das Projekt lebt bewusst in normalem Docker.
 - Kein ARM-Fork — Rippy ist ein Eigenbau von Grund auf.
 
-## Aktueller Stand (24.07.2026)
+## Aktueller Stand (25.07.2026)
 
 - ✅ **E2E bewiesen (v3.1):** BD-50 komplett durch die Kette (43 GB → 4,8 GB)
 - ✅ **Etappe 13 (v3.2):** Universal-Komfort-Runde — Media-Server-Integration,
   echte Benachrichtigungen, SMB-Klartext-Fehler, UHD-Arbeitsverzeichnis,
   MakeMKV-Key via UI, Job-Detail-Popup, Toast-Feedback, Ampel-Blocker behoben
+- ✅ **Etappe 17 (v3.10):** 4K-UHD-Disc-Schlüssel — persistentes
+  MakeMKV-Datenverzeichnis + `KEYDB.cfg` im UI
+- ✅ **Etappe 18 (v3.11):** 4K-UHD gelöst — `makemkvcon` holt Schlüssel
+  unter Linux nie, unter Windows schon; Schlüsselspeicher übernehmbar.
+  Akira-UHD geht auf der VM auf (`TCOUNT:5`, bewiesen)
+- ✅ **Etappe 19 (v3.14):** Durchsicht Frontend/Backend — vier Placebos weg
+  (Fortschritt log, Auswurf tat nichts, „Alle Tracks" konnte nichts, Encoder
+  wurden behauptet statt gemessen), Zombie-Erkennung gebaut, Pfad-Prüfung
+  gehärtet, und der Platten-Schutz aus `c065967` als **unwirksam** entlarvt
 - 📝 **Details immer in SAVEPOINT.md** — diese Sektion nennt nur die Etappe
+
+## Was diese Sitzungen wiederholt gekostet hat
+
+**Nicht aus einem Zustandswert auf einen Mechanismus schließen.** Vorgefallen:
+aus „kein Schlüssel da" → „Server abgeschaltet" (falsch), aus Status
+`transcoding` → „Celery hat neu zugestellt" (falsch), aus `progress=99` →
+„Altwert aus dem Absturz" (falsch — ein Bug), aus gleichem `st_dev` →
+„`os.rename` funktioniert" (falsch — der Kernel vergleicht den Mount).
+Jedes Mal hätte eine Messung von unter einer Minute gereicht.
+
+**Und die Umkehrung gilt genauso:** gleiches `st_dev` heißt NICHT gleicher
+Mount. Wo eine Eigenschaft ausprobierbar ist, probiere sie aus, statt sie
+vorherzusagen.

KONZEPT.md

@@ -127,6 +127,7 @@ Ein modular aufgebautes System, das bei Disc-Einwurf automatisch den Typ erkennt
 | Risiko | Status | Behandlung |
 |--------|--------|------------|
 | MakeMKV-Beta-Key-Management | Gelöst | Key-Erneuerung als Cron-Job; DMCA-Ausnahme in DE |
+| **Disc-Schlüssel für 4K-UHD (AACS 2.0)** | **Gelöst mit Handgriff** | Am 25.07.2026 auf beiden Maschinen gemessen: `makemkvcon` unter **Linux** ruft Disc-Schlüssel nie ab (kein einziger Verbindungsversuch, mit leerem wie gefülltem Speicher, mit und ohne `--noscan`, `dev:` wie `disc:`), die **Windows**-Version tut es (Meldung 3338). Rippy stellt ein persistentes Datenverzeichnis bereit und nimmt den Schlüsselspeicher `_private_data.tar` einer Windows-Installation sowie ersatzweise eine `KEYDB.cfg` entgegen; damit ging Akira UHD auf der VM auf. Rippy liefert, lädt und verteilt KEINE Schlüssel. Siehe §10 (25.07.2026) |
 | 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 |
@@ -182,6 +183,23 @@ Ein modular aufgebautes System, das bei Disc-Einwurf automatisch den Typ erkennt
   passlib/bcrypt-Abhängigkeit hat die CI-Ampel gebrochen. Rate-Limiting
   (pro IP) bleibt. Wer Rippy je nach außen öffnet, stellt einen
   Reverse-Proxy mit eigener Auth davor (z. B. Authelia/Caddy basicauth).
+- **25.07.2026 — 4K-UHD-Disc-Schlüssel: Rippy stellt Platz bereit, keine
+  Schlüssel:** Das Muss-Feature „MakeMKV-Ripping (lossless)" bleibt
+  unverändert; ergänzt wird nur ein **persistentes MakeMKV-Datenverzeichnis**
+  (`MAKEMKV_DATA_HOST`, im Worker `/root/.MakeMKV`, in der API
+  `/app/makemkv-data`) samt Bedienung im UI. Begründung: Am 25.07.2026 auf
+  BEIDEN Maschinen nachgemessen — `makemkvcon` unter Linux ruft Disc-Schlüssel
+  nie ab, die Windows-Version tut es. (Erste Fassung dieses Eintrags behauptete,
+  MakeMKVs Schlüssel-Kanal sei abgeschaltet; das war falsch und wurde am selben
+  Tag richtiggestellt.) Rippy nimmt deshalb den Schlüsselspeicher
+  `_private_data.tar` einer MakeMKV-Installation entgegen und ersatzweise eine
+  `KEYDB.cfg`. **Rippy liefert und verteilt KEINE Disc-Schlüssel und
+  lädt auch keine herunter** — es hält nur den Platz für Dateien bereit,
+  die der Nutzer selbst mitbringt, zeigt ehrlich an, was dort liegt, und gibt
+  die AACS-Dumps heraus, die MakeMKV ohnehin selbst schreibt. Das ist genau
+  die Grenze, die `docker/api/makemkv_key.py` in Zeile 14 zieht: die
+  kostenlose Beta-LIZENZ der Software ist etwas anderes als das
+  Entschlüsseln oder Verteilen von Disc-Schlüsseln.
 - **24.07.2026 — Serien-Flow:** Staffel-Ablage <Serie>/Season NN plus
   Episoden-Zuordnung per Laufzeitabgleich (TMDB) — erfüllt Etappe-12-Ziel
   „Serien-Episoden-Erkennung" in der ersten Ausbaustufe (nur bei

README.md

@@ -63,7 +63,13 @@ NICHT als emuliertes CD-ROM (`media=cdrom`), das kann keine SCSI-Kommandos.
    per Laufzeitabgleich (TMDB) automatisch zu „Serie S01E02.mkv" benannt
    (nur bei eindeutiger Zuordnung — sonst bleiben die Namen, mit Log).
 3. **Kompression** (HandBrake, eigener Job auf eigener Queue): x265/x264,
-   Preset im UI wählbar; Rohdatei wird erst nach Erfolg gelöscht
+   **je Disc-Typ ein eigenes Preset** (Einstellungen → Verarbeitung) —
+   Rippy kennt den Typ und wählt selbst. Wichtig, weil ein 1080p-Preset
+   eine 4K-UHD stillschweigend herunterrechnet und ein 1080p-Preset eine
+   DVD sinnlos hochskaliert. Sind die drei Felder nie gespeichert worden,
+   gilt weiter das alte allgemeine Preset — Bestandsinstallationen ändern
+   ihr Verhalten also nicht von selbst.
+   Rohdatei wird erst nach Erfolg gelöscht
    („Original behalten" als Option). Fehlgeschlagene Kompressionen lassen
    sich ohne Neu-Rip neu anstoßen.
 4. **Media-Server-Ablage**: Unter Einstellungen → Ripping (oder im
@@ -74,9 +80,34 @@ NICHT als emuliertes CD-ROM (`media=cdrom`), das kann keine SCSI-Kommandos.
    nur die Benennung. **Jellyfin/Emby**: Server-URL + API-Key eintragen,
    dann stößt Rippy nach jedem fertigen Rip sofort einen Bibliotheks-Scan
    an — Disc rein, Film erscheint im Server.
-5. **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
+5. **4K-UHD**: braucht **zwei** Dinge — ein LibreDrive-fähiges Laufwerk
+   (MakeMKV-Forum: „Ultimate UHD Drives Flashing Guide") **und** einen
+   passenden Disc-Schlüssel. Normale BD/DVD gehen mit jedem Laufwerk und
+   ohne Schlüssel-Datei.
+   **Der Schlüssel ist heute die eigentliche Hürde — und zwar 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".
+   Die Ursache:
+   **`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 mit 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:** MakeMKV einmal auf einem Windows-PC die Disc
+   öffnen lassen und die dabei gefüllte Datei `_private_data.tar` bei
+   Rippy unter **Einstellungen → System** hochladen (siehe unten). Für
+   Pressungen, die auch MakeMKV nicht kennt, bleibt die **`KEYDB.cfg`**
+   als Notnagel.
+   ⚠️ **Rippy liefert keine Schlüssel mit, lädt keine herunter und
+   verteilt keine.** Rippy stellt nur den Platz für eine Datei bereit, die
+   du selbst mitbringst, und zeigt dir ehrlich an, was dort liegt.
+   ⚠️ 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
@@ -106,7 +137,7 @@ fehlgeschlagen, abgebrochen) und erkennt den Dienst an der URL selbst:
 | 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 & Updates
+## System, MakeMKV-Beta-Key, Disc-Schlüssel & Updates
 
 **Einstellungen → System** zeigt die Werkzeug-Versionen jedes Workers
 (MakeMKV, HandBrake), den Key-Status und den freien Speicherplatz. Der
@@ -114,11 +145,47 @@ 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`.
 
+**Disc-Schlüssel für 4K-UHD** — im selben Tab, nur für UHD nötig. Der
+Hauptweg zuerst:
+
+- **Schlüsselspeicher (`_private_data.tar`)**: Rippy zeigt, **wie viele
+  Disc-Schlüssel** dieser Worker kennt. Steht dort 0, scheitert jede
+  unbekannte UHD-Disc.
+  **So füllst du ihn:** MakeMKV auf einem Windows-PC installieren
+  (gleicher Beta-Key), Laufwerk anstecken, Disc einmal öffnen — dabei lädt
+  MakeMKV die Schlüssel nach. Dann in MakeMKV unter *Preferences →
+  General* das „MakeMKV data directory" nachschlagen und die Datei
+  `_private_data.tar` daraus hier hochladen. Wirkt ab dem nächsten Rip;
+  für neue Discs 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.
+- **`KEYDB.cfg`** (Notnagel): nur nötig, wenn eine Pressung auch mit
+  gefülltem Speicher nicht aufgeht, MakeMKV sie also selbst nicht kennt.
+  Hochladen, Status und Entfernen genau wie oben.
+- **AACS-Dumps herunterladen**: MakeMKV legt bei jeder unbekannten Disc
+  selbst einen Dump ab. Genau den braucht man, wenn man im MakeMKV-Forum
+  um den Schlüssel für eine neue Pressung bittet — hier holst du ihn dir
+  aus dem Container, ohne SSH.
+
+Der Beta-Key ist die **Lizenz für die Software**, der Schlüsselspeicher
+und die `KEYDB.cfg` sind **Disc-Schlüssel** — zwei völlig verschiedene
+Dinge. **Rippy liefert und lädt keine Disc-Schlüssel**, es hält nur ein
+persistentes Verzeichnis dafür bereit (`MAKEMKV_DATA_HOST`, siehe Tabelle
+unten) — rebuild-fest, damit deine Dateien einen
+`docker compose build` überleben. Der Schlüsselspeicher ist der
+Zwischenspeicher **deiner eigenen** MakeMKV-Installation.
+
 **Updates:** „Auf Updates prüfen" vergleicht mit makemkv.com und den
 offiziellen HandBrake-Releases (12 h gecacht). MakeMKV-Update ohne
 Code-Änderung: `MAKEMKV_VERSION=x.y.z` in die `.env`, dann
-`docker compose build worker && docker compose up -d worker` — neue
-Versionen bringen auch die neueste Disc-Schlüssel-Datenbank mit.
+`docker compose build worker && docker compose up -d worker`.
+⚠️ **Richtigstellung (25.07.2026):** Hier stand früher, neue MakeMKV-
+Versionen brächten „auch die neueste Disc-Schlüssel-Datenbank mit". Das
+ist widerlegt — MakeMKV liefert überhaupt keine Disc-Schlüssel mit, es
+holt sie zur Laufzeit. Und die Linux-Version holt sie nie. Ein Update
+lohnt für Programmfehler und neue Laufwerke, hilft aber NICHT gegen „The
+volume key is unknown". Dafür brauchst du den Schlüsselspeicher (siehe
+oben).
 HandBrake kommt im Docker-Worker bewusst aus Debian (stabil, hinkt der
 offiziellen Version hinterher); der native Windows-Worker nutzt die
 aktuelle Version direkt.
@@ -153,6 +220,7 @@ bleibt All-in-one.
 | `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 |
+| `MAKEMKV_DATA_HOST` | optional | Host-Verzeichnis für MakeMKVs Daten (Default `/srv/rippy/makemkv`) — hier liegen dein Schlüsselspeicher `_private_data.tar`, eine etwaige `KEYDB.cfg` und die AACS-Dumps; persistent, überlebt jeden Rebuild |
 | `OPTICAL_SR` | je Host | Host-Pfad des CD-ROM-Knotens (Default `/dev/sr0`) — siehe „Laufwerk anpassen" |
 | `OPTICAL_SG` | je Host | Host-Pfad des sg-Knotens des Laufwerks (Default `/dev/sg1`; oft `/dev/sg0`) |
 | `POSTGRES_PASSWORD` | optional | DB-Passwort (Default `rippy`) — für exponierte Umgebungen ein starkes Passwort setzen |
@@ -181,6 +249,12 @@ Voraussetzungen auf dem Ziel-Host:
    ```
    (reboot-fest als systemd-`.mount`-Unit persistieren.) Braucht einen klassischen
    Linux-Docker-Host mit `SYS_ADMIN` — nicht Docker-Desktop/rootless/Podman.
+4. MakeMKV-Datenverzeichnis anlegen: `mkdir -p /srv/rippy/makemkv` (oder
+   eigenen Pfad über `MAKEMKV_DATA_HOST` in der `.env`). Dort liegen
+   MakeMKVs Programmzustand, die AACS-Dumps und — falls du 4K-UHD rippst —
+   dein Schlüsselspeicher (`_private_data.tar`) sowie eine etwaige
+   `KEYDB.cfg`. Das Verzeichnis gehört dem Host, damit ein
+   `docker compose build` deine Dateien nicht wegwirft.
 
 Dann wie im Schnellstart: klonen, `.env` füllen, `docker compose up -d
 --build`, `http://<host>` öffnen — der Einrichtungs-Assistent führt durch

ROADMAP.md

@@ -414,6 +414,162 @@ irrelevant und kann komplett raus."
 
 ---
 
+## Etappe 17 (25.07.2026): 4K-UHD-Schlüssel (KEYDB.cfg)
+
+**Quelle:** Messung am 25.07. live auf der Rippy-VM im Worker-Container.
+Eine 4K-UHD (Akira, MKB v76, Pressung Dezember 2020) scheitert an „The
+volume key is unknown for this disc" — obwohl makemkvcon „Using LibreDrive
+mode (v06.3)" und „Using direct disc access mode" meldet, die Disc liest
+und den AACS-Dump ablegt (Meldung 3332). Das Debug-Log geht ohne einen
+einzigen Netz-Versuch von „Loaded content hash table" direkt auf den
+Fehler; `_private_data.tar` enthielt nur die Index-Datei und keine einzige
+`hkd_*.bin`; auch mit gelöschter `update.conf` (Meldung 5074 belegt den
+Web-Kontakt) und `app_UpdateEnable = "1"` kam kein Schlüssel; die
+Forum-Schlüssel-Server `hkdata.fairuse.org` und `hkdata.crabdance.com`
+lösen weltweit nicht mehr auf. **Fazit: Ein MakeMKV-Update löst das
+nicht** (das behauptete v3.3 — dort richtiggestellt). Der einzige heute
+funktionierende Weg ist eine `KEYDB.cfg` im MakeMKV-Datenverzeichnis.
+
+> ⚠️ **Nachtrag am selben Tag (siehe Etappe 18): Die letzte Folgerung war
+> falsch.** Die beiden toten Hostnamen stammen aus alten Forumsbeiträgen und
+> werden von MakeMKV längst nicht mehr benutzt — der Dienst lebt. Richtig
+> ist: `makemkvcon` unter **Linux** fragt nie nach Schlüsseln, die
+> **Windows**-Version schon. Alles hier Gebaute bleibt richtig und nötig,
+> nur die `KEYDB.cfg` ist nicht der Haupt-, sondern der Ersatzweg.
+
+**Gebaut:**
+- [x] **Persistentes Datenverzeichnis**: `${MAKEMKV_DATA_HOST:-/srv/rippy/makemkv}`
+      vom Host gemountet — Worker `/root/.MakeMKV`, API `/app/makemkv-data`,
+      beide mit `MAKEMKV_DATA_DIR`. `KEYDB.cfg` und AACS-Dumps überleben
+      jeden Rebuild. `.env.example` erklärt die Variable.
+- [x] **entrypoint.sh entschärft**: `settings.conf` wird ergänzt statt
+      überschrieben (der Beta-Key hatte sonst alles andere gelöscht),
+      `app_UpdateEnable = "1"` gesetzt.
+- [x] **Zwillings-Modul `makemkv_daten.py`** (identisch in `docker/api/`
+      und `docker/worker/`) als einzige Wahrheit über das Verzeichnis:
+      Status lesen, Inhalt prüfen, atomar schreiben, löschen, Dumps
+      auflisten — alles reine Funktionen, damit die Ampel sie ohne
+      Postgres/Redis testen kann.
+- [x] **API**: `GET/POST/DELETE /system/keydb`, `GET /system/aacs-dumps`
+      und `GET /system/aacs-dumps/{dateiname}`. Der Inhalt kommt bewusst
+      als JSON-Body — es gibt kein `python-multipart`, ein Endpunkt mit
+      `UploadFile`/`File()` würde die API beim Import töten.
+- [x] **UI (Einstellungen → System)**: Status der `KEYDB.cfg` (Pfad,
+      Größe, Anzahl Disc-Einträge, Datum), Inhalt einfügen, entfernen,
+      AACS-Dumps herunterladen — ohne SSH auf die VM.
+- [x] **MakeMKV redet endlich**: `parse_msg()` in `ripping.py` + Log-Callback
+      in `tasks.py` schreiben MakeMKV-Meldungen ins Rippy-Log (gedrosselt:
+      Code 1003 raus, keine Wiederholungen, max. 40 je Rip). UHD-Fehlertext
+      ehrlich neu geschrieben; `caps.py` meldet `keydb: ja | nein | unbekannt`.
+- [x] **Doku nachgezogen**: README (UHD-Voraussetzungen, System-Panel,
+      `MAKEMKV_DATA_HOST`, Bereitstellung), SAVEPOINT v3.10 inkl.
+      Richtigstellung von v3.3, KONZEPT §8 + §10.
+
+**Offen aus dieser Runde:**
+- [ ] **Der Nachweis mit einer echten `KEYDB.cfg` steht aus.** Zum
+      Zeitpunkt der Änderung lag keine Datei vor, die den Akira-Schlüssel
+      enthält — belegt sind der Befund und die Mechanik, NICHT ein
+      erfolgreicher UHD-Rip.
+- [ ] Damit bleibt auch der volle Transcode-E2E an einer UHD weiter offen
+      (siehe SAVEPOINT v3.7) — an normalen BD/DVD ist die Kette bewiesen.
+
+**Nachtrag zu „Offen":** Beide Punkte sind mit Etappe 18 erledigt — Akira
+ging auf der VM auf, allerdings über den Schlüsselspeicher statt über eine
+`KEYDB.cfg`.
+
+**Ausdrücklich nicht gebaut (und wird es auch nicht):** Rippy liefert
+keine Disc-Schlüssel mit, lädt keine herunter und verteilt keine. Es
+stellt nur den Platz für eine Datei bereit, die der Nutzer selbst
+mitbringt, und zeigt ehrlich an, was dort liegt.
+
+---
+
+## Etappe 18 (25.07.2026): 4K-UHD gelöst — Schlüsselspeicher statt KEYDB.cfg
+
+**Quelle:** Einwand des Commanders („wenn ich MakeMKV lokal auf meinem
+Windows-PC installiere, würde es SOFORT gehen — wir übersehen etwas
+Gewaltiges"). Er hatte recht. Gegenprobe mit demselben Laufwerk und
+derselben Disc an einem Windows-PC:
+
+| | Linux (Worker) | Windows |
+|---|---|---|
+| Verbindungen beim Disc-Öffnen | **keine einzige** | 185.84.108.20:443 |
+| Meldung 3338 „Downloading latest HK" | nie | ja |
+| `_private_data.tar` | 2048 B, 0 Schlüssel | 6,4 MB, 604 Schlüssel |
+| Disc | „volume key is unknown" | **TCOUNT:5, geht auf** |
+
+Gegengeprüft mit leerem UND gefülltem Speicher, mit und ohne `--noscan`,
+mit `dev:/dev/sr0` und `disc:0`, mit gelöschter `update.conf`: Linux
+fragt nie. Die Meldungsvorlage „Downloading latest %1 to %2 ..." steckt
+sehr wohl im Linux-Binary — sie löst nur nicht aus. Gleiches Symptom im
+MakeMKV-Forum, seit Jahren offen (t=25782, t=34022).
+**Damit ist die Diagnose aus Etappe 17 („der Schlüssel-Kanal ist tot")
+widerlegt.** Sie stützte sich auf zwei Hostnamen aus alten Forumsbeiträgen,
+die MakeMKV längst nicht mehr benutzt.
+
+**Gebaut:**
+- [x] **Schlüsselspeicher im Modul**: `zaehle_schluessel`,
+      `private_data_pruefen`, `schluesselspeicher_status`,
+      `private_data_schreiben` in `makemkv_daten.py` (beide Zwillinge).
+      Die Prüfung lehnt einen Speicher OHNE `hkd_*.bin` ab — sonst lädt
+      jemand den leeren Vorrat einer frischen Installation hoch, es ändert
+      sich nichts, und niemand versteht warum.
+- [x] **API**: `GET /system/keystore` und `POST /system/keystore`. Der
+      Rohkörper der Anfrage IST die Datei — binär, deshalb kein JSON und
+      kein Base64; Multipart kann die API ohnehin nicht.
+- [x] **UI**: neuer Block „Disc-Schlüssel für 4K-UHD" ÜBER dem
+      KEYDB-Block, mit Schlüssel-Anzahl, Upload und Schritt-für-Schritt-
+      Anleitung für den Windows-Umweg. KEYDB.cfg ist jetzt als Notnagel
+      beschriftet. Worker-Plakette zeigt die Schlüssel-Anzahl.
+- [x] **Fehlertext** in `tasks.py` sagt den Windows-Weg an und nennt die
+      Anzahl bekannter Schlüssel dieses Workers.
+- [x] **`caps.py`** meldet `schluessel` je Worker.
+- [x] **Alle Falschaussagen korrigiert**: UI (3 Stellen), Anleitung (2),
+      README (3), KONZEPT §8 + §10, `makemkv_daten.py`-Modulkopf,
+      Worker-Dockerfile, `makemkv_key.py`.
+
+**Bewiesen:** Nach Übernahme des Windows-Schlüsselspeichers öffnet
+`makemkvcon` auf der VM die Akira-UHD — „Operation successfully
+completed", `TCOUNT:5`, fünf Titel, identisch zum Windows-Ergebnis.
+**Das ist der erste belegte UHD-Disc-Zugriff auf der Rippy-Maschine.**
+
+**Offen aus dieser Runde:**
+- [ ] Voller UHD-Rip inklusive Transcode-E2E (nur der Disc-Zugriff ist
+      belegt, nicht die komplette Kette bis zur fertigen Datei).
+- [ ] Ob sich der Abruf unter Linux doch anstoßen lässt, ist ungeklärt —
+      der Code ist im Binary vorhanden. Bis dahin bleibt der Windows-Umweg.
+
+---
+
+## Etappe 19 (25.07.2026): Preset je Disc-Typ
+
+**Quelle:** Rückfrage des Commanders beim ersten echten UHD-Rip („merkt
+Rippy eigentlich, wenn es eine UHD-Disc ist, und wendet direkt das
+4K-Preset an?"). Antwort war: nein. Die Kompression fragte den Disc-Typ
+gar nicht — ein globales `transcodePreset` galt für alles, live eingestellt
+`HQ 1080p30 Surround`. Der laufende 4K-Rip wäre danach auf 1080p
+heruntergerechnet und der Rohschnitt gelöscht worden (`keepOriginal: False`).
+
+**Gebaut:**
+- [x] **`preset_fuer(disc_type, einstellungen)`** in `ripping.py` — pure
+      Funktion, drei Tests. Reihenfolge: Preset des Disc-Typs → allgemeines
+      `transcodePreset` → `DEFAULT_HB_PRESET`. Bestandsinstallationen
+      ändern ihr Verhalten NICHT, solange die neuen Felder ungespeichert sind.
+- [x] **`transcode_files`** holt den Disc-Typ aus dem Job-Datensatz und
+      schreibt ihn mit ins Log („Disc-Typ 'uhd', Preset '…'").
+- [x] **UI**: drei Auswahlfelder (DVD / Blu-ray / 4K-UHD) statt einem, mit
+      Erklärung, warum 4K auf ein 2160p-Preset gehört. Preset-Namen aus
+      `HandBrakeCLI --preset-list` im Worker-Image belegt, nicht geraten.
+- [x] **Sofortmaßnahme am laufenden Job**: `keepOriginal` auf `True`, damit
+      der 4K-Rohschnitt die Kompression überlebt.
+
+**Offen aus dieser Runde:**
+- [ ] **Deploy steht aus** — er würde den laufenden Akira-Rip abbrechen.
+      Erst nach Abschluss des Jobs deployen, dann bei Bedarf „Neu
+      komprimieren" mit dem 4K-Preset.
+
+---
+
 ## Ideen-Katalog (Rest) — bewusst offen
 
 1. **Design 2.0** — an Gemini übergeben (24.07.2026). Vollständiges

SAVEPOINT.md

@@ -1,6 +1,452 @@
 # SAVEPOINT — Rippy
 
-## Aktueller Stand: v3.9 — Windows-Installer als echte .exe (Icon, kein Konsolenfenster) (24.07.2026)
+## Aktueller Stand: v3.14 — Durchsicht: vier Placebos und ein unwirksamer Schutz (25.07.2026, 18:40)
+
+> Alles unten ist committet, die Ampel ist grün, **nichts ist deployt**.
+> Der Akira-Encode wurde parallel zu dieser Sitzung um 18:31 abgebrochen
+> (siehe Nachtrag im Block darunter) — **es läuft jetzt nichts mehr, ein
+> Deploy ist gefahrlos möglich.** Zuerst lesen: „SOFORT ENTSCHEIDEN" unten.
+
+### DER WICHTIGSTE FUND: der Platten-Schutz aus `c065967` greift nicht
+
+`_original_aufheben()` entschied per `os.stat().st_dev`, ob umgehängt oder
+kopiert werden muss. Auf der VM gemessen — **beides gleichzeitig wahr**:
+
+```
+st_dev /app/temp  = 2050
+st_dev /app/media = 2050        → identisch
+os.rename(...)    → EXDEV, "Invalid cross-device link"
+```
+
+Der Kernel vergleicht bei `rename()` den **Mount**, nicht das Gerät.
+`/app/temp` (Docker-Volume) und `/app/media` (Bind-Mount) sind zwei Mounts
+DERSELBEN ext4-Partition. Die Prüfung sah deshalb „gleiches Dateisystem",
+**übersprang die Platzprüfung**, und `shutil.move` kopierte doch — 75 GB bei
+37 GB frei. Der Schutz hätte genau den Schaden zugelassen, gegen den er
+gebaut wurde.
+
+**Behoben:** `os.rename` wird jetzt VERSUCHT statt vorhergesagt. Klappt es,
+ist es umgehängt. Kommt EXDEV, steht die Kopie fest — und erst dann wird der
+Platz geprüft. Vier Tests dazu (`test_original_aufheben.py`), inklusive des
+Falls, der die Platte füllte.
+
+### GEMESSEN, Stand 18:30 (alles per Befehl auf der VM geprüft)
+
+- **Container:** alle 5 `Up`, api/postgres/redis `healthy`. api/ui/worker seit
+  18:00:39 (Deploy von `8bb075c`), postgres/redis älter.
+- **Platte:** 148 G, 105 G belegt, 37 G frei = 75 G Rohschnitt + 4,9 G Medien
+  (Evangelion) + ~25 G System. **Keine Kopier-Reste**, kein `original`-Ordner.
+- **Akira-Job:** `failed`, „Abgebrochen durch Nutzer" (Abbruch 18:30:17
+  angefordert, Worker bestätigt 18:33:38 → **3,4 Minuten Verzug**, siehe unten).
+  Es läuft **kein** HandBrake mehr (per `/proc` geprüft, Stand 19:06).
+- **Der Encode war bei 1,44 %**, gemessen an der Leseposition im Quellstrom
+  (`/proc/<pid>/fdinfo/3`: 1.145.940.149 von 79.604.951.639 Bytes) — exakter
+  als jede Fortschrittsanzeige. Zwei Tempo-Fenster ergaben 395 und 784 KB/s
+  → **28–55 h** für den Film, bei 3,84 von 4 gesättigten Kernen.
+- **Achtung bei Prozess-Suchen per `/proc`:** Ein `case "$c" in *HandBrake*)`
+  trifft die eigene Shell mit, weil deren Kommandozeile das Wort enthält. Zwei
+  Fehlalarme in dieser Sitzung. Immer die PID gegenprüfen.
+- **Die Ursache dafür ist neu und behebbar:** Die VM läuft auf dem generischen
+  QEMU-CPU-Modell (`QEMU Virtual CPU version 2.5+`), `grep -c avx2
+  /proc/cpuinfo` = **0**, nur bis `sse4_2`. x265 lebt von AVX2. Abhilfe:
+  CPU-Typ von VM 106 in Proxmox auf `host` stellen (braucht VM-Neustart).
+- **HandBrake im Worker-Image kann:** `svt_av1`, `x264`, `x265` (je 10/12-bit),
+  `mpeg4/2`, `VP8/9`, `theora` — und **keinen einzigen Hardware-Encoder**.
+- **Ampel grün** für `b526a0a` und `8bb075c` (Gitea-API abgefragt).
+
+### GEBAUT — vier Placebos entfernt bzw. echt gemacht
+
+1. **Fortschritt log statt Wahrheit.** `get_progress_from_line` matchte jede
+   Zahl vor einem `%` — also auch HandBrakes **Scan-Durchlauf**, der VOR dem
+   Encodieren bis 100 % hochläuft. Dazu warf `if progress > 0` alle echten
+   Werte unter 1,00 % weg. Ergebnis: Anzeige klebte stundenlang auf 99 %.
+   Jetzt wird nur die `Encoding:`-Zeile gelesen, `task N of M` mitgerechnet,
+   und **-1 heißt „keine Angabe"** (Muster von `get_progress_from_prgv`).
+   Formatstrings aus dem Binary gelesen, nicht geraten.
+   **⚠️ Richtigstellung zu v3.13:** Dort steht, `progress=99` sei ein „Altwert
+   aus dem Absturz". Falsch — beide Startpfade setzen auf 0, der Wert war
+   frisch vom Scan-Durchlauf geschrieben. Es war ein Bug, kein Überrest.
+2. **„Automatischer Auswurf" tat nichts.** Die Einstellung (Standard: ein)
+   wurde von niemandem gelesen: DVD/Blu-ray warfen **nie** aus, Audio-CDs
+   **immer**, weil abcde `-x` fest verdrahtet bekam. Jetzt entscheidet die
+   Einstellung beides (`wirf_disc_aus()` per CDROMEJECT-ioctl, Linux-guarded).
+3. **„Alle Tracks rippen" konnte nichts bewirken** — abcde bekommt keine
+   Track-Auswahl und es gibt keine Oberfläche dafür. Schalter entfernt, an
+   seiner Stelle steht jetzt die Wahrheit („wird immer vollständig gerippt").
+4. **Encoder-Auslese behauptete statt zu messen.** `cpu-x264`/`cpu-x265`
+   standen fest verdrahtet drin („immer dabei") — ein Rip-Worker **ohne**
+   HandBrake behauptete damit, komprimieren zu können. Und `vaapi` wurde
+   allein wegen `/dev/dri` gemeldet, ohne zu prüfen, ob HandBrake das kann
+   (dieses Image kann es nicht). Jetzt aus `HandBrakeCLI --help` geparst, plus
+   **CPU-Modell, Kernzahl und Vektorbefehlsstufe** je Worker — mit sichtbarer
+   Warnung im UI, wenn AVX2 fehlt. Genau die Angabe, deren Fehlen den
+   55-Stunden-Encode unsichtbar machte.
+
+### GEBAUT — Zombie-Erkennung (v3.13 Punkt 2 abgearbeitet)
+
+`zombies.py`: Beim Worker-Start werden Jobs, die auf `ripping`/`transcoding`/
+`canceling` stehen, gegen Celerys `active`/`reserved`/`scheduled` gehalten und
+ehrlich auf `failed` gesetzt, wenn niemand daran arbeitet. Drei Sicherungen,
+weil ein falsch getöteter Job teurer ist als eine stehende Leiche:
+
+- **nur beim Start** (da ist „es lief nichts" eindeutig),
+- **120 s Gnadenfrist** (Celery stellt unbestätigte Aufgaben erneut zu),
+- **Vollzähligkeit**: antworten weniger Knoten als laut Herzschlag online
+  sind, wird NICHTS gewertet — sonst wäre der laufende Job eines
+  beschäftigten Remote-Workers eine falsche Leiche.
+
+13 Tests, unter anderem: „laufender Job wird nicht angetastet" und
+„schweigender Worker verhindert jedes Urteil".
+
+### GEBAUT — Pfad-Prüfung gehärtet
+
+Elf Stellen prüften mit nacktem `startswith(MEDIA_ROOT)`. `/app/media-boese/x`
+beginnt mit `/app/media`, liegt aber außerhalb — betroffen waren auch `/browse`
+und `/browse/mkdir`, wo der Pfad vom Nutzer kommt. Neuer Zwillings-Helfer
+`unter_wurzel()` in `api/main.py` und `worker/tasks.py`, alle elf Stellen
+umgestellt, Tests in beiden.
+
+Nebenbefund dabei: `_zielbasis()` benutzte `os.path.normpath` — unter Windows
+werden daraus Backslashes und die Prüfung greift nicht mehr; das gewählte Ziel
+wäre still auf den Standard zurückgefallen. Genau die Falle, die
+`_arbeitsverzeichnis()` drei Zeilen weiter dokumentiert und mit `posixpath`
+vermeidet. Live war es nie (nur aus `rip_disc`, das auf Windows verriegelt
+ist), jetzt konsistent.
+
+### GEFUNDEN, NICHT ANGETASTET — vier tote Endpunkte
+
+Nirgends im UI referenziert (mechanisch gegengeprüft: alle `api.*`-Aufrufe
+gegen alle Routen):
+
+| Endpunkt | Lage |
+|---|---|
+| `POST /jellyfin/format` | ersetzt durch `medien.py` im Worker; zieht `nfo_generator.py` + `image_downloader.py` in der API mit, die sonst niemand nutzt |
+| `POST /prescan` | ohne Aufrufer (die `PreScan`-Klasse selbst wird woanders sehr wohl gebraucht) |
+| `GET /stream/jobs` | niemand konsumiert ihn; der Kommentar behauptet einen „Fix 23.07.", der ihn funktionsfähig machte — gebraucht wird er trotzdem nicht |
+| `GET /worker-setup/windows-gui` | seit der `.exe` (v3.9) unreferenziert |
+
+Bewusst nicht entfernt: `test_api_smoke.py` prüft `/prescan` als verdrahtete
+Route, und Entfernen ist eine Entscheidung, keine Reparatur. **Der Commander
+entscheidet.**
+
+### NOCH OFFEN / EHRLICH UNGEKLÄRT
+
+- **Was die Platte am 25.07. mittags füllte, ist nicht belegt.** Es gibt keine
+  Kopier-Reste, kein `original`-Verzeichnis und **keinen einzigen Log-Eintrag
+  von `_original_aufheben`** — das loggt in beiden Zweigen. Zwischen 10:21:50
+  und 17:49 steht überhaupt nichts im Log. Der EXDEV-Mechanismus ist jetzt
+  belegt (siehe oben), dass er DAMALS zuschlug, ist es nicht.
+- **`tracks:/dev/sr0` meldet `{"status":"done","tracks":[]}`** — null Titel für
+  eine Disc, die MakeMKV mit `TCOUNT:5` öffnet. Nicht weiter verfolgt.
+- **Der Discord-Webhook und der MakeMKV-Key liegen im Klartext** in der
+  settings-Tabelle. Für Heimnetz erwartbar, aber der Webhook ist eine echte
+  Zugangsberechtigung.
+- **Zwei neue API-Tests laufen nur in der Ampel** — `test_api_smoke.py`
+  überspringt sich unter Windows selbst (`main.py` braucht `fcntl`).
+
+### GEBAUT — „Abbrechen" wirkt jetzt sofort
+
+Der Fund aus dem Nachtrag (Commander, am laufenden Job beobachtet) ist behoben.
+Ursache war genau wie dort beschrieben: Der Abbruch wurde nur in
+`datei_fortschritt` geprüft, und diese Closure stieg oben sofort wieder aus,
+wenn sich die Prozentzahl nicht geändert hatte. Bei einem Prozent je halber
+Stunde sah „Abbrechen" entsprechend lange wirkungslos aus.
+
+Jetzt gibt es in `run_handbrake` einen **eigenen Abbruch-Kanal** neben dem
+Fortschritts-Callback — dasselbe Muster, das `run_makemkv` schon für `log_cb`
+benutzt, und aus demselben Grund. Er wird bei JEDER Ausgabezeile aufgerufen
+und ist im Worker auf 5 Sekunden gedrosselt (`ABBRUCH_INTERVALL_SEKUNDEN`).
+Nebeneffekt: Er greift auch während des Scan-Durchlaufs, der überhaupt keine
+Encode-Prozente liefert — dort war ein Abbruch vorher grundsätzlich unmöglich.
+Die Leseschleife ist als `_handbrake_schleife()` herausgezogen, damit die
+Reihenfolge (Abbruch VOR Fortschritt) ohne echtes HandBrake testbar ist.
+
+### SOFORT ENTSCHEIDEN
+
+**1. Deployen — es läuft nichts, der Weg ist frei.** Nichts blockiert mehr, und
+solange nicht deployt ist, gilt weiterhin der alte Code: unwirksamer
+Platten-Schutz, Anzeige auf 99 %, Auswurf ohne Wirkung, träges „Abbrechen".
+
+```
+ssh arcane@192.168.178.162 'cd ~/projects/rippy && git pull --ff-only && docker compose up -d --build'
+```
+
+**2. Die UHD-Strategie ist noch offen** (aus dem Nachtrag, unverändert gültig).
+Preset-je-Disc-Typ war richtig, reicht aber nicht: Software-HEVC in 4K ist auf
+dieser CPU keine Option. Drei Wege, keiner davon gebaut:
+- **UHD gar nicht komprimieren** — Roh-MKV behalten. Ehrlichste Variante,
+  kostet Platz (75–100 GB je Film, gehört dann auf die NAS).
+- **Hardware-Encoder** — Remote-Worker mit GPU (`nvenc`/`vaapi`). Rippy kann
+  das schon routen (bewiesen v3.7); es fehlt die Maschine. Achtung: Das
+  Worker-Image kann selbst keinen Hardware-Encoder, ein GPU-Worker braucht ein
+  HandBrake-Build mit `nvenc_*`/`qsv_*` — die neue Anzeige sagt das jetzt.
+- **CPU-Typ der VM auf `host`** — schaltet AVX2 frei, bringt bei x265 typisch
+  Faktor 2–4. Aus 28–55 h werden damit aber immer noch Stunden bis Tage; das
+  allein löst 4K nicht, hilft aber jedem 1080p-Encode.
+
+**3. Vier tote Endpunkte** — entfernen oder behalten (Tabelle oben).
+
+**4. Im Akira-Ordner liegt ein unbrauchbares 4K-Fragment** (die 1080p-Fassung
+wurde beim Start auf 0 Bytes gekürzt). Der 75-GB-Rohschnitt ist unversehrt,
+also ist nichts verloren — aber die Datei gehört weg, bevor jemand sie für ein
+Ergebnis hält.
+
+---
+
+## Vorheriger Stand: v3.13 — ÜBERGABE (25.07.2026, 18:05)
+
+> Dieser Block ist eine Übergabe an die nächste Sitzung. Er trennt bewusst
+> **gemessen** von **vermutet** — in dieser Sitzung wurden zwei Behauptungen
+> aufgestellt, die sich als falsch erwiesen (siehe „Vertrauensnotiz" unten).
+> Im Zweifel: selbst nachmessen, nicht diesem Dokument glauben.
+
+### GEMESSEN, Stand 18:05 (alles per Befehl auf der VM geprüft)
+
+- **Container:** api/postgres/redis/ui/worker alle `Up`, api + postgres +
+  redis `healthy`.
+- **Platte:** `/dev/sda2` 148 G, 105 G belegt, **37 G frei** (75 %).
+- **Läuft gerade:** `HandBrakeCLI --input
+  /app/temp/raw/73b89777-…/title_t00.mkv --output
+  "/app/media/movies/Akira (1988)/title_t00.mkv" --preset
+  "H.265 MKV 2160p60 4K" --all-audio --all-subtitles`
+- **Job `73b89777-a808-426f-8159-d406d27d0ec8`:** `status='transcoding'`,
+  `progress=99` (⚠️ **Altwert aus dem Absturz, NICHT der echte Fortschritt** —
+  der Lauf hat um 18:02 begonnen), `disc_type='uhd'`,
+  `output_path='/app/media/movies/Akira (1988)'`.
+- **Dateien:** `…/Akira (1988)/title_t00.mkv` ist **0 Bytes** (HandBrake hat
+  die vorherige 1080p-Fassung beim Start gekürzt und schreibt gerade neu).
+  Roh-Rip `/app/temp/raw/73b89777-…/` = **75 GB, unversehrt.**
+- **Git:** `8bb075c` ist HEAD und deployt. Davor `c065967`, `e84afc1`,
+  `f449c4e`, `0935766`. Alle Ampeln waren grün.
+- **Schlüsselspeicher:** 604 Disc-Schlüssel, `/system/keystore` antwortet.
+- **NAS:** `//192.168.178.62/rippy` auf `/srv/rippy/media/rippy` gemountet,
+  erreichbar, **2311 GB frei**. Wird als Ablageziel gelistet.
+
+### NACHTRAG 18:35 — der 4K-Lauf wurde abgebrochen, zwei neue Befunde
+
+- **4K-HEVC ist auf dieser CPU nicht machbar.** Gemessen: von 18:02 bis 18:31
+  kam der Lauf von 0 auf **1 %** → hochgerechnet **~50 Stunden** für den Film.
+  Der Commander hat um 18:31 abgebrochen. **Konsequenz, die noch zu
+  entscheiden ist:** entweder UHD gar nicht komprimieren (Roh-MKV behalten,
+  `transcodeEnabled` für UHD aus), oder ein Hardware-Encoder (Remote-Worker
+  mit GPU, `nvenc`/`vaapi`), oder bewusst bei 1080p bleiben. Das eben
+  gebaute Preset-je-Disc-Typ ist damit richtig, aber allein nicht genug.
+- **Abbruch wirkt verzögert (FEHLER, nicht gebaut).** Job steht seit 18:31 auf
+  `canceling`, **HandBrake lief um 18:35 immer noch**. Ursache: Der Abbruch
+  wird nur in `datei_fortschritt` geprüft, und diese Closure läuft nur, wenn
+  sich die PROZENTZAHL ändert (`tasks.py`, `if gesamt == letzter[0]: return`).
+  Bei 1 % alle 30 Minuten heißt das: bis zu eine halbe Stunde, in der
+  „Abbrechen" für den Nutzer wirkungslos aussieht. Der Abbruch muss unabhängig
+  vom Fortschritt geprüft werden (z. B. zeitgesteuert beim Lesen der
+  HandBrake-Ausgabe).
+- **Die 1080p-Fassung ist weg.** HandBrake hat sie beim Start auf 0 Bytes
+  gekürzt; aktuell liegen dort ~64 MB 4K-Fragment. Der **75-GB-Rohschnitt ist
+  unversehrt** — es ist also nichts unwiederbringlich verloren, aber im
+  Akira-Ordner liegt gerade eine unbrauchbare Datei.
+
+### WAS ALS NÄCHSTES ANSTEHT
+
+1. **Ausgang des 4K-Laufs prüfen.** Erwartung, die noch NICHT bewiesen ist:
+   Der Job endet **erfolgreich**, und „Original behalten" (Setting steht auf
+   `true`) meldet nur eine **Warnung**, weil 75 GB nicht neben 37 GB freien
+   Platz passen. Genau dieser Pfad ist neu (`_original_aufheben` in
+   `tasks.py`) und in der Praxis noch nie gelaufen. Wenn er hält, ist der
+   Ausfall von heute Mittag strukturell behoben.
+2. **Zombie-Erkennung fehlt (gefunden, NICHT gebaut).** Nach dem Absturz stand
+   der Job auf `transcoding 96 %`, obwohl weder ein Prozess lief noch etwas in
+   den Celery-Queues stand (beide `llen` = 0). Folge: keine Anzeige, kein
+   Download, und der „Neu komprimieren"-Knopf fehlt, weil
+   `_kann_neu_komprimieren` (main.py) `status == "failed"` verlangt. Der
+   Worker sollte beim Start solche Leichen erkennen und ehrlich auf `failed`
+   setzen.
+3. **`keepOriginal` steht auf `true`** — von dieser Sitzung gesetzt, um den
+   4K-Rohschnitt zu retten. Bewusst entscheiden, ob das so bleibt: mit
+   Arbeitsverzeichnis auf der NAS-Freigabe wäre es ein reines Umhängen statt
+   einer Vollkopie.
+4. **75 GB Rohschnitt** liegen weiter in `/app/temp/raw/73b89777-…`. Nach
+   erfolgreichem 4K-Lauf entscheiden, ob er weg kann.
+
+### VERTRAUENSNOTIZ — zwei Fehlschlüsse dieser Sitzung
+
+- **„MakeMKVs Schlüssel-Kanal ist abgeschaltet"** — falsch. Stützte sich auf
+  zwei tote Hostnamen aus alten Forumsbeiträgen, die MakeMKV längst nicht mehr
+  benutzt. Richtig: `makemkvcon` unter **Linux** fragt nie, die
+  **Windows**-Version schon. Korrigiert in v3.11.
+- **„Celery hat die Aufgabe nach dem Deploy erneut zugestellt"** — falsch.
+  Aus dem Status `transcoding` geraten, ohne Prozesse oder Queues zu prüfen.
+  Es war ein Zombie-Eintrag (Punkt 2 oben).
+
+Beide Male war das Muster dasselbe: **aus einem Zustandswert auf einen
+Mechanismus geschlossen, statt den Mechanismus zu messen.**
+
+---
+
+## Vorheriger Stand: v3.12 — Preset je Disc-Typ (25.07.2026)
+
+- **Der Fund:** Beim ersten echten UHD-Rip aufgefallen — die Kompression
+  fragte den Disc-Typ **gar nicht**: `preset = einstellungen.get(
+  "transcodePreset")`, ein globales Preset für alles. Live eingestellt war
+  `HQ 1080p30 Surround`. Der laufende Akira-Rip wäre also verlustfrei in 4K
+  gerippt und danach **auf 1080p heruntergerechnet** worden — und mit
+  `keepOriginal: False` wäre der 4K-Rohschnitt anschließend gelöscht worden.
+  Aufgefallen ist es nur, weil der Commander gefragt hat, ob Rippy das
+  UHD-Preset automatisch nimmt.
+- **Sofortmaßnahme am laufenden Job:** `keepOriginal` auf `True` gesetzt
+  (nur dieses eine Feld, gegengeprüft: kein anderer Schlüssel verändert).
+  Damit überlebt der 4K-Rohschnitt die Kompression auf jeden Fall.
+- **Gebaut:** `preset_fuer(disc_type, einstellungen)` in `ripping.py` (pure,
+  getestet) plus drei Einstellungen `transcodePresetDvd` / `…Bluray` /
+  `…Uhd`. Reihenfolge: Preset des Disc-Typs → allgemeines
+  `transcodePreset` → `DEFAULT_HB_PRESET`. **Bestandsinstallationen ändern
+  ihr Verhalten nicht**, solange die neuen Felder nicht gespeichert sind.
+  `transcode_files` holt den Disc-Typ aus dem Job-Datensatz und schreibt ihn
+  mit ins Log.
+- **UI (Einstellungen → Verarbeitung):** drei Auswahlfelder statt einem, mit
+  Klartext dazu, warum 4K auf ein 2160p-Preset gehört. Alle Preset-Namen
+  stammen aus `HandBrakeCLI --preset-list` im Worker-Image (1.6.1) — nicht
+  geraten (AGENTS Regel D).
+- **⚠️ Deploy bewusst zurückgehalten:** `docker compose up -d --build`
+  würde den Worker-Container neu erstellen und den **laufenden Akira-Rip
+  abbrechen**. Erst deployen, wenn der Job durch ist. Der 4K-Rohschnitt ist
+  durch `keepOriginal` geschützt; danach reicht „Neu komprimieren" im UI,
+  um mit dem richtigen Preset in 4K zu komprimieren.
+- **Nebenbefund:** `ps` gibt es im Worker-Image nicht (python-slim). Frühere
+  Prüfungen auf laufende Rips per `ps | grep` lieferten deshalb still
+  „nichts aktiv" — richtig geht es über `/proc`.
+
+---
+
+## Vorheriger Stand: v3.11 — 4K-UHD GELÖST: Akira geht auf (25.07.2026)
+
+- **🎉 Der Durchbruch:** Nach Übernahme des Schlüsselspeichers öffnet
+  `makemkvcon` auf der VM die Akira-UHD: „Operation successfully
+  completed", **`TCOUNT:5`**, fünf Titel — identisch zum Windows-Ergebnis.
+  **Erster belegter UHD-Disc-Zugriff auf der Rippy-Maschine.**
+- **Die echte Ursache — und sie ist eine andere als in v3.10:**
+  `makemkvcon` unter **Linux** ruft Disc-Schlüssel **nie** ab. Die
+  **Windows**-Version tut es. Gegenprobe mit demselben Laufwerk und
+  derselben Disc:
+
+  | | Linux (Worker) | Windows |
+  |---|---|---|
+  | Verbindungen beim Disc-Öffnen | **keine einzige** | 185.84.108.20:443 |
+  | Meldung 3338 „Downloading latest HK" | nie | ja |
+  | `_private_data.tar` | 2048 B, **0** Schlüssel | 6,4 MB, **604** Schlüssel |
+  | Disc | „volume key is unknown" | **geht auf** |
+
+  Gegengeprüft mit leerem UND gefülltem Speicher, mit und ohne `--noscan`,
+  mit `dev:/dev/sr0` und `disc:0`, mit gelöschter `update.conf`. Immer:
+  keine Verbindung. Die Meldungsvorlage „Downloading latest %1 to %2 ..."
+  steckt sehr wohl im Linux-Binary — sie löst nur nie aus. Gleiches
+  Symptom im MakeMKV-Forum, seit Jahren offen (t=25782, t=34022).
+- **⚠️ Richtigstellung zu v3.10 (direkt darunter):** Dort steht, MakeMKVs
+  Schlüssel-Kanal sei abgeschaltet. **Das war falsch.** Die Herleitung
+  stützte sich auf zwei Hostnamen aus alten Forumsbeiträgen
+  (`hkdata.fairuse.org`, `hkdata.crabdance.com`), die tatsächlich nicht
+  mehr auflösen — MakeMKV benutzt sie aber längst nicht mehr. **Der Dienst
+  lebt, der Worker erreicht ihn sogar** (Verbindungstest auf
+  185.84.108.20:443 erfolgreich); er wird unter Linux nur nie gefragt.
+  Aufgedeckt hat das der Commander mit dem Einwand, unter Windows ginge es
+  sofort. Alles in v3.10 Gebaute bleibt richtig und nötig — nur die
+  `KEYDB.cfg` ist nicht der Haupt-, sondern der Ersatzweg.
+- **Gebaut — Schlüsselspeicher übernehmbar:** `GET`/`POST
+  /system/keystore` plus die Helfer in `makemkv_daten.py` (beide
+  Zwillinge). Der Rohkörper der Anfrage IST die Datei — binär, deshalb
+  kein JSON und kein Base64. Die Prüfung lehnt einen Speicher **ohne**
+  `hkd_*.bin` ab, sonst lädt jemand den leeren Vorrat einer frischen
+  Installation hoch und wundert sich, dass nichts passiert.
+- **Gebaut — UI:** neuer Block „Disc-Schlüssel für 4K-UHD" **über** dem
+  KEYDB-Block, mit Schlüssel-Anzahl, Upload und der Schritt-für-Schritt-
+  Anleitung für den Windows-Umweg. KEYDB.cfg ist jetzt als **Notnagel**
+  beschriftet. Die Worker-Plakette zeigt die Anzahl bekannter Schlüssel;
+  `0` heißt sichtbar „4K-UHD scheitert".
+- **Gebaut — ehrliche Texte:** Der UHD-Fehlertext nennt jetzt den
+  Windows-Weg und die Anzahl der Schlüssel dieses Workers. Alle
+  Falschaussagen korrigiert: UI (3 Stellen), Anleitung (2), README (3),
+  KONZEPT §8 + §10, Modulkopf von `makemkv_daten.py`, Worker-Dockerfile
+  und `makemkv_key.py` (dort stand: „Den AACS-Schlüssel zieht MakeMKV via
+  LibreDrive ohnehin selbst aus dem Laufwerk" — gilt für Blu-ray, NICHT
+  für UHD).
+- **So hältst du den Vorrat aktuell:** Laufwerk an den Windows-PC, Disc in
+  MakeMKV öffnen, dann `_private_data.tar` aus dem MakeMKV-Datenverzeichnis
+  (*Preferences → General*) unter Einstellungen → System hochladen. Der
+  Speicher der Windows-Installation liegt bereits auf der VM unter
+  `/srv/rippy/makemkv/`.
+- **Offen:** Der volle UHD-Rip inklusive Transcode-E2E ist noch nicht
+  durch — belegt ist der Disc-Zugriff, nicht die komplette Kette bis zur
+  fertigen Datei. Und ob sich der Abruf unter Linux doch anstoßen lässt,
+  ist ungeklärt; der Code dafür ist im Binary vorhanden.
+
+---
+
+## Vorheriger Stand: v3.10 — 4K-UHD: KEYDB.cfg statt Warten auf MakeMKV (25.07.2026)
+
+- **Der Befund (am 25.07. live auf der VM im Worker-Container
+  nachgemessen — kein Verdacht, alles belegt):** Eine 4K-UHD (Akira,
+  MKB v76, Pressung Dezember 2020) scheitert mit „The volume key is
+  unknown for this disc". **Laufwerk und MakeMKV sind dabei in Ordnung:**
+  makemkvcon meldet „Using LibreDrive mode (v06.3)" und „Using direct
+  disc access mode", liest die Disc und legt den AACS-Dump ab
+  (Meldung 3332). Der Fehler liegt also NICHT an der Hardware.
+- **Die echte Ursache — MakeMKV fragt gar nicht erst:** Das Debug-Log
+  geht ohne einen einzigen Netz-Versuch von „Loaded content hash table"
+  direkt auf „The volume key is unknown". **Beweise:**
+  `/root/.MakeMKV/_private_data.tar` enthielt nur die Index-Datei und
+  KEINE einzige `hkd_*.bin` — es wurde also nie ein Schlüssel geladen.
+  Auch mit erzwungener frischer Prüfung (`update.conf` gelöscht,
+  Meldung 5074 belegt den Web-Kontakt) und mit `app_UpdateEnable = "1"`
+  kam keiner. Und die im MakeMKV-Forum dokumentierten Schlüssel-Server
+  `hkdata.fairuse.org` und `hkdata.crabdance.com` lösen weltweit nicht
+  mehr auf (NXDOMAIN gegen Fritz!Box, 8.8.8.8 und 1.1.1.1).
+- **Richtigstellung zu v3.3 (weiter unten korrigiert):** Dort stand, die
+  Ursache sei „Disc neuer als MakeMKVs Schlüssel-DB" und ein
+  MakeMKV-Update werde das lösen. Das ist widerlegt — es gibt keine
+  nachladbare Schlüssel-Datenbank mehr. **Warten auf ein MakeMKV-Update
+  hilft bei diesem Fehler nicht.**
+- **Der einzige Weg, der heute funktioniert: `KEYDB.cfg`** — GROSS
+  geschrieben (unter Linux case-sensitiv) im MakeMKV-Datenverzeichnis.
+  Rippy macht diesen Weg jetzt begehbar, statt auf MakeMKV zu warten.
+- **Gebaut — persistentes Datenverzeichnis:** `docker-compose.yml` mountet
+  `${MAKEMKV_DATA_HOST:-/srv/rippy/makemkv}` vom Host — im Worker auf
+  `/root/.MakeMKV`, in der API auf `/app/makemkv-data`; beide Container
+  bekommen `MAKEMKV_DATA_DIR`. Damit überleben `KEYDB.cfg` und die
+  AACS-Dumps jeden Rebuild. `entrypoint.sh` schreibt `settings.conf`
+  jetzt ergänzend statt zerstörend (sonst hätte der Beta-Key den Rest
+  überbügelt) und setzt `app_UpdateEnable = "1"`.
+- **Gebaut — eine einzige Wahrheit über das Verzeichnis:** neues
+  Zwillings-Modul `makemkv_daten.py` (identisch in `docker/api/` und
+  `docker/worker/`) mit reinen Helfern — Status lesen, Inhalt prüfen,
+  atomar schreiben, löschen, AACS-Dumps auflisten. Nur reine Funktionen,
+  damit die Ampel sie ohne Postgres/Redis testen kann.
+- **Gebaut — Bedienung im UI:** Einstellungen → System zeigt den
+  `KEYDB.cfg`-Status (Pfad, Größe, Anzahl Disc-Einträge, Datum), nimmt die
+  Datei über einen ganz normalen Datei-Dialog entgegen (der Browser liest
+  sie und schickt den Text als JSON — serverseitig bewusst KEIN
+  Multipart-Upload, es gibt kein `python-multipart`, das würde die API
+  beim Import töten), lehnt
+  unplausiblen Inhalt mit deutschem Klartext ab, kann die Datei wieder
+  entfernen und die AACS-Dumps zum Download anbieten.
+- **Gebaut — man sieht endlich, was MakeMKV sagt:** `parse_msg()` in
+  `ripping.py` plus Log-Callback in `tasks.py` schreiben MakeMKV-Meldungen
+  ins Rippy-Log (gedrosselt: Code 1003 raus, keine Wiederholungen, max. 40
+  je Rip). Der UHD-Fehlertext ist ehrlich neu geschrieben. `caps.py`
+  meldet zusätzlich `keydb: ja | nein | unbekannt` je Worker.
+- **Abgrenzung, die überall durchscheint:** **Rippy liefert KEINE
+  Schlüssel mit, lädt keine herunter und verteilt keine.** Rippy stellt
+  nur den Platz für eine Datei bereit, die der Nutzer selbst mitbringt,
+  und zeigt ehrlich an, was dort liegt. Genau die Grenze zieht schon
+  `docker/api/makemkv_key.py` (Zeile 14) für den Beta-Key: das ist die
+  Software-LIZENZ, nicht das Entschlüsseln oder Verteilen von
+  Disc-Schlüsseln.
+- **⚠️ NOCH NICHT end-to-end bewiesen — ehrlich gesagt:** Zum Zeitpunkt
+  dieser Änderung lag KEINE `KEYDB.cfg` vor, die den Akira-Schlüssel
+  enthält. Belegt sind der Befund oben und die neue Mechanik (Mount,
+  Modul, Endpunkte, UI) — **nicht** ein erfolgreicher UHD-Rip. Der
+  Nachweis steht aus und braucht eine echte Schlüssel-Datei.
+
+---
+
+## Vorheriger Stand: v3.9 — Windows-Installer als echte .exe (Icon, kein Konsolenfenster) (24.07.2026)
 
 - **RippyWorkerSetup.exe** ersetzt den .vbs/.bat-Weg (Commander-Einwand:
   .vbs ist abgekündigt + wird als gefährlich geflaggt). install-gui.ps1 via
@@ -183,16 +629,20 @@ Konvertierung (Infrastruktur steht), AI-Box-NFS-Export, Kodi-Refresh.
 - **UHD-Kette diagnostiziert (Nachtrag, gleicher Tag): Der BU40N-Flash IST
   erledigt** — makemkvcon meldet „Using LibreDrive mode (v06.3)". Der
   Summer-Wars-Fehlschlag lag NICHT am Laufwerk, sondern an „The volume key
-  is unknown": die Disc (MKB v82) ist neuer als MakeMKVs Schlüssel-DB —
-  auf der VM mit 1.17.7 UND der aktuellsten 1.18.4 bewiesen. Konsequenzen:
+  is unknown" — auf der VM mit 1.17.7 UND der aktuellsten 1.18.4
+  reproduziert. Konsequenzen:
   MakeMKV auf **1.18.4** gehoben (Scan-Hänger durch überall genutztes
   --noscan umgangen, auf der BU40N sauber gelaufen; URL-Base → /download),
   run_makemkv reicht kritische Meldungen (volume key/Key abgelaufen) in
   den Fehlertext durch, UHD-Klartext unterscheidet jetzt „Laufwerk kann
-  kein UHD" von „Disc neuer als Key-DB" inkl. Forum-Dump-Hinweis
+  kein UHD" von „Disc-Schlüssel fehlt" inkl. Forum-Dump-Hinweis
   (MakeMKV speichert den AACS-Dump automatisch unter /root/.MakeMKV/).
-  Summer Wars bleibt bis zu einem MakeMKV-Key-Update nicht entschlüsselbar
-  — das ist Stand der Technik, kein Rippy-Bug.
+  **⚠️ Korrigiert am 25.07.2026 (siehe v3.10 ganz oben):** Die hier
+  ursprünglich genannte Erklärung „die Disc ist neuer als MakeMKVs
+  Schlüssel-DB, ein MakeMKV-Update löst das" ist FALSCH. Nachgemessen:
+  MakeMKV hat gar keine nachladbare Schlüssel-DB mehr und versucht auch
+  keinen Online-Abruf; die alten Schlüssel-Server sind tot. Der Weg zum
+  Ziel heißt `KEYDB.cfg`, nicht „warten auf die nächste Version".
 - **Vollautomatik** (Einstellungen → Ripping): Disc erkannt → Rip startet
   ohne Popup in den passenden Schnellwahl-Ordner (Serie/Film/Musik).
 - **Job-Verwaltung**: „Neu komprimieren" nur noch, wenn Rohdaten wirklich

docker-compose.yml

@@ -16,6 +16,10 @@ services:
       - TMDB_API_KEY=${TMDB_API_KEY:-}
       - THETVDB_API_KEY=${THETVDB_API_KEY:-}
       - OMDB_API_KEY=${OMDB_API_KEY:-}
+      # Dasselbe Host-Verzeichnis wie beim Worker, nur an neutraler Stelle:
+      # die API liest den KEYDB-Status und die AACS-Dumps und nimmt eine
+      # hochgeladene KEYDB.cfg entgegen (Einstellungen → System).
+      - MAKEMKV_DATA_DIR=/app/makemkv-data
       - LOG_LEVEL=INFO
     healthcheck:
       test: ["CMD-SHELL", "python -c 'import urllib.request; urllib.request.urlopen(\"http://localhost:8000/health\")'"]
@@ -47,6 +51,8 @@ services:
         bind:
           propagation: rshared
       - temp:/app/temp
+      # MakeMKV-Datenverzeichnis (dasselbe wie im Worker, siehe dort).
+      - ${MAKEMKV_DATA_HOST:-/srv/rippy/makemkv}:/app/makemkv-data
     devices:
       - ${OPTICAL_SR:-/dev/sr0}:/dev/sr0
     networks:
@@ -78,6 +84,10 @@ services:
       - REDIS_URL=redis://redis:6379/0
       - RIP_OUTPUT_DIR=/app/media
       - MAKEMKV_APP_KEY=${MAKEMKV_APP_KEY}
+      # MakeMKVs Datenverzeichnis im Container — fest verdrahtet in MakeMKV
+      # selbst (HOME/.MakeMKV, HOME ist /root). Steht hier, damit Worker-Code
+      # und Mount dieselbe Wahrheit benutzen.
+      - MAKEMKV_DATA_DIR=/root/.MakeMKV
       # Anzeigename in Einstellungen → Worker (stabil über Rebuilds hinweg;
       # via .env übersteuerbar, z. B. WORKER_NAME=wohnzimmer-vm)
       - WORKER_NAME=${WORKER_NAME:-rippy-hauptworker}
@@ -92,6 +102,13 @@ services:
         bind:
           propagation: rslave
       - temp:/app/temp
+      # MakeMKV-Datenverzeichnis PERSISTENT (Befund 25.07.2026, live gemessen):
+      # Hier liegen die KEYDB.cfg — heute die EINZIGE funktionierende
+      # Schlüsselquelle für 4K-UHD, weil MakeMKVs Online-Kanal nichts mehr
+      # liefert —, die AACS-Dumps fehlgeschlagener Discs und settings.conf.
+      # Ohne diesen Mount löschte JEDER `up -d --build` beides; die
+      # Fehlermeldung schickte den Nutzer zu einer Datei, die es nicht mehr gab.
+      - ${MAKEMKV_DATA_HOST:-/srv/rippy/makemkv}:/root/.MakeMKV
     devices:
       # Host-Geräteknoten via .env (OPTICAL_SR/OPTICAL_SG) — je Rechner ANDERS!
       # MakeMKV spricht Laufwerke über die SCSI-Generic-Schicht an; ohne den

docker/api/main.py

@@ -12,6 +12,7 @@ import uuid
 
 import db
 import devices as device_discovery
+import makemkv_daten
 import makemkv_key
 import mounts as mount_verwaltung
 import notify
@@ -154,7 +155,7 @@ async def _auto_rip_wenn_aktiviert(pfad: str):
     else:
         unterordner = einstellungen.get("movieDir") or "movies"
     ziel = os.path.normpath(os.path.join(basis, unterordner))
-    if not ziel.startswith(MEDIA_ROOT):
+    if not unter_wurzel(ziel, MEDIA_ROOT):
         ziel = None
 
     job_id = str(uuid.uuid4())
@@ -250,6 +251,7 @@ class Job(BaseModel):
     title: Optional[str] = None
     error: Optional[str] = None
     can_retry: bool = False  # Rohdaten vorhanden → „Neu komprimieren" sinnvoll
+    meta: Optional[Dict] = None  # Disc-Metadaten (Poster/Jahr/Plot) — fürs Thumbnail in der Jobliste + aktivem Rip-Header
 
 class Device(BaseModel):
     id: str
@@ -265,6 +267,13 @@ class Device(BaseModel):
 def _job_row_to_model(zeile: dict) -> Job:
     """DB-Zeile → UI-Form (Worker-Status 'running' heißt im UI 'processing')."""
     status_map = {"running": "processing"}
+    # meta (JSON-Text) enthält u. a. poster_path — die UI baut daraus das Thumbnail.
+    # Muss hier mit ins Job-Model, sonst schneidet FastAPIs response_model es weg
+    # (Befund 25.07.: meta kam nie in der Jobliste an → Filmstreifen-Platzhalter).
+    try:
+        meta = json.loads(zeile["meta"]) if zeile.get("meta") else None
+    except (ValueError, TypeError):
+        meta = None
     return Job(
         id=zeile["id"],
         type=zeile.get("disc_type") or "unknown",
@@ -275,6 +284,7 @@ def _job_row_to_model(zeile: dict) -> Job:
         progress=zeile.get("progress") or 0,
         title=zeile.get("title"),
         error=zeile.get("error"),
+        meta=meta,
     )
 
 @app.get("/health")
@@ -298,7 +308,7 @@ def _kann_neu_komprimieren(job: dict, work_dir: str) -> bool:
         return False
     if os.path.isdir(os.path.join("/app/temp/raw", job["id"])):
         return True
-    return work_dir.startswith(MEDIA_ROOT) and os.path.isdir(os.path.join(work_dir, job["id"]))
+    return unter_wurzel(work_dir, MEDIA_ROOT) and os.path.isdir(os.path.join(work_dir, job["id"]))
 
 
 @app.get("/jobs", response_model=List[Job])
@@ -349,6 +359,10 @@ class JobCreateRequest(BaseModel):
     main_feature_only: Optional[bool] = None  # pro Rip; None = Setting gilt
     titles: Optional[List[int]] = None  # exakte Titel-Auswahl (Track-Tabelle)
     transcode_node: Optional[str] = None  # gewählter Encoder-Worker (Celery-Node)
+    # Arbeitsverzeichnis NUR für diesen Rip (Commander-Wunsch 25.07.2026:
+    # beim Start wählbar, nicht global vorgegeben). Leer = der Wert aus
+    # Einstellungen → Verarbeitung, der auch für Vollautomatik-Rips gilt.
+    work_dir: Optional[str] = None
 
 
 MEDIA_ROOT = "/app/media"
@@ -359,7 +373,7 @@ def _validiere_ziel(target_dir: Optional[str]) -> Optional[str]:
     if not target_dir:
         return None
     normalisiert = os.path.normpath(target_dir)
-    if not normalisiert.startswith(MEDIA_ROOT):
+    if not unter_wurzel(normalisiert, MEDIA_ROOT):
         raise HTTPException(
             status_code=422,
             detail=f"Ziel muss unter {MEDIA_ROOT} liegen (Shares dort einhängen)",
@@ -408,6 +422,12 @@ async def create_job(request: JobCreateRequest):
             meta_dict["titles"] = titel_liste
     if request.transcode_node:
         meta_dict["transcode_node"] = request.transcode_node
+    # Arbeitsverzeichnis dieses Rips. Dieselbe Pfad-Härte wie beim Ziel: muss
+    # unter /app/media liegen, damit man nicht versehentlich 100 GB Rohdaten
+    # irgendwohin in den Container schreibt.
+    arbeits_dir = _validiere_ziel(request.work_dir)
+    if arbeits_dir:
+        meta_dict["work_dir"] = arbeits_dir
     meta_json = json.dumps(meta_dict) if meta_dict else None
 
     job_id = str(uuid.uuid4())
@@ -442,10 +462,24 @@ def _sicherer_dateiname(name: str) -> bool:
     return bool(name) and "/" not in name and "\\" not in name and not name.startswith(".")
 
 
+def unter_wurzel(pfad: str, wurzel: str) -> bool:
+    """Liegt `pfad` wirklich unterhalb von `wurzel` (oder IST es die Wurzel)?
+
+    Pure Funktion, testbar. Ein nacktes `startswith()` genügt hier nicht:
+    „/app/media-boese/x" beginnt mit „/app/media", liegt aber ausserhalb
+    (Befund 25.07.2026 bei der Durchsicht). Deshalb Gleichheit ODER Wurzel
+    samt Trennzeichen. Erwartet werden normalisierte Container-Pfade mit „/".
+    """
+    if not pfad or not wurzel:
+        return False
+    sauber = wurzel.rstrip("/") or "/"
+    return pfad == sauber or pfad.startswith(sauber + "/")
+
+
 def _job_ausgabeordner(job: dict) -> str:
     """Validierter Ausgabeordner eines Jobs — strikt unter /app/media."""
     ausgabe = os.path.normpath(job.get("output_path") or "")
-    if not ausgabe.startswith(MEDIA_ROOT):
+    if not unter_wurzel(ausgabe, MEDIA_ROOT):
         raise HTTPException(status_code=404, detail="Job hat keinen Ausgabeordner unter /app/media")
     return ausgabe
 
@@ -502,7 +536,7 @@ async def download_job_file(job_id: str, dateiname: str):
     pfad = os.path.join(ausgabe, dateiname)
 
     def pruefe():
-        return os.path.isfile(pfad) and os.path.realpath(pfad).startswith(MEDIA_ROOT)
+        return os.path.isfile(pfad) and unter_wurzel(os.path.realpath(pfad), MEDIA_ROOT)
 
     if not await asyncio.to_thread(pruefe):
         raise HTTPException(status_code=404, detail="Datei nicht gefunden")
@@ -613,7 +647,7 @@ async def retry_transcode(job_id: str):
     # (Einstellungen → Verarbeitung), sonst Container-Default /app/temp/raw.
     einstellungen = await asyncio.to_thread(db.get_settings)
     work_dir = os.path.normpath((einstellungen.get("workDir") or "").strip() or "/")
-    raw_basis = work_dir if work_dir.startswith(MEDIA_ROOT) else "/app/temp/raw"
+    raw_basis = work_dir if unter_wurzel(work_dir, MEDIA_ROOT) else "/app/temp/raw"
     raw_dir = f"{raw_basis}/{job_id}"
     # Zielordner: der Worker schreibt das geplante Ziel beim Rip-Start nach
     # output_path (sprechender Name statt UUID) — alter Fallback bleibt.
@@ -968,7 +1002,7 @@ async def delete_storage_mount(name: str):
 async def browse(path: str = MEDIA_ROOT):
     """Server-seitiger Ordner-Browser für die Ziel-Auswahl (nur unter /app/media)."""
     normalisiert = os.path.normpath(path)
-    if not normalisiert.startswith(MEDIA_ROOT):
+    if not unter_wurzel(normalisiert, MEDIA_ROOT):
         raise HTTPException(status_code=422, detail=f"Nur Pfade unter {MEDIA_ROOT}")
 
     def liste():
@@ -1009,7 +1043,7 @@ class MkdirRequest(BaseModel):
 async def browse_mkdir(request: MkdirRequest):
     """Neuen Ordner unter /app/media anlegen (Speicherziele-Verwaltung)."""
     basis = os.path.normpath(request.path)
-    if not basis.startswith(MEDIA_ROOT):
+    if not unter_wurzel(basis, MEDIA_ROOT):
         raise HTTPException(status_code=422, detail=f"Nur Pfade unter {MEDIA_ROOT}")
     name = request.name.strip()
     if not name or "/" in name or "\\" in name or name.startswith("."):
@@ -1181,6 +1215,203 @@ async def system_info():
     return await asyncio.to_thread(sammle)
 
 
+# Eigene Wurzel für die Datei-Härtung der AACS-Dumps. Bewusst NICHT die
+# MEDIA_ROOT-Helfer (_sicherer_dateiname/_validiere_ziel/_job_ausgabeordner):
+# die prüfen hart gegen /app/media und würden hier IMMER 404 liefern.
+# Das MakeMKV-Datenverzeichnis liegt woanders (in der API auf
+# /app/makemkv-data, im Worker auf /root/.MakeMKV — laut docker-compose.yml
+# beides dasselbe Host-Verzeichnis).
+MAKEMKV_DATA_ROOT = os.path.realpath(makemkv_daten.DATEN_DIR)
+
+
+class KeydbRequest(BaseModel):
+    inhalt: str  # voller Text der KEYDB.cfg (kein Upload — es gibt kein python-multipart)
+
+
+@app.get("/system/keydb")
+async def get_keydb_status():
+    """Was liegt gerade als KEYDB.cfg im MakeMKV-Datenverzeichnis?
+
+    Hintergrund (Befund 25.07.2026, live auf der VM nachgemessen): Bei
+    4K-UHD-Discs meldet MakeMKV "The volume key is unknown for this disc" und
+    holt den Schlüssel NICHT mehr online nach — die dokumentierten
+    Schlüssel-Server lösen weltweit nicht mehr auf. Der einzige heute
+    funktionierende Weg ist eine KEYDB.cfg, die der Nutzer selbst mitbringt.
+    Rippy liefert KEINE Schlüssel mit, lädt keine herunter und verteilt keine —
+    es stellt nur den Platz bereit und zeigt ehrlich an, was dort liegt.
+
+    Fehlendes Verzeichnis oder fehlende Datei ist der NORMALFALL: dann kommt
+    200 mit vorhanden=false zurück, niemals 404 oder 500.
+    """
+    def sammle():
+        return makemkv_daten.keydb_status()
+
+    return await asyncio.to_thread(sammle)
+
+
+@app.post("/system/keydb")
+async def set_keydb(request: KeydbRequest):
+    """Legt die vom Nutzer mitgebrachte KEYDB.cfg ab (atomar, ersetzt die alte).
+
+    WICHTIG für die Ehrlichkeit: Die Datei wirkt erst beim NÄCHSTEN Rip —
+    makemkvcon liest sie beim Prozessstart, ein bereits laufender Rip merkt
+    nichts davon. Genau so steht es auch im Log-Eintrag.
+    """
+    # Reine Prüfung (kein Dateisystem) — fängt den häufigsten Bedienfehler ab:
+    # statt der KEYDB.cfg landet die HTML-Fehlerseite eines Downloads im Feld.
+    fehler = makemkv_daten.keydb_pruefen(request.inhalt)
+    if fehler:
+        raise HTTPException(status_code=422, detail=fehler)
+
+    def schreibe():
+        return makemkv_daten.keydb_schreiben(request.inhalt)
+
+    try:
+        status = await asyncio.to_thread(schreibe)
+    except OSError as e:
+        raise HTTPException(
+            status_code=500,
+            detail=(
+                f"KEYDB.cfg konnte nicht geschrieben werden: {e}. "
+                "Prüfe, ob das MakeMKV-Datenverzeichnis auf der VM existiert und "
+                "beschreibbar ist (Standard: /srv/rippy/makemkv)."
+            ),
+        )
+    await asyncio.to_thread(
+        db.add_log, "success", "makemkv-keydb",
+        f"KEYDB.cfg abgelegt: {status['eintraege']} Zeilen mit Disc-Kennung, "
+        f"{status['groesse_bytes']} Bytes ({status['pfad']}). "
+        "Wirkt erst beim NÄCHSTEN Rip — MakeMKV liest die Datei beim Start.",
+    )
+    return status
+
+
+@app.delete("/system/keydb")
+async def delete_keydb():
+    """Entfernt die KEYDB.cfg (z. B. nach einem Fehlgriff beim Einfügen).
+
+    Auch hier gilt: Die Änderung wirkt erst beim NÄCHSTEN Rip. Fehlt die Datei
+    schon, ist das kein Fehler — es kommt derselbe Zustand mit vorhanden=false.
+    """
+    def loesche():
+        return makemkv_daten.keydb_loeschen()
+
+    try:
+        status = await asyncio.to_thread(loesche)
+    except OSError as e:
+        raise HTTPException(
+            status_code=500,
+            detail=f"KEYDB.cfg konnte nicht entfernt werden: {e}",
+        )
+    await asyncio.to_thread(
+        db.add_log, "warning", "makemkv-keydb",
+        "KEYDB.cfg entfernt. Ab dem NÄCHSTEN Rip fehlen die selbst mitgebrachten "
+        "Schlüssel wieder — UHD-Discs können dann erneut an "
+        "'The volume key is unknown for this disc' scheitern.",
+    )
+    return status
+
+
+@app.get("/system/keystore")
+async def get_keystore():
+    """Wie viele Disc-Schlüssel kennt diese Rippy-Installation?
+
+    Der Schlüsselspeicher (_private_data.tar) ist MakeMKVs eigener Vorrat.
+    Unter Windows füllt MakeMKV ihn selbst; unter Linux nie — deshalb muss er
+    hier von Hand hereingereicht werden (Befund 25.07.2026, siehe
+    makemkv_daten.py). Fehlt er, ist das der Normalfall: 200 mit
+    vorhanden=false, nie 404.
+    """
+    def sammle():
+        return makemkv_daten.schluesselspeicher_status()
+
+    return await asyncio.to_thread(sammle)
+
+
+@app.post("/system/keystore")
+async def set_keystore(request: Request):
+    """Nimmt den Schlüsselspeicher einer MakeMKV-Installation entgegen.
+
+    Der Rohkörper der Anfrage IST die Datei — bewusst kein Multipart-Upload
+    (python-multipart fehlt) und bewusst kein JSON: _private_data.tar ist
+    binär, und Base64 würde sie nur unnötig aufblähen.
+
+    Wirkt ab dem NÄCHSTEN Rip: makemkvcon liest den Speicher beim Start.
+    """
+    rohdaten = await request.body()
+
+    def pruefe_und_schreibe():
+        # Prüfung liest ein mehrere MB grosses tar — gehört deshalb mit in
+        # den Thread und nicht in die Ereignisschleife.
+        fehler = makemkv_daten.private_data_pruefen(rohdaten)
+        if fehler:
+            return fehler, None
+        return "", makemkv_daten.private_data_schreiben(rohdaten)
+
+    try:
+        fehler, status = await asyncio.to_thread(pruefe_und_schreibe)
+    except OSError as e:
+        raise HTTPException(
+            status_code=500,
+            detail=(
+                f"Schlüsselspeicher konnte nicht geschrieben werden: {e}. "
+                "Prüfe, ob das MakeMKV-Datenverzeichnis auf der VM existiert "
+                "und beschreibbar ist (Standard: /srv/rippy/makemkv)."
+            ),
+        )
+    if fehler:
+        raise HTTPException(status_code=422, detail=fehler)
+    await asyncio.to_thread(
+        db.add_log, "success", "makemkv-keydb",
+        f"Schlüsselspeicher übernommen: {status['schluessel']} Disc-Schlüssel, "
+        f"{status['groesse_bytes']} Bytes. Wirkt ab dem NÄCHSTEN Rip.",
+    )
+    return status
+
+
+@app.get("/system/aacs-dumps")
+async def get_aacs_dumps():
+    """AACS-Dumps, die MakeMKV selbst abgelegt hat (neueste zuerst).
+
+    MakeMKV schreibt sie beim gescheiterten UHD-Versuch ins Datenverzeichnis
+    (Meldung 3332 "Saved AACS dump file as file:///root/.MakeMKV/<name>.tgz",
+    am 25.07.2026 so beobachtet). Rippy wertet sie nicht aus und schickt sie
+    nirgendwohin — es zeigt nur, dass sie da sind, damit der Nutzer selbst
+    entscheiden kann, was er damit tut.
+    """
+    def liste():
+        return {"dumps": makemkv_daten.dumps_auflisten()}
+
+    return await asyncio.to_thread(liste)
+
+
+@app.get("/system/aacs-dumps/{dateiname}")
+async def download_aacs_dump(dateiname: str):
+    """Lädt EINEN AACS-Dump herunter.
+
+    Pfad-Validierung genauso streng wie beim Job-Datei-Download: nackter Name
+    ohne Pfadtrenner und ohne führenden Punkt (ist_aacs_dump) PLUS realpath,
+    der das MakeMKV-Datenverzeichnis nicht verlassen darf (kein ..-Ausbruch,
+    kein Symlink nach draußen).
+    """
+    if not makemkv_daten.ist_aacs_dump(dateiname):
+        raise HTTPException(
+            status_code=404,
+            detail="Kein gültiger Dump-Name — erwartet wird eine .tgz-Datei ohne Pfadangabe.",
+        )
+    pfad = os.path.join(MAKEMKV_DATA_ROOT, dateiname)
+
+    def pruefe():
+        return os.path.isfile(pfad) and unter_wurzel(os.path.realpath(pfad), MAKEMKV_DATA_ROOT)
+
+    if not await asyncio.to_thread(pruefe):
+        raise HTTPException(
+            status_code=404,
+            detail="Dump nicht gefunden — MakeMKV legt ihn erst beim gescheiterten UHD-Versuch an.",
+        )
+    return FileResponse(pfad, filename=dateiname, media_type="application/gzip")
+
+
 class NotificationTestRequest(BaseModel):
     url: str
 

docker/api/makemkv_daten.py

@@ -0,0 +1,375 @@
+"""MakeMKV-Datenverzeichnis: Schluesselspeicher, KEYDB.cfg, AACS-Dumps.
+
+WARUM ES DIESE DATEI GIBT (Befund 25.07.2026, auf BEIDEN Maschinen gemessen):
+4K-UHD-Discs scheiterten mit "The volume key is unknown for this disc". Die
+Ursache ist weder die Disc noch das Laufwerk — LibreDrive v06.3 laeuft und
+MakeMKV liest die Disc — sondern:
+
+    makemkvcon unter LINUX ruft die Disc-Schluessel nie ab.
+    Die Windows-Version tut es.
+
+Gemessen, nicht vermutet:
+  * Linux: in KEINEM Lauf auch nur eine Verbindung nach draussen. Geprueft mit
+    leerem UND mit gefuelltem Schluesselspeicher, mit und ohne --noscan, mit
+    dev:/dev/sr0 und mit disc:0, und mit erzwungener frischer Pruefung
+    (update.conf geloescht, Meldung 5074 belegt den Web-Kontakt). Immer:
+    keine Verbindung, kein Schluessel.
+  * Windows, dieselbe Disc, dasselbe Laufwerk: Meldung 3338 "Downloading
+    latest HK to ...", Verbindung nach 185.84.108.20:443
+    (web33.majordomo.ru), _private_data.tar waechst — und die Disc geht auf
+    (TCOUNT:5, "Operation successfully completed").
+  * Der Code dafuer steckt auch im Linux-Binary: die Meldungsvorlage
+    "Downloading latest %1 to %2 ..." steht in makemkvcon. Sie loest nur nie
+    aus. Gleiches Symptom im Forum, seit Jahren offen und unbeantwortet.
+
+FRUEHERE FEHLDIAGNOSE, bewusst festgehalten: An dieser Stelle stand zuerst,
+MakeMKVs Schluessel-Kanal sei abgeschaltet. Das war FALSCH. Die Herleitung
+stuetzte sich auf zwei Hostnamen aus alten Forumsbeitraegen
+(hkdata.fairuse.org, hkdata.crabdance.com), die tatsaechlich nicht mehr
+aufloesen — MakeMKV benutzt sie aber laengst nicht mehr. Der Dienst lebt, der
+Worker erreicht ihn sogar; er wird unter Linux nur nie gefragt.
+
+WAS DARAUS FOLGT: Der Schluesselspeicher (_private_data.tar) muss von einer
+MakeMKV-Installation kommen, die ihn wirklich abruft — praktisch von Windows.
+Rippy nimmt ihn unter Einstellungen -> System entgegen. Die KEYDB.cfg bleibt
+der Notnagel fuer Pressungen, die auch MakeMKV selbst nicht kennt.
+
+Rippy liefert KEINE Schluessel mit, laedt keine herunter und verteilt keine.
+Es verwaltet nur, was der Nutzer selbst mitbringt.
+
+QUELLEN (AGENTS Regel D — externe Schnittstellen nie aus dem Kopf):
+  * Linux laedt keine Hashed Keys — dasselbe Symptom, mehrfach berichtet:
+    https://forum.makemkv.com/forum/viewtopic.php?t=25782
+    https://forum.makemkv.com/forum/viewtopic.php?t=34022
+  * Schluessel liegen als hkd_*.bin in _private_data.tar:
+    https://forum.makemkv.com/forum/viewtopic.php?t=32675
+  * Datenverzeichnis und Dateiname KEYDB.cfg GROSS geschrieben (unter Linux
+    case-sensitiv), dort geloest mit "cp KEYDB.cfg ~/.MakeMKV/":
+    https://forum.makemkv.com/forum/viewtopic.php?t=30636
+  * Zeilenformat der KEYDB.cfg (libaacs): Disc-Kennung = 40 Hex-Zeichen,
+    optional mit 0x-Praefix, dann "= Titel", danach optionale Felder wie
+    "| V | <32 Hex>"; Zeilen ab ";" sind Kommentare:
+    https://github.com/ShiftMediaProject/libaacs/blob/master/KEYDB.cfg
+  * Den AACS-Dump legt MakeMKV selbst ab, Meldung 3332 "Saved AACS dump file
+    as file:///root/.MakeMKV/<name>.tgz" (am 25.07.2026 so beobachtet).
+
+ZWILLINGSDATEI: liegt identisch unter docker/api/ und docker/worker/ — beide
+Images brauchen sie, ein gemeinsames Paket gibt es in diesem Projekt nicht
+(gleiche Lage wie bei db.py). Aenderungen IMMER in BEIDEN Dateien nachziehen.
+"""
+
+import io
+import os
+import re
+import tarfile
+from datetime import datetime, timezone
+
+# Container-Pfad aus der Umgebung: /root/.MakeMKV im Worker (nur dort sucht
+# makemkvcon), /app/makemkv-data in der API. Beide zeigen laut
+# docker-compose.yml auf DASSELBE Host-Verzeichnis.
+DATEN_DIR = os.getenv("MAKEMKV_DATA_DIR", "/root/.MakeMKV")
+
+# GROSS geschrieben — unter Linux case-sensitiv, "keydb.cfg" wird ignoriert.
+KEYDB_NAME = "KEYDB.cfg"
+
+# Obergrenze fuer den Upload. Eine vollstaendige oeffentliche KEYDB.cfg liegt
+# im einstelligen MB-Bereich; 64 MB sind reichlich Luft und verhindern, dass
+# eine versehentlich hochgeladene Riesendatei den Speicher vollschreibt.
+MAX_KEYDB_BYTES = 64 * 1024 * 1024
+
+# Eine Disc-Zeile beginnt mit der 40 Zeichen langen Hex-Kennung (optional mit
+# 0x davor), danach folgt das Gleichheitszeichen. Alles andere (Kommentare ab
+# ";", Leerzeilen, Fortsetzungsfelder) zaehlt nicht als Eintrag.
+_DISC_ZEILE = re.compile(r"^\s*(?:0x)?[0-9a-fA-F]{40}\s*=")
+
+
+def _iso(zeitstempel: float) -> str:
+    """Unix-Zeit -> ISO-8601 in UTC (sekundengenau), wie db.utcnow() es tut."""
+    return datetime.fromtimestamp(zeitstempel, timezone.utc).isoformat(timespec="seconds")
+
+
+def keydb_pfad(daten_dir: str = None) -> str:
+    """Voller Pfad zur KEYDB.cfg im Datenverzeichnis."""
+    return os.path.join(daten_dir or DATEN_DIR, KEYDB_NAME)
+
+
+def zaehle_disc_eintraege(inhalt: str) -> int:
+    """Zeilen mit Disc-Kennung zaehlen (pure Funktion, testbar).
+
+    Bewusst eine Heuristik und keine vollstaendige Auswertung: MakeMKV liest
+    die Datei mit seinem eigenen Parser, und wie viele Eintraege es daraus
+    macht, ist von aussen nicht sichtbar. Die Zahl dient nur dazu, im UI
+    "da liegt wirklich etwas drin" von "leere oder falsche Datei" zu
+    unterscheiden — sie wird deshalb auch genau so beschriftet.
+    """
+    return sum(1 for zeile in inhalt.splitlines() if _DISC_ZEILE.match(zeile))
+
+
+def keydb_pruefen(inhalt: str) -> str:
+    """Prueft hochgeladenen Inhalt; gibt deutschen Fehlertext oder "" zurueck.
+
+    Verhindert den haeufigsten Bedienfehler: statt der KEYDB.cfg landet die
+    HTML-Fehlerseite eines Downloads oder eine leere Datei im Verzeichnis —
+    MakeMKV wuerde dann still weiter "volume key is unknown" melden.
+    """
+    if not inhalt.strip():
+        return "Die Datei ist leer."
+    if len(inhalt.encode("utf-8")) > MAX_KEYDB_BYTES:
+        return (
+            "Die Datei ist groesser als "
+            f"{MAX_KEYDB_BYTES // (1024 * 1024)} MB — das ist keine KEYDB.cfg."
+        )
+    if inhalt.lstrip()[:1] == "<":
+        return (
+            "Das sieht nach HTML aus, nicht nach einer KEYDB.cfg — "
+            "vermutlich wurde eine Fehlerseite statt der Datei geladen."
+        )
+    if zaehle_disc_eintraege(inhalt) == 0:
+        return (
+            "Keine einzige Zeile mit Disc-Kennung gefunden (40 Hex-Zeichen, "
+            "dann ein Gleichheitszeichen). Das ist keine KEYDB.cfg."
+        )
+    return ""
+
+
+def keydb_status(daten_dir: str = None) -> dict:
+    """Zustand der KEYDB.cfg. Fehlt sie, ist das der Normalfall, kein Fehler."""
+    pfad = keydb_pfad(daten_dir)
+    try:
+        angaben = os.stat(pfad)
+    except OSError:
+        return {
+            "vorhanden": False,
+            "pfad": pfad,
+            "groesse_bytes": 0,
+            "eintraege": 0,
+            "geaendert": "",
+        }
+    eintraege = 0
+    try:
+        with open(pfad, encoding="utf-8", errors="replace") as datei:
+            eintraege = zaehle_disc_eintraege(datei.read())
+    except OSError:
+        pass  # Datei da, aber unlesbar: Groesse/Datum stimmen trotzdem
+    return {
+        "vorhanden": True,
+        "pfad": pfad,
+        "groesse_bytes": angaben.st_size,
+        "eintraege": eintraege,
+        "geaendert": _iso(angaben.st_mtime),
+    }
+
+
+def keydb_schreiben(inhalt: str, daten_dir: str = None) -> dict:
+    """Schreibt die KEYDB.cfg atomar und meldet den neuen Zustand.
+
+    Erst in eine Nebendatei, dann os.replace: waehrend ein Rip laeuft, darf
+    makemkvcon niemals eine halb geschriebene Datei zu sehen bekommen.
+    """
+    pfad = keydb_pfad(daten_dir)
+    os.makedirs(os.path.dirname(pfad), exist_ok=True)
+    neben = pfad + ".neu"
+    try:
+        with open(neben, "w", encoding="utf-8", newline="\n") as datei:
+            datei.write(inhalt)
+        os.replace(neben, pfad)
+    except OSError:
+        # Die Nebendatei nie liegen lassen: eine halb geschriebene
+        # KEYDB.cfg.neu verwirrt jeden, der ins Verzeichnis schaut, und
+        # belegt im Extremfall 64 MB, die niemand mehr aufräumt.
+        try:
+            os.remove(neben)
+        except OSError:
+            pass
+        raise
+    return keydb_status(daten_dir)
+
+
+def keydb_loeschen(daten_dir: str = None) -> dict:
+    """Entfernt die KEYDB.cfg (z. B. nach einem Fehlgriff beim Hochladen).
+
+    Nur "Datei war schon weg" wird geschluckt — das ist das gewünschte
+    Ergebnis. Jeder andere Fehler (schreibgeschützter Mount, fremder
+    Eigentümer) MUSS nach oben durch: sonst meldete die API einen Erfolg,
+    den es nicht gab, und die Datei wirkte beim nächsten Rip weiter.
+    """
+    try:
+        os.remove(keydb_pfad(daten_dir))
+    except FileNotFoundError:
+        pass
+    return keydb_status(daten_dir)
+
+
+def ist_aacs_dump(name: str) -> bool:
+    """Dateiname eines AACS-Dumps? (pure Funktion, testbar)
+
+    MakeMKV legt ihn als <MKB..._NAME_....>.tgz direkt im Datenverzeichnis ab
+    (Meldung 3332). Pfadtrenner und fuehrende Punkte werden hier schon
+    ausgeschlossen, damit der Download-Endpunkt keine Pfad-Tricks erlaubt.
+    """
+    return (
+        name.endswith(".tgz")
+        and "/" not in name
+        and "\\" not in name
+        and not name.startswith(".")
+    )
+
+
+def dumps_auflisten(daten_dir: str = None) -> list:
+    """Alle AACS-Dumps im Datenverzeichnis, neueste zuerst."""
+    ordner = daten_dir or DATEN_DIR
+    try:
+        namen = os.listdir(ordner)
+    except OSError:
+        return []
+    liste = []
+    for name in namen:
+        if not ist_aacs_dump(name):
+            continue
+        try:
+            angaben = os.stat(os.path.join(ordner, name))
+        except OSError:
+            continue
+        liste.append(
+            {
+                "name": name,
+                "groesse_bytes": angaben.st_size,
+                "geaendert": _iso(angaben.st_mtime),
+                "_sort": angaben.st_mtime,
+            }
+        )
+    liste.sort(key=lambda eintrag: eintrag["_sort"], reverse=True)
+    for eintrag in liste:
+        del eintrag["_sort"]
+    return liste
+
+
+# --- Schluesselspeicher (_private_data.tar) -------------------------------
+#
+# Das ist MakeMKVs eigener Speicher fuer die "Hashed Keys": ein tar-Archiv mit
+# hkd_*.bin-Eintraegen. Unter Windows fuellt MakeMKV es selbst (Meldung 3338),
+# unter Linux nie — siehe Modul-Kopf. Rippy nimmt die Datei deshalb entgegen
+# und legt sie ins Datenverzeichnis; MakeMKV liest sie beim naechsten Start.
+
+PRIVATE_DATA_NAME = "_private_data.tar"
+
+# Der Speicher lag am 25.07.2026 bei rund 6 MB und waechst mit jeder neuen
+# Pressung. 64 MB sind reichlich Luft — und derselbe Wert wie
+# client_max_body_size in docker/ui/nginx.conf: waere die Grenze hier hoeher,
+# wuerde nginx den Upload abweisen, bevor die API ihn ueberhaupt sieht.
+MAX_PRIVATE_DATA_BYTES = 64 * 1024 * 1024
+
+
+def private_data_pfad(daten_dir: str = None) -> str:
+    """Voller Pfad zum Schluesselspeicher im Datenverzeichnis."""
+    return os.path.join(daten_dir or DATEN_DIR, PRIVATE_DATA_NAME)
+
+
+def zaehle_schluessel(rohdaten: bytes) -> int:
+    """Anzahl der hkd_*.bin-Eintraege im Archiv (pure Funktion, testbar).
+
+    Das ist die ehrliche Kennzahl fuer "wie viele Disc-Schluessel kennt diese
+    Installation". Ein frischer, leerer Speicher enthaelt nur eine
+    Index-Datei und kommt hier auf 0 — genau der Zustand, in dem jede
+    unbekannte UHD-Disc scheitert.
+    """
+    try:
+        with tarfile.open(fileobj=io.BytesIO(rohdaten)) as archiv:
+            return sum(1 for name in archiv.getnames() if name.startswith("hkd_"))
+    except (tarfile.TarError, OSError, EOFError):
+        return 0
+
+
+def private_data_pruefen(rohdaten: bytes) -> str:
+    """Prueft hochgeladene Rohdaten; deutscher Fehlertext oder "".
+
+    Faengt die beiden Bedienfehler ab, die sonst still danebengehen: eine
+    voellig andere Datei hochladen, oder den Speicher einer Installation, die
+    selbst noch keine Schluessel geholt hat (dann aendert sich nichts, und
+    niemand versteht warum).
+    """
+    if not rohdaten:
+        return "Die Datei ist leer."
+    if len(rohdaten) > MAX_PRIVATE_DATA_BYTES:
+        return (
+            "Die Datei ist groesser als "
+            f"{MAX_PRIVATE_DATA_BYTES // (1024 * 1024)} MB — das ist kein "
+            "MakeMKV-Schluesselspeicher."
+        )
+    try:
+        with tarfile.open(fileobj=io.BytesIO(rohdaten)) as archiv:
+            namen = archiv.getnames()
+    except (tarfile.TarError, OSError, EOFError):
+        return (
+            "Das ist kein tar-Archiv. Erwartet wird die Datei "
+            f"{PRIVATE_DATA_NAME} aus dem MakeMKV-Datenverzeichnis."
+        )
+    if not any(name.startswith("hkd_") for name in namen):
+        return (
+            "In dieser Datei steckt kein einziger Schluessel (kein hkd_*.bin). "
+            "Sie stammt vermutlich von einer MakeMKV-Installation, die selbst "
+            "noch keine geholt hat — oeffne dort erst einmal eine Disc."
+        )
+    return ""
+
+
+def schluesselspeicher_status(daten_dir: str = None) -> dict:
+    """Zustand des Schluesselspeichers. Fehlt er, ist das kein Fehler."""
+    pfad = private_data_pfad(daten_dir)
+    try:
+        angaben = os.stat(pfad)
+        with open(pfad, "rb") as datei:
+            schluessel = zaehle_schluessel(datei.read())
+    except OSError:
+        return {
+            "vorhanden": False,
+            "pfad": pfad,
+            "groesse_bytes": 0,
+            "schluessel": 0,
+            "geaendert": "",
+        }
+    return {
+        "vorhanden": True,
+        "pfad": pfad,
+        "groesse_bytes": angaben.st_size,
+        "schluessel": schluessel,
+        "geaendert": _iso(angaben.st_mtime),
+    }
+
+
+def private_data_schreiben(rohdaten: bytes, daten_dir: str = None) -> dict:
+    """Legt den Schluesselspeicher atomar ab und meldet den neuen Zustand.
+
+    Atomar aus demselben Grund wie bei der KEYDB.cfg: waehrend ein Rip laeuft,
+    darf makemkvcon nie ein halb geschriebenes Archiv sehen.
+    """
+    pfad = private_data_pfad(daten_dir)
+    os.makedirs(os.path.dirname(pfad), exist_ok=True)
+    neben = pfad + ".neu"
+    try:
+        with open(neben, "wb") as datei:
+            datei.write(rohdaten)
+        os.replace(neben, pfad)
+    except OSError:
+        try:
+            os.remove(neben)
+        except OSError:
+            pass
+        raise
+    return schluesselspeicher_status(daten_dir)
+
+
+def settings_conf_zusammenfuehren(inhalt: str, key: str) -> str:
+    """app_Key setzen, ohne den Rest der settings.conf zu verlieren (pure).
+
+    Bis zum 25.07.2026 haben entrypoint.sh UND tasks.py die Datei komplett
+    ueberschrieben. Mit dem jetzt persistenten Datenverzeichnis waere damit
+    bei jedem Containerstart und vor jedem Rip alles andere weg — z. B.
+    app_UpdateEnable. Leerer Key laesst die vorhandene Zeile ebenfalls fallen,
+    damit ein bewusst geleerter Key nicht heimlich weiterwirkt.
+    """
+    zeilen = [z for z in inhalt.splitlines() if not z.lstrip().startswith("app_Key")]
+    if key:
+        zeilen.append('app_Key = "{}"'.format(key))
+    text = "\n".join(zeilen).strip("\n")
+    return text + "\n" if text else ""

docker/api/makemkv_key.py

@@ -11,8 +11,14 @@ Dieses Modul holt den aktuellen Key vom Forum und schreibt ihn in die Settings
 Rebuild/Neustart, ab dem naechsten Rip.
 
 Wichtig: Das ist die kostenlose, oeffentliche Beta-LIZENZ der Software selbst —
-NICHT das Entschluesseln oder Verteilen von Disc-Schluesseln. Den AACS-Schluessel
-zieht MakeMKV via LibreDrive ohnehin selbst aus dem Laufwerk.
+NICHT das Entschluesseln oder Verteilen von Disc-Schluesseln. Diese Grenze gilt
+unveraendert; Rippy liefert keine Disc-Schluessel mit und verteilt keine.
+
+Richtigstellung 25.07.2026: Hier stand frueher, MakeMKV ziehe den AACS-Schluessel
+via LibreDrive ohnehin selbst aus dem Laufwerk. Das stimmt fuer Blu-ray, aber
+NICHT fuer 4K-UHD — dort braucht MakeMKV den Volume-Key der jeweiligen Pressung,
+und den bekommt es weder aus dem Laufwerk noch (heute) aus dem Netz. Belege und
+Messungen stehen im Modul-Kopf von makemkv_daten.py.
 
 Quelle/Format dokumentiert (AGENTS Regel D — nicht geraten):
 - Forum-Thread: https://forum.makemkv.com/forum/viewtopic.php?t=1053

docker/api/test_api_smoke.py

@@ -18,7 +18,16 @@ def test_main_importierbar_und_routen_verdrahtet():
     from main import app
 
     routen = {route.path for route in app.routes}
-    for pfad in ("/health", "/jobs", "/devices", "/logs", "/settings", "/prescan"):
+    for pfad in (
+        "/health", "/jobs", "/devices", "/logs", "/settings", "/prescan",
+        # KEYDB.cfg + AACS-Dumps: der Platz für die selbst mitgebrachte
+        # Schlüsseldatei (Befund 25.07.2026 — MakeMKV holt UHD-Schlüssel nicht
+        # mehr online nach). Ohne diese Routen ist die Seite im UI tot.
+        "/system/keydb", "/system/aacs-dumps", "/system/aacs-dumps/{dateiname}",
+        # Der Hauptweg fuer 4K-UHD (25.07.2026): makemkvcon holt Disc-Schluessel
+        # unter Linux nie selbst, sie kommen von Hand ueber diesen Endpunkt.
+        "/system/keystore",
+    ):
         assert pfad in routen, f"Route {pfad} fehlt"
 
 
@@ -57,3 +66,31 @@ def test_remount_blockiert_den_api_start_nicht():
         "remount muss als Hintergrund-Task laufen (nicht blockierend)"
     assert "await asyncio.to_thread(remount)" not in quelle, \
         "remount darf nicht mehr direkt awaited werden (blockiert sonst den Start)"
+
+
+def test_unter_wurzel_faellt_nicht_auf_praefix_namen_herein():
+    """Befund 25.07.2026: In main.py prueften neun Stellen mit nacktem
+    startswith(MEDIA_ROOT) — darunter /browse und /browse/mkdir, wo der Pfad
+    vom Nutzer kommt. „/app/media-boese/x" beginnt mit „/app/media", liegt
+    aber ausserhalb. Zwilling von tasks.unter_wurzel im Worker."""
+    from main import unter_wurzel
+
+    assert unter_wurzel("/app/media", "/app/media") is True
+    assert unter_wurzel("/app/media/movies", "/app/media") is True
+    assert unter_wurzel("/app/media-boese/x", "/app/media") is False
+    assert unter_wurzel("/app/mediaX", "/app/media") is False
+    assert unter_wurzel("/etc/passwd", "/app/media") is False
+    assert unter_wurzel("", "/app/media") is False
+    assert unter_wurzel("/app/media", "") is False
+    assert unter_wurzel("/app/media/movies", "/app/media/") is True
+
+
+def test_sicherer_dateiname_blockt_pfad_tricks():
+    from main import _sicherer_dateiname
+
+    assert _sicherer_dateiname("film.mkv") is True
+    assert _sicherer_dateiname("../../etc/passwd") is False
+    assert _sicherer_dateiname("a/b.mkv") is False
+    assert _sicherer_dateiname("a\b.mkv") is False
+    assert _sicherer_dateiname(".versteckt") is False
+    assert _sicherer_dateiname("") is False

docker/api/test_makemkv_daten.py

@@ -0,0 +1,118 @@
+"""Tests fuer die puren Helfer aus makemkv_daten.
+
+Bewusst OHNE Dateisystem, DB und fcntl — deshalb laufen sie auch auf Windows
+und nicht nur in der Ampel. Geprueft wird genau das, was ohne Container und
+ohne echte Disc entscheidbar ist: das Zeilenformat der KEYDB.cfg, die
+Plausibilitaetspruefung beim Hochladen, die Namenshaerte der AACS-Dumps und
+das Zusammenfuehren der settings.conf.
+"""
+from makemkv_daten import (
+    ist_aacs_dump,
+    keydb_pruefen,
+    settings_conf_zusammenfuehren,
+    zaehle_disc_eintraege,
+)
+
+# Echte Beispielzeilen im libaacs-Format: 40 Hex-Zeichen Disc-Kennung, dann
+# "= Titel". Zweite Zeile mit 0x-Praefix, weil die oeffentlichen Dateien beide
+# Schreibweisen mischen (Fundstelle steht im Modul-Docstring von makemkv_daten).
+_GUELTIG = """; KEYDB.cfg — Beispiel
+
+0123456789ABCDEF0123456789ABCDEF01234567 = Akira
+0xFEDCBA9876543210FEDCBA9876543210FEDCBA98 = Blade Runner | V | 00112233445566778899AABBCCDDEEFF
+"""
+
+
+def test_zaehle_disc_eintraege_zaehlt_nur_echte_disc_zeilen():
+    # Kommentar- und Leerzeilen duerfen NICHT mitgezaehlt werden, sonst meldet
+    # das UI "da liegt was drin", obwohl die Datei keinen Schluessel enthaelt.
+    assert zaehle_disc_eintraege(_GUELTIG) == 2
+
+
+def test_zaehle_disc_eintraege_ohne_disc_zeile_ist_null():
+    nur_kommentare = "; nur ein Kommentar\n\n;noch einer\n"
+    assert zaehle_disc_eintraege(nur_kommentare) == 0
+    assert zaehle_disc_eintraege("") == 0
+
+
+def test_zaehle_disc_eintraege_akzeptiert_0x_praefix_einzeln():
+    assert zaehle_disc_eintraege("0x0123456789abcdef0123456789abcdef01234567 = Tenet") == 1
+
+
+def test_zaehle_disc_eintraege_lehnt_zu_kurze_kennung_ab():
+    # 39 statt 40 Hex-Zeichen: das ist keine Disc-Kennung, sondern Tippfehler
+    # oder eine abgeschnittene Datei — darf nicht als Eintrag durchgehen.
+    assert zaehle_disc_eintraege("0123456789ABCDEF0123456789ABCDEF0123456 = Kurz") == 0
+
+
+def test_keydb_pruefen_meldet_leere_datei():
+    assert keydb_pruefen("") != ""
+    assert keydb_pruefen("   \n\n ") != ""
+
+
+def test_keydb_pruefen_erkennt_html():
+    # Haeufigster Bedienfehler: statt der Datei landet die HTML-Fehlerseite
+    # eines Downloads im Feld. MakeMKV wuerde dann still weiter meckern.
+    fehler = keydb_pruefen("<!DOCTYPE html>\n<html><body>404 Not Found</body></html>\n")
+    assert "HTML" in fehler
+
+
+def test_keydb_pruefen_meldet_datei_ohne_disc_zeile():
+    # Text ist da, aber keine einzige Disc-Kennung — z. B. eine Liesmich-Datei.
+    assert keydb_pruefen("Das hier ist irgendein Text ohne Schluessel.\n") != ""
+
+
+def test_keydb_pruefen_laesst_gueltige_datei_durch():
+    # "" heisst laut Vertrag: alles in Ordnung, darf geschrieben werden.
+    assert keydb_pruefen(_GUELTIG) == ""
+
+
+def test_ist_aacs_dump_erkennt_echten_namen():
+    # So heisst der Dump, den MakeMKV am 25.07.2026 fuer Akira UHD abgelegt hat
+    # (Meldung 3332) — dieser Name MUSS zum Download durchkommen.
+    assert ist_aacs_dump("MKB20_v76_UHD_AKIRA_C02B.tgz") is True
+
+
+def test_ist_aacs_dump_blockt_pfad_tricks():
+    # Der Download-Endpunkt haengt den Namen an das Datenverzeichnis — ein
+    # durchgelassenes ".." oder ein Pfadtrenner waere ein Ausbruch.
+    assert ist_aacs_dump("../x.tgz") is False
+    assert ist_aacs_dump("../../etc/passwd.tgz") is False
+    assert ist_aacs_dump("unter/ordner.tgz") is False
+    assert ist_aacs_dump("unter\\ordner.tgz") is False
+    assert ist_aacs_dump(".versteckt.tgz") is False
+
+
+def test_ist_aacs_dump_lehnt_andere_endungen_ab():
+    # Nur die Dumps sollen abholbar sein — nicht settings.conf, nicht
+    # _private_data.tar und schon gar nicht die KEYDB.cfg selbst.
+    assert ist_aacs_dump("KEYDB.cfg") is False
+    assert ist_aacs_dump("settings.conf") is False
+    assert ist_aacs_dump("_private_data.tar") is False
+    assert ist_aacs_dump("") is False
+
+
+def test_settings_conf_ersetzt_alten_key_und_behaelt_den_rest():
+    # Regression: bis 25.07.2026 wurde die Datei komplett ueberschrieben. Mit
+    # dem jetzt persistenten Datenverzeichnis waere app_UpdateEnable vor jedem
+    # Rip weg gewesen.
+    alt = 'app_UpdateEnable = "1"\napp_Key = "T-alt"\napp_DestinationDir = "/tmp"\n'
+    neu = settings_conf_zusammenfuehren(alt, "T-neu")
+    assert 'app_Key = "T-neu"' in neu
+    assert "T-alt" not in neu
+    assert 'app_UpdateEnable = "1"' in neu
+    assert 'app_DestinationDir = "/tmp"' in neu
+
+
+def test_settings_conf_leerer_key_entfernt_die_zeile():
+    # Ein bewusst geleerter Key darf nicht heimlich weiterwirken.
+    neu = settings_conf_zusammenfuehren('app_Key = "T-alt"\napp_UpdateEnable = "1"\n', "")
+    assert "app_Key" not in neu
+    assert 'app_UpdateEnable = "1"' in neu
+
+
+def test_settings_conf_aus_dem_nichts_endet_mit_zeilenumbruch():
+    # Erster Start: es gibt noch keine settings.conf. MakeMKV erwartet eine
+    # Datei mit abschliessendem Zeilenumbruch.
+    assert settings_conf_zusammenfuehren("", "T-neu") == 'app_Key = "T-neu"\n'
+    assert settings_conf_zusammenfuehren("", "") == ""

docker/ui/nginx.conf

@@ -17,6 +17,12 @@ server {
         # SSE (/api/stream/jobs) braucht ungepufferte, lange Verbindungen:
         proxy_buffering off;
         proxy_read_timeout 3600s;
+        # Der nginx-Default ist 1 MB. Eine echte KEYDB.cfg ist deutlich groesser,
+        # der Upload ueber POST /api/system/keydb wuerde also schon hier mit
+        # 413 abgewiesen — die API bekaeme die Anfrage nie zu sehen und das UI
+        # haette keinen detail-Text, den es anzeigen koennte. 64m entspricht dem
+        # Limit MAX_KEYDB_BYTES in makemkv_daten.py.
+        client_max_body_size 64m;
     }
 
     location / {

docker/ui/src/components/DeviceDiscovery.tsx

@@ -90,6 +90,7 @@ export default function DeviceDiscovery() {
         ...(optionen?.mainFeatureOnly !== undefined ? { main_feature_only: optionen.mainFeatureOnly } : {}),
         ...(optionen?.titles && optionen.titles.length ? { titles: optionen.titles } : {}),
         ...(optionen?.transcodeNode ? { transcode_node: optionen.transcodeNode } : {}),
+        ...(optionen?.workDir ? { work_dir: optionen.workDir } : {}),
       })
       setActionFeedback(`✓ Job angelegt (${response.data.id.slice(0, 8)}…) — Fortschritt im Dashboard`)
       toast('success', 'Rip gestartet — Fortschritt unten bei „Neueste Jobs"')

docker/ui/src/components/FirstRunWizard.tsx

@@ -14,6 +14,7 @@ interface WorkerInfo {
 const ENCODER_LABELS: Record<string, string> = {
   'cpu-x264': 'CPU · H.264 (x264)',
   'cpu-x265': 'CPU · H.265 (x265)',
+  'cpu-av1': 'CPU · AV1 (SVT-AV1)',
   'vaapi': 'Hardware · VAAPI (AMD/Intel)',
   'nvenc': 'Hardware · NVENC (NVIDIA)',
 }

docker/ui/src/components/RipTargetModal.tsx

@@ -1,5 +1,5 @@
 import { useState, useEffect } from 'react'
-import { Folder, FolderOpen, File, ArrowUp, CheckCircle, Film, Tv, Music, Cpu } from 'lucide-react'
+import { Folder, FolderOpen, File, ArrowUp, CheckCircle, Film, Tv, Music, Cpu, HardDrive } from 'lucide-react'
 import { api } from '../lib/api'
 import { Modal } from './ui/Modal'
 import { Button } from './ui/Button'
@@ -19,6 +19,15 @@ export interface RipOptionen {
   mainFeatureOnly?: boolean
   titles?: number[]
   transcodeNode?: string  // gewählter Encoder-Worker (Celery-Node) oder leer = auto
+  workDir?: string        // Arbeitsverzeichnis für die Rohdaten; leer = Einstellung
+}
+
+// Ein Ablageziel aus GET /storage-targets.
+interface StorageZiel {
+  name: string
+  path: string
+  is_mount: boolean
+  free_gb: number | null
 }
 
 interface WorkerWahl {
@@ -29,7 +38,8 @@ interface WorkerWahl {
 }
 
 const ENCODER_KURZ: Record<string, string> = {
-  'cpu-x264': 'H.264', 'cpu-x265': 'H.265', 'vaapi': 'VAAPI⚡', 'nvenc': 'NVENC⚡',
+  'cpu-x264': 'H.264', 'cpu-x265': 'H.265', 'cpu-av1': 'AV1',
+  'vaapi': 'VAAPI⚡', 'nvenc': 'NVENC⚡',
 }
 
 interface TitelInfo {
@@ -112,6 +122,12 @@ export default function RipTargetModal({ isOpen, initialType, discTitle, deviceI
   const [browseDirs, setBrowseDirs] = useState<BrowseDir[]>([])
   const [browseFiles, setBrowseFiles] = useState<{ name: string, size_mb: number | null }[]>([])
   const [customPath, setCustomPath] = useState('')
+  // Arbeitsverzeichnis dieses Rips (Commander-Wunsch 25.07.2026: hier wählbar,
+  // nicht global vorgegeben). '' = der Wert aus den Einstellungen, der auch
+  // bei Vollautomatik-Rips gilt, weil dort niemand gefragt wird.
+  const [arbeitsZiele, setArbeitsZiele] = useState<StorageZiel[]>([])
+  const [arbeitsDir, setArbeitsDir] = useState('')
+  const [standardArbeitsDir, setStandardArbeitsDir] = useState('')
 
   useEffect(() => {
     if (!isOpen) return
@@ -124,6 +140,10 @@ export default function RipTargetModal({ isOpen, initialType, discTitle, deviceI
     setTitelListe([])
     setGewaehlt(new Set())
     setEncoderNode('')
+    setArbeitsDir('')
+    api.get('/storage-targets')
+      .then(r => setArbeitsZiele(Array.isArray(r.data) ? r.data : []))
+      .catch(() => setArbeitsZiele([]))
     // Online-Worker für die Encoder-Wahl (nur relevant, wenn ≥2 verfügbar)
     api.get('/capabilities').then(r => {
       setWorkers((r.data.workers || []).filter((w: WorkerWahl) => w.online && w.node))
@@ -131,6 +151,7 @@ export default function RipTargetModal({ isOpen, initialType, discTitle, deviceI
     api.get('/settings').then(r => {
       const s = r.data || {}
       setNurHauptfilm(!!s.mainFeatureOnly)
+      setStandardArbeitsDir((s.workDir || '').trim())
       const basis = s.outputDir || '/app/media'
       setTargets([
         { id: '1', name: 'Filme', path: `${basis}/${s.movieDir || 'movies'}`, type: 'movies', isActive: true },
@@ -164,6 +185,7 @@ export default function RipTargetModal({ isOpen, initialType, discTitle, deviceI
       optionen.titles = [...gewaehlt].sort((a, b) => a - b)
     }
     if (encoderNode) optionen.transcodeNode = encoderNode
+    if (arbeitsDir) optionen.workDir = arbeitsDir
     const target = targets.find(t => t.type === selectedType)
     if (customPath) {
       onSave({ id: 'custom', name: 'Eigener Ordner', path: customPath, type: selectedType, isActive: true }, optionen)
@@ -245,6 +267,42 @@ export default function RipTargetModal({ isOpen, initialType, discTitle, deviceI
           </label>
         )}
 
+        {/*
+          Arbeitsverzeichnis für DIESEN Rip (Commander-Wunsch 25.07.2026).
+          Warum es hier steht: Der Roh-Rip einer 4K-UHD ist bis zu 100 GB groß
+          und lag bisher immer auf der Container-Platte — am 25.07. lief sie
+          damit voll (74 GB Rohschnitt auf 148 GB Platte). Die Wahl gehört zur
+          Disc, nicht in eine globale Einstellung. Leer = der Wert aus
+          Einstellungen → Verarbeitung; genau der greift auch bei
+          Vollautomatik-Rips, weil dort niemand gefragt wird.
+          Musik-Rips gehen direkt als FLAC ins Ziel, ohne Roh-Zwischenstufe.
+        */}
+        {selectedType !== 'music' && (
+          <div>
+            <Select
+              label="Arbeitsverzeichnis für die Rohdaten"
+              value={arbeitsDir}
+              onChange={e => setArbeitsDir(e.target.value)}
+            >
+              <option value="">
+                Standard aus den Einstellungen
+                {standardArbeitsDir ? ` (${standardArbeitsDir})` : ' (Container-Platte)'}
+              </option>
+              {arbeitsZiele.map(z => (
+                <option key={z.path} value={z.path}>
+                  {z.name}{z.is_mount ? ' (Netzwerk-Freigabe)' : ''}
+                  {z.free_gb != null ? ` — ${z.free_gb} GB frei` : ''}
+                </option>
+              ))}
+            </Select>
+            <p className="text-xs mt-1.5 text-slate-500 dark:text-slate-400 flex items-center gap-1.5">
+              <HardDrive size={13} />
+              Bei 4K-UHD bis zu 100 GB — nimm eine Freigabe mit Platz, am besten dieselbe wie das Ziel oben.
+              Dann muss Rippy am Ende nur umhängen statt zu kopieren.
+            </p>
+          </div>
+        )}
+
         {/* Encoder-/Worker-Wahl — nur wenn mehrere Worker online sind
             (sonst gibt es nichts zu wählen). Musik wird nicht komprimiert. */}
         {selectedType !== 'music' && workers.length >= 2 && (

docker/ui/src/components/WorkerVerwaltung.tsx

@@ -1,6 +1,7 @@
 import { useState, useEffect } from 'react'
 import { Server, RefreshCw, Copy, CheckCircle, Trash2, Download } from 'lucide-react'
 import { api } from '../lib/api'
+import { simdWarnung } from '../lib/encoder'
 import { useToast } from '../context/ToastContext'
 import { Card, CardHeader, CardTitle, CardContent } from './ui/Card'
 import { Button } from './ui/Button'
@@ -16,16 +17,22 @@ interface WorkerInfo {
     ip?: string
     makemkv?: string
     handbrake?: string
+    cpu_modell?: string
+    cpu_kerne?: string
+    cpu_simd?: string
+    handbrake_encoder?: string
   }
 }
 
 const ENCODER_LABELS: Record<string, string> = {
   'cpu-x264': 'CPU · H.264',
   'cpu-x265': 'CPU · H.265',
+  'cpu-av1': 'CPU · AV1 (SVT)',
   'vaapi': 'GPU · VAAPI (AMD/Intel)',
   'nvenc': 'GPU · NVENC (NVIDIA)',
 }
 
+
 function relativeZeit(iso?: string): string {
   if (!iso) return 'nie'
   const sekunden = Math.floor((Date.now() - new Date(iso).getTime()) / 1000)
@@ -134,6 +141,18 @@ export default function WorkerVerwaltung() {
                         {w.info?.ip ? ` · IP ${w.info.ip}` : ''}
                         {w.info?.hostname && w.info.hostname !== w.name ? ` · ID ${w.info.hostname}` : ''}
                       </p>
+                      {(w.info?.cpu_kerne || w.info?.cpu_simd) && (
+                        <p className="text-xs text-slate-500 dark:text-slate-400" title={w.info?.cpu_modell || ''}>
+                          {w.info?.cpu_kerne ? `${w.info.cpu_kerne} Kerne` : ''}
+                          {w.info?.cpu_kerne && w.info?.cpu_simd ? ' · ' : ''}
+                          {w.info?.cpu_simd ? `Vektorbefehle ${w.info.cpu_simd}` : ''}
+                        </p>
+                      )}
+                      {simdWarnung(w.info?.cpu_simd) && (
+                        <p className="mt-1 text-xs text-amber-600 dark:text-amber-400 max-w-xl">
+                          {simdWarnung(w.info?.cpu_simd)}
+                        </p>
+                      )}
                     </div>
                   </div>
                   <div className="flex items-center gap-2">

docker/ui/src/components/ui/Modal.tsx

@@ -1,4 +1,5 @@
 import { ReactNode, useEffect } from 'react'
+import { createPortal } from 'react-dom'
 import { X } from 'lucide-react'
 
 interface ModalProps {
@@ -35,7 +36,15 @@ export function Modal({ isOpen, onClose, title, children, maxWidth = 'lg' }: Mod
     '4xl': 'max-w-4xl',
   }
 
-  return (
+  // WICHTIG (Befund 25.07.2026): Der Dialog wird per Portal direkt an
+  // document.body gehängt statt dort zu bleiben, wo er im Baum steht.
+  // Grund: `.glass-panel` in index.css setzt `backdrop-filter: blur(16px)`,
+  // und ein Element mit backdrop-filter wird zum Bezugsrahmen für
+  // `position: fixed` seiner Nachfahren. Ein Modal INNERHALB einer Card war
+  // damit nicht mehr am Fenster ausgerichtet, sondern an der Card — es klebte
+  // im Panel und wurde am Rand abgeschnitten (gemeldet für „Rippen starten"
+  // im Laufwerke-Tab). Das Portal löst das für ALLE Dialoge auf einmal.
+  return createPortal(
     <div className="fixed inset-0 z-50 flex items-center justify-center p-4 overflow-y-auto">
       {/* Glass Backdrop */}
       <div
@@ -61,6 +70,7 @@ export function Modal({ isOpen, onClose, title, children, maxWidth = 'lg' }: Mod
           {children}
         </div>
       </div>
-    </div>
+    </div>,
+    document.body,
   )
 }

docker/ui/src/lib/design.ts

@@ -80,6 +80,7 @@ export const LOG_LEVEL_STYLES = {
 export const ENCODER_BADGES: Record<string, { label: string; highlight: boolean }> = {
   'cpu-x264': { label: 'H.264 (CPU)', highlight: false },
   'cpu-x265': { label: 'H.265 (CPU)', highlight: false },
+  'cpu-av1': { label: 'AV1 (CPU)', highlight: false },
   'vaapi': { label: 'VAAPI ⚡', highlight: true },
   'nvenc': { label: 'NVENC ⚡', highlight: true },
 }

docker/ui/src/lib/encoder.ts

@@ -0,0 +1,24 @@
+// Encoder-Fähigkeiten eines Workers in Klartext übersetzen.
+//
+// Befund 25.07.2026: Die Rippy-VM lief auf dem generischen QEMU-CPU-Modell
+// („QEMU Virtual CPU version 2.5+") und hatte deshalb kein AVX2, nur sse4_2.
+// x265 lebt von diesen Vektorbefehlen — ein 4K-Encode brauchte dort gemessene
+// 28-55 Stunden, und nirgends im UI war das zu sehen. Der Worker meldet die
+// Angaben seit dieser Runde selbst (worker/caps.py), hier werden sie gedeutet.
+
+// Stufen, mit denen Software-Encoding brauchbar schnell ist.
+export const SIMD_SCHNELL = ['avx512f', 'avx2']
+
+/**
+ * Warnt, wenn die CPU dieses Workers zu schwach für Software-Encoding ist.
+ * Gibt null zurück, wenn alles in Ordnung ist ODER die Stufe unbekannt ist —
+ * lieber nichts sagen als etwas Falsches behaupten.
+ */
+export function simdWarnung(simd?: string): string | null {
+  if (!simd || simd === 'unbekannt') return null
+  if (SIMD_SCHNELL.includes(simd)) return null
+  return `Diese CPU kann nur ${simd} (kein AVX2) — Software-Encoding ist hier `
+    + 'sehr langsam. Bei einer virtuellen Maschine hilft es meist, den '
+    + 'CPU-Typ auf "host" zu stellen; sonst besser einen Worker mit '
+    + 'Hardware-Encoder wählen.'
+}

docker/ui/src/pages/Anleitung.tsx

@@ -134,12 +134,15 @@ export default function AnleitungPage() {
           Einstellungen → System eintragen — gilt ab dem nächsten Rip, ohne Neustart. DVDs gehen
           immer auch ohne Key. Dort stehen auch die Werkzeug-Versionen und der freie Speicherplatz.
         </p>
+        {/* 25.07.2026 richtiggestellt: Updates bringen keine Disc-Schluessel mit — siehe UHD-Absatz unten. */}
         <p>
           <span className={fett}>Updates:</span> „Auf Updates prüfen" (ebenfalls Einstellungen →
           System) vergleicht die installierten Versionen mit makemkv.com und den offiziellen
           HandBrake-Releases. Gibt es ein MakeMKV-Update, zeigt Rippy den fertigen
-          Update-Befehl an — wichtig, weil neue Versionen auch die neueste
-          Disc-Schlüssel-Datenbank mitbringen.
+          Update-Befehl an — neue Versionen bringen bessere Laufwerks-Unterstützung und
+          Fehlerbehebungen. <span className={fett}>Disc-Schlüssel für 4K-UHD kommen dagegen nicht
+          aus einem Update</span> — die holt MakeMKV zur Laufzeit, und die Linux-Version tut das
+          nie. Wie du sie trotzdem bekommst, steht unter „Häufige Fragen".
         </p>
       </Abschnitt>
 
@@ -157,11 +160,35 @@ export default function AnleitungPage() {
           <span className={fett}>„Diese Disc wurde bereits gerippt"?</span> Rippy erkennt Discs am
           Fingerabdruck. Nochmal rippen geht trotzdem — der Hinweis verhindert nur Versehen.
         </p>
+        {/*
+          25.07.2026 auf BEIDEN Maschinen nachgemessen und erneut korrigiert. Es
+          stand hier nacheinander zweierlei Falsches: erst "ein MakeMKV-Update macht
+          die Disc rippbar", dann "MakeMKVs Schluessel-Kanal ist tot". Richtig ist:
+          makemkvcon unter Linux ruft die Schluessel nie ab, die Windows-Version
+          schon (Meldung 3338, Verbindung nach 185.84.108.20:443).
+        */}
         <p>
           <span className={fett}>4K-UHD schlägt fehl mit „volume key is unknown"?</span> Das Laufwerk
-          liest die Disc (LibreDrive), aber MakeMKV kennt den Schlüssel dieser (zu neuen) Pressung
-          noch nicht. Den automatisch gespeicherten AACS-Dump im MakeMKV-Forum einreichen — mit einem
-          der nächsten Updates ist die Disc rippbar.
+          liest die Disc einwandfrei (LibreDrive) — MakeMKV fehlt nur der Schlüssel dieser Pressung.
+          Der Grund liegt nicht bei dir und nicht bei Rippy: <span className={fett}>die Linux-Version
+          von MakeMKV holt Disc-Schlüssel nie selbst aus dem Netz</span>. Die Windows-Version tut es.
+          Ein MakeMKV-Update ändert daran nichts.
+        </p>
+        <p>
+          <span className={fett}>Der Weg drumherum:</span> MakeMKV einmalig auf einem Windows-PC
+          installieren (gleicher Beta-Key), das Laufwerk dort anstecken, die Disc öffnen — MakeMKV
+          lädt die Schlüssel dabei nach. Dann in MakeMKV unter <em>Preferences → General</em> das
+          „MakeMKV data directory" nachschlagen und die Datei <code>_private_data.tar</code> daraus
+          bei Rippy unter Einstellungen → System hochladen. Wirkt ab dem nächsten Rip. Für neue
+          Discs gelegentlich wiederholen — der Block dort zeigt dir, wie viele Schlüssel Rippy kennt.
+        </p>
+        <p>
+          Geht eine Pressung auch damit nicht auf, kennt MakeMKV sie selbst nicht. Dann bleiben zwei
+          Dinge: eine <code>KEYDB.cfg</code> (ebenfalls dort hochladbar, der Notnagel), oder den
+          <span className={fett}> AACS-Dump</span> im MakeMKV-Forum im Bereich „Ultra HD Blu-ray"
+          einreichen — der bleibt jetzt erhalten und steht unter Einstellungen → System zum
+          Herunterladen. <span className={fett}>Rippy liefert keine Schlüssel mit und lädt keine
+          herunter</span> — es verwaltet nur, was du selbst mitbringst.
         </p>
         <p>
           <span className={fett}>„Neu komprimieren" fehlt bei einem Fehl-Job?</span> Der Knopf

docker/ui/src/pages/Settings.tsx

@@ -1,5 +1,5 @@
-import { useState, useEffect } from 'react'
-import { Save, Disc, Cpu, Database, Globe, AlertCircle, CheckCircle, HardDrive, Wrench, Send, Tv } from 'lucide-react'
+import { useState, useEffect, useRef } from 'react'
+import { Save, Disc, Cpu, Database, Globe, AlertCircle, CheckCircle, HardDrive, Wrench, Send, Tv, KeyRound, Upload, Trash2, Download } from 'lucide-react'
 import { api } from '../lib/api'
 import { useToast } from '../context/ToastContext'
 import StorageMounts from '../components/StorageMounts'
@@ -10,6 +10,7 @@ import { Button } from '../components/ui/Button'
 import { Input, Select, Toggle } from '../components/ui/Input'
 import { MEDIA_SERVER_OPTIONEN } from '../lib/mediaServer'
 import { ENCODER_BADGES } from '../lib/design'
+import { simdWarnung } from '../lib/encoder'
 
 interface SettingsState {
   tmdbApiKey: string
@@ -19,13 +20,18 @@ interface SettingsState {
   movieDir: string
   seriesDir: string
   musicDir: string
-  ripAllTracks: boolean
   mainFeatureOnly: boolean
   autoEject: boolean
   autoRipStart: boolean
   notificationWebhook: string
   transcodeEnabled: boolean
+  // transcodePreset bleibt als Rückfall für Bestandsinstallationen bestehen —
+  // solange die drei Felder darunter nicht gespeichert sind, gilt weiter dieser
+  // Wert (siehe preset_fuer() in docker/worker/ripping.py).
   transcodePreset: string
+  transcodePresetDvd: string
+  transcodePresetBluray: string
+  transcodePresetUhd: string
   keepOriginal: boolean
   mediaServer: string
   jellyfinUrl: string
@@ -42,13 +48,15 @@ const defaultSettings: SettingsState = {
   movieDir: 'movies',
   seriesDir: 'series',
   musicDir: 'music',
-  ripAllTracks: true,
   mainFeatureOnly: false,
   autoEject: true,
   autoRipStart: false,
   notificationWebhook: '',
   transcodeEnabled: true,
   transcodePreset: 'H.265 MKV 1080p30',
+  transcodePresetDvd: 'H.265 MKV 576p25',
+  transcodePresetBluray: 'H.265 MKV 1080p30',
+  transcodePresetUhd: 'H.265 MKV 2160p60 4K',
   keepOriginal: false,
   mediaServer: 'none',
   jellyfinUrl: '',
@@ -62,7 +70,51 @@ type SettingsTab = 'ripping' | 'verarbeitung' | 'worker' | 'speicherziele' | 'ap
 interface WorkerInfo {
   name: string
   encoders: string[]
-  info?: { makemkv?: string, handbrake?: string, makemkv_key?: string }
+  // keydb: "ja" | "nein" | "unbekannt" — sagt, ob DIESER Worker eine KEYDB.cfg
+  // in seinem MakeMKV-Datenverzeichnis sieht. Nur der Worker, der wirklich
+  // rippt, zaehlt, deshalb steht die Angabe pro Worker und nicht global.
+  // cpu_kerne/cpu_simd: Rechenleistung fuers Software-Encodieren. Ohne diese
+  // Angaben war am 25.07.2026 nicht zu sehen, dass ein 4K-Encode auf der
+  // Rippy-VM Tage statt Stunden braucht (kein AVX2, 4 Kerne).
+  // handbrake_encoder: die ungefilterte Encoder-Auskunft von HandBrake selbst.
+  info?: {
+    makemkv?: string, handbrake?: string, makemkv_key?: string, keydb?: string,
+    cpu_modell?: string, cpu_kerne?: string, cpu_simd?: string,
+    handbrake_encoder?: string,
+  }
+}
+
+// Antwort von GET/POST/DELETE /system/keydb (Feldnamen exakt wie die API sie liefert).
+interface KeydbStatus {
+  vorhanden: boolean
+  pfad: string
+  groesse_bytes: number
+  eintraege: number
+  geaendert: string
+}
+
+// Ein Ablageziel aus GET /storage-targets (Feldnamen exakt wie die API liefert).
+interface StorageZiel {
+  name: string
+  path: string
+  is_mount: boolean
+  free_gb: number | null
+}
+
+// Antwort von GET/POST /system/keystore — MakeMKVs eigener Schluesselvorrat.
+interface KeystoreStatus {
+  vorhanden: boolean
+  pfad: string
+  groesse_bytes: number
+  schluessel: number
+  geaendert: string
+}
+
+// Ein AACS-Dump aus GET /system/aacs-dumps.
+interface AacsDump {
+  name: string
+  groesse_bytes: number
+  geaendert: string
 }
 
 interface SystemInfo {
@@ -73,6 +125,24 @@ interface SystemInfo {
   webhook_gesetzt: boolean
 }
 
+// Byte-Zahl menschenlesbar — eine echte KEYDB.cfg ist mehrere MB gross.
+function bytesLesbar(bytes: number): string {
+  if (!bytes) return '0 B'
+  if (bytes >= 1024 * 1024) return `${(bytes / (1024 * 1024)).toFixed(1)} MB`
+  if (bytes >= 1024) return `${Math.round(bytes / 1024)} KB`
+  return `${bytes} B`
+}
+
+// Die API liefert ISO-8601 in UTC (oder einen leeren String). Ohne Zonen-Kennung
+// wuerde der Browser den Zeitstempel als Ortszeit lesen und die Uhrzeit um den
+// Zonen-Versatz verschieben — deshalb notfalls ein Z anhaengen.
+function zeitLesbar(iso: string): string {
+  if (!iso) return 'unbekannt'
+  const mitZone = /[Zz]$|[+-]\d{2}:?\d{2}$/.test(iso) ? iso : `${iso}Z`
+  const d = new Date(mitZone)
+  return isNaN(d.getTime()) ? 'unbekannt' : d.toLocaleString('de-DE')
+}
+
 export default function SettingsPage() {
   const [settings, setSettings] = useState<SettingsState>(defaultSettings)
   const [activeTab, setActiveTab] = useState<SettingsTab>('ripping')
@@ -86,6 +156,19 @@ export default function SettingsPage() {
   const [quellenBusy, setQuellenBusy] = useState(false)
   const [updates, setUpdates] = useState<Record<string, { installiert?: string, verfuegbar?: string, update?: boolean }> | null>(null)
   const [updatesBusy, setUpdatesBusy] = useState(false)
+  // KEYDB.cfg und AACS-Dumps sind DATEIEN im MakeMKV-Datenverzeichnis, keine
+  // Einstellungen — deshalb bewusst NICHT in SettingsState: der globale
+  // Speichern-Knopf postet dieses Objekt komplett und wuerde sie mitschleifen.
+  const [keydb, setKeydb] = useState<KeydbStatus | null>(null)
+  const [keydbBusy, setKeydbBusy] = useState(false)
+  const [dumps, setDumps] = useState<AacsDump[]>([])
+  const keydbInput = useRef<HTMLInputElement>(null)
+  // Ablageziele unter /app/media inkl. eingehängter Freigaben — speist die
+  // Auswahl des Arbeitsverzeichnisses (vorher musste man den Pfad tippen).
+  const [ziele, setZiele] = useState<StorageZiel[]>([])
+  const [keystore, setKeystore] = useState<KeystoreStatus | null>(null)
+  const [keystoreBusy, setKeystoreBusy] = useState(false)
+  const keystoreInput = useRef<HTMLInputElement>(null)
 
   const { toast } = useToast()
 
@@ -106,6 +189,69 @@ export default function SettingsPage() {
     }
   }
 
+  // Status der KEYDB.cfg + Liste der AACS-Dumps frisch holen. Wird beim Laden
+  // der Seite und nach jeder Aktion aufgerufen — die API ist die Wahrheit,
+  // nicht das, was wir gerade hochgeschickt haben.
+  const keydbLaden = () => {
+    api.get('/system/keydb').then(r => setKeydb(r.data)).catch(() => setKeydb(null))
+    api.get('/system/keystore').then(r => setKeystore(r.data)).catch(() => setKeystore(null))
+    api.get('/system/aacs-dumps').then(r => setDumps(r.data?.dumps || [])).catch(() => setDumps([]))
+    // Die Worker-Plaketten oben kommen aus /capabilities und stammen aus dem
+    // letzten Herzschlag des Workers (minuetlich) — ohne dieses Nachladen
+    // widerspraeche die Kachel nach einem Upload sichtbar der Erfolgsmeldung.
+    // Ganz sofort ist sie trotzdem nicht: der Worker meldet erst beim
+    // naechsten Herzschlag neu. Genau so steht es auch im Erklaertext.
+    api.get('/capabilities').then(r => setWorkers(r.data.workers || [])).catch(() => setWorkers([]))
+  }
+
+  const keydbHochladen = async (datei: File) => {
+    setKeydbBusy(true)
+    try {
+      // Bewusst als JSON-Text und nicht als Multipart-Upload: der API fehlt
+      // python-multipart, ein File()-Endpunkt wuerde sie beim Import killen.
+      const inhalt = await datei.text()
+      await api.post('/system/keydb', { inhalt })
+      keydbLaden()
+      toast('success', 'KEYDB.cfg gespeichert — sie wirkt ab dem nächsten Rip.')
+    } catch (e: any) {
+      toast('error', e?.response?.data?.detail || 'Hochladen fehlgeschlagen — ist das wirklich eine KEYDB.cfg, und läuft die API?')
+    } finally {
+      setKeydbBusy(false)
+    }
+  }
+
+  const keystoreHochladen = async (datei: File) => {
+    setKeystoreBusy(true)
+    try {
+      // Die Datei wandert als roher Anfrage-Körper zur API — _private_data.tar
+      // ist binär, JSON oder Base64 wäre nur unnötiger Ballast, und Multipart
+      // kann die API nicht (kein python-multipart).
+      await api.post('/system/keystore', datei, {
+        headers: { 'Content-Type': 'application/octet-stream' },
+      })
+      keydbLaden()
+      toast('success', 'Schlüsselspeicher übernommen — wirkt ab dem nächsten Rip.')
+    } catch (e: any) {
+      toast('error', e?.response?.data?.detail
+        || 'Übernahme fehlgeschlagen — ist das wirklich die Datei _private_data.tar, und läuft die API?')
+    } finally {
+      setKeystoreBusy(false)
+    }
+  }
+
+  const keydbEntfernen = async () => {
+    setKeydbBusy(true)
+    try {
+      await api.delete('/system/keydb')
+      keydbLaden()
+      toast('success', 'KEYDB.cfg entfernt — Rippy nutzt jetzt keine Schlüsseldatei mehr.')
+    } catch (e: any) {
+      toast('error', e?.response?.data?.detail || 'Entfernen fehlgeschlagen — läuft die API?')
+    } finally {
+      setKeydbBusy(false)
+    }
+  }
+
   const quellenPruefen = async () => {
     setQuellenBusy(true)
     try {
@@ -131,6 +277,18 @@ export default function SettingsPage() {
     api.get('/system/info')
       .then(r => setSystemInfo(r.data))
       .catch(() => setSystemInfo(null))
+    api.get('/system/keydb')
+      .then(r => setKeydb(r.data))
+      .catch(() => setKeydb(null))
+    api.get('/system/keystore')
+      .then(r => setKeystore(r.data))
+      .catch(() => setKeystore(null))
+    api.get('/storage-targets')
+      .then(r => setZiele(Array.isArray(r.data) ? r.data : []))
+      .catch(() => setZiele([]))
+    api.get('/system/aacs-dumps')
+      .then(r => setDumps(r.data?.dumps || []))
+      .catch(() => setDumps([]))
   }, [])
 
   const webhookTesten = async () => {
@@ -276,14 +434,16 @@ export default function SettingsPage() {
                   🎵 Audio-CD
                 </p>
 
-                <div className="p-4 rounded-xl border border-slate-200/80 dark:border-slate-800 bg-slate-50/50 dark:bg-slate-950/80">
-                  <Toggle
-                    label="Alle Tracks rippen"
-                    description="Rippe alle Tracks einer CD (FLAC + MusicBrainz-Tags)."
-                    checked={settings.ripAllTracks}
-                    onChange={(v) => handleChange('ripAllTracks', v)}
-                  />
-                </div>
+                {/* Der Schalter „Alle Tracks rippen" ist am 25.07.2026 entfallen.
+                    Er war ein Placebo: abcde bekommt keine Track-Auswahl (siehe
+                    build_abcde_cmd) und es gibt auch keine Oberflaeche, um eine
+                    Teilmenge zu waehlen — eine Audio-CD wurde also immer
+                    vollstaendig gerippt, egal wie der Schalter stand. Statt einer
+                    Wahl, die nichts bewirkt, steht hier jetzt die Wahrheit. */}
+                <p className="text-xs text-slate-500 dark:text-slate-400 px-1">
+                  💿 Eine Audio-CD wird immer vollständig gerippt — alle Tracks als
+                  FLAC, mit MusicBrainz-Tags.
+                </p>
 
                 <p className="text-xs font-bold uppercase tracking-wider pt-2 text-slate-400 dark:text-slate-500">
                   Allgemein
@@ -404,6 +564,24 @@ export default function SettingsPage() {
                           {ENCODER_BADGES[e]?.label || e}
                         </span>
                       ))}
+                      {(w.info?.cpu_kerne || w.info?.cpu_simd) && (
+                        <p className="mt-1 text-xs text-slate-500 dark:text-slate-400" title={w.info?.cpu_modell || ''}>
+                          {w.info?.cpu_modell ? `${w.info.cpu_modell} · ` : ''}
+                          {w.info?.cpu_kerne ? `${w.info.cpu_kerne} Kerne` : ''}
+                          {w.info?.cpu_kerne && w.info?.cpu_simd ? ' · ' : ''}
+                          {w.info?.cpu_simd ? `Vektorbefehle ${w.info.cpu_simd}` : ''}
+                        </p>
+                      )}
+                      {simdWarnung(w.info?.cpu_simd) && (
+                        <p className="mt-1 text-xs text-amber-600 dark:text-amber-400">
+                          {simdWarnung(w.info?.cpu_simd)}
+                        </p>
+                      )}
+                      {w.info?.handbrake_encoder && (
+                        <p className="mt-1 text-xs text-slate-400 dark:text-slate-500 font-mono break-all">
+                          HandBrake meldet: {w.info.handbrake_encoder}
+                        </p>
+                      )}
                     </div>
                   ))
                 )}
@@ -419,16 +597,53 @@ export default function SettingsPage() {
                   />
                 </div>
 
-                <Select
-                  label="HandBrake-Preset"
-                  value={settings.transcodePreset}
-                  onChange={(e) => handleChange('transcodePreset', e.target.value)}
-                >
-                  <option value="H.265 MKV 1080p30">H.265 MKV 1080p30 — klein &amp; modern (Standard)</option>
-                  <option value="H.265 MKV 2160p60 4K">H.265 MKV 2160p60 4K — für UHD-Quellen</option>
-                  <option value="HQ 1080p30 Surround">HQ 1080p30 Surround — H.264, maximale Kompatibilität</option>
-                  <option value="Super HQ 1080p30 Surround">Super HQ 1080p30 Surround — größer, beste Qualität</option>
-                </Select>
+                {/*
+                  Ein Preset JE DISC-TYP (25.07.2026). Vorher lief alles durch
+                  dasselbe Preset — eine 4K-UHD wurde damit auf 1080p
+                  heruntergerechnet und eine DVD auf 1080p hochskaliert.
+                  Preset-Namen stammen aus `HandBrakeCLI --preset-list` im
+                  Worker-Image (HandBrake 1.6.1), nicht aus dem Kopf.
+                */}
+                <div className="space-y-3">
+                  <p className="text-xs text-slate-500 dark:text-slate-400">
+                    Ein Preset je Quelle — Rippy erkennt den Disc-Typ selbst und wählt passend aus.
+                    <strong className="text-slate-700 dark:text-slate-300"> Eine 4K-UHD gehört auf ein
+                    2160p-Preset</strong>, sonst rechnet HandBrake sie auf 1080p herunter und die
+                    4K-Auflösung ist weg.
+                  </p>
+
+                  <Select
+                    label="Preset für 4K-UHD"
+                    value={settings.transcodePresetUhd}
+                    onChange={(e) => handleChange('transcodePresetUhd', e.target.value)}
+                  >
+                    <option value="H.265 MKV 2160p60 4K">H.265 MKV 2160p60 4K — 4K erhalten (empfohlen)</option>
+                    <option value="HQ 2160p60 4K HEVC Surround">HQ 2160p60 4K HEVC Surround — 4K, mehr Qualität</option>
+                    <option value="Super HQ 2160p60 4K HEVC Surround">Super HQ 2160p60 4K HEVC Surround — 4K, größer</option>
+                    <option value="H.265 MKV 1080p30">H.265 MKV 1080p30 — bewusst auf 1080p verkleinern</option>
+                  </Select>
+
+                  <Select
+                    label="Preset für Blu-ray"
+                    value={settings.transcodePresetBluray}
+                    onChange={(e) => handleChange('transcodePresetBluray', e.target.value)}
+                  >
+                    <option value="H.265 MKV 1080p30">H.265 MKV 1080p30 — klein &amp; modern (empfohlen)</option>
+                    <option value="HQ 1080p30 Surround">HQ 1080p30 Surround — H.264, maximale Kompatibilität</option>
+                    <option value="Super HQ 1080p30 Surround">Super HQ 1080p30 Surround — größer, beste Qualität</option>
+                  </Select>
+
+                  <Select
+                    label="Preset für DVD"
+                    value={settings.transcodePresetDvd}
+                    onChange={(e) => handleChange('transcodePresetDvd', e.target.value)}
+                  >
+                    <option value="H.265 MKV 576p25">H.265 MKV 576p25 — PAL-DVD, native Auflösung (empfohlen)</option>
+                    <option value="H.265 MKV 480p30">H.265 MKV 480p30 — NTSC-DVD, native Auflösung</option>
+                    <option value="HQ 576p25 Surround">HQ 576p25 Surround — H.264, maximale Kompatibilität</option>
+                    <option value="H.265 MKV 1080p30">H.265 MKV 1080p30 — hochskalieren (bringt nichts)</option>
+                  </Select>
+                </div>
 
                 <div className="p-4 rounded-xl border border-slate-200/80 dark:border-slate-800 bg-slate-50/50 dark:bg-slate-950/80">
                   <Toggle
@@ -439,14 +654,35 @@ export default function SettingsPage() {
                   />
                 </div>
 
-                <Input
-                  label="Arbeitsverzeichnis für Roh-Rips (optional)"
+                {/*
+                  Auswahl statt Eintippen (Befund 25.07.2026): Das Feld war ein
+                  freies Textfeld — man musste den Container-Pfad KENNEN
+                  (/app/media/…), um eine Netzwerk-Freigabe zu treffen. Genau
+                  daran ist es gescheitert, und der 74-GB-Rohschnitt landete auf
+                  der VM-Platte, bis sie voll war. Die Ziele kommen aus
+                  /storage-targets — dieselbe Liste wie bei den Speicherzielen,
+                  inklusive freiem Platz.
+                */}
+                <Select
+                  label="Arbeitsverzeichnis für Roh-Rips (Standard)"
                   value={settings.workDir}
                   onChange={(e) => handleChange('workDir', e.target.value)}
-                  placeholder="leer = /app/temp (Container-Platte)"
-                />
+                >
+                  <option value="">Container-Platte (Standard) — klein, nur für DVD/Blu-ray</option>
+                  {ziele.map(z => (
+                    <option key={z.path} value={z.path}>
+                      {z.name}{z.is_mount ? ' (Netzwerk-Freigabe)' : ''}
+                      {z.free_gb != null ? ` — ${z.free_gb} GB frei` : ''}
+                    </option>
+                  ))}
+                </Select>
                 <p className="text-xs text-slate-500 dark:text-slate-400">
-                  Wichtig für 4K-UHD: Rohdaten sind bis 100 GB groß.
+                  <strong className="text-slate-700 dark:text-slate-300">Der Standard</strong> — beim
+                  „Rippen starten" kannst du für jede Disc etwas anderes wählen. <strong className="text-slate-700 dark:text-slate-300">
+                  Läuft die Vollautomatik</strong>, fragt dich niemand: dann gilt genau dieser Wert.
+                  Wichtig für 4K-UHD: Rohdaten sind bis 100 GB groß und passen selten auf die
+                  Container-Platte. Am besten dieselbe Freigabe wie das Ziel — dann muss Rippy die
+                  Rohdatei am Ende nur umhängen statt sie zu kopieren.
                   {systemInfo?.plaetze?.length ? (
                     <> Aktuell frei: {systemInfo.plaetze.map(p => `${p.name}: ${p.frei_gb} GB`).join(' · ')}</>
                   ) : null}
@@ -633,13 +869,42 @@ export default function SettingsPage() {
                           HandBrake {w.info.handbrake}
                         </span>
                       )}
+                      {/*
+                        Nur das Verzeichnis des rippenden Workers zaehlt — deshalb je Worker.
+                        Die Zahl der Disc-Schluessel ist die entscheidende Angabe fuer 4K-UHD:
+                        0 heisst, dass JEDE unbekannte UHD-Disc scheitert.
+                      */}
+                      {w.info?.schluessel && w.info.schluessel !== '0' && w.info.schluessel !== 'unbekannt' && (
+                        <span className="text-xs px-2.5 py-0.5 rounded-md font-medium bg-emerald-500/15 text-emerald-600 dark:text-emerald-400 border border-emerald-500/30">
+                          {w.info.schluessel} Disc-Schlüssel
+                        </span>
+                      )}
+                      {w.info?.schluessel === '0' && (
+                        <span className="text-xs px-2.5 py-0.5 rounded-md font-medium bg-amber-500/15 text-amber-600 dark:text-amber-400 border border-amber-500/30">
+                          keine Disc-Schlüssel — 4K-UHD scheitert
+                        </span>
+                      )}
+                      {w.info?.keydb === 'ja' && (
+                        <span className="text-xs px-2.5 py-0.5 rounded-md font-medium bg-slate-200 dark:bg-slate-800 text-slate-500 dark:text-slate-400 border border-slate-300 dark:border-slate-700">
+                          + KEYDB.cfg
+                        </span>
+                      )}
                     </div>
                   ))
                 )}
+                {/*
+                  Bis 25.07.2026 stand hier, MakeMKV-Updates braechten die neueste
+                  Disc-Schluessel-Datenbank mit. Nachgemessen: falsch — MakeMKV liefert
+                  gar keine Schluessel mit, es holt sie zur Laufzeit. Und die
+                  Linux-Version holt sie nie (kein einziger Verbindungsversuch, auf
+                  beiden Maschinen verglichen). Deshalb der Schluesselspeicher unten.
+                */}
                 <p className="text-xs mt-3 pt-3 border-t border-slate-200/60 dark:border-slate-800 text-slate-500 dark:text-slate-400">
                   <strong className="text-slate-700 dark:text-slate-300">MakeMKV</strong> lässt sich aktuell halten
-                  (Update-Check unten; Version über <code>MAKEMKV_VERSION</code> + Rebuild) — wichtig wegen der
-                  Disc-Schlüssel-Datenbank.
+                  (Update-Check unten; Version über <code>MAKEMKV_VERSION</code> + Rebuild) — neue Versionen bringen
+                  vor allem Laufwerks-Unterstützung und Fehlerbehebungen. <strong>Disc-Schlüssel für 4K-UHD kommen
+                  NICHT aus einem Update</strong> — die holt MakeMKV zur Laufzeit, und die Linux-Version tut das
+                  nie. Deshalb der Block „Disc-Schlüssel für 4K-UHD" weiter unten.
                   {' '}<strong className="text-slate-700 dark:text-slate-300">HandBrake</strong> im eingebauten
                   Docker-Worker ist bewusst die stabile <strong>Debian-Version</strong> — für die Kompression völlig
                   ausreichend und wird <strong>nicht separat aktualisiert</strong>. Native Worker (Windows) holen
@@ -655,6 +920,213 @@ export default function SettingsPage() {
                 placeholder="T-… (Forum-Thread „MakeMKV is free while in beta”)"
               />
 
+              {/*
+                Schluesselspeicher — der Hauptweg fuer 4K-UHD (Befund 25.07.2026,
+                auf beiden Maschinen gemessen): makemkvcon holt Disc-Schluessel
+                unter Linux NIE selbst, die Windows-Version tut es (Meldung 3338,
+                Verbindung nach 185.84.108.20:443). Deshalb wird der Vorrat hier
+                von Hand hereingereicht. Frueher stand an dieser Stelle die These,
+                MakeMKVs Schluessel-Kanal sei abgeschaltet — das war falsch.
+              */}
+              <div className="p-4 rounded-xl border border-slate-200/80 dark:border-slate-800 bg-slate-50/50 dark:bg-slate-950/80 space-y-3">
+                <div className="flex items-center justify-between">
+                  <p className="text-sm font-semibold text-slate-900 dark:text-slate-200 flex items-center gap-2">
+                    <Database size={16} className="text-amber-500" />
+                    Disc-Schlüssel für 4K-UHD
+                  </p>
+                  <div className="flex items-center gap-2">
+                    <input
+                      type="file"
+                      className="hidden"
+                      ref={keystoreInput}
+                      accept=".tar"
+                      onChange={(e) => {
+                        const datei = e.target.files?.[0]
+                        e.target.value = ''
+                        if (datei) keystoreHochladen(datei)
+                      }}
+                    />
+                    <Button
+                      variant="amber"
+                      size="sm"
+                      onClick={() => keystoreInput.current?.click()}
+                      disabled={keystoreBusy}
+                    >
+                      <Upload size={14} />
+                      {keystoreBusy ? 'Übernehme…' : '_private_data.tar übernehmen'}
+                    </Button>
+                  </div>
+                </div>
+
+                {keystore?.vorhanden && keystore.schluessel > 0 ? (
+                  <div className="p-3 rounded-lg text-sm bg-emerald-500/15 text-emerald-600 dark:text-emerald-400 border border-emerald-500/30">
+                    <p className="font-semibold">{keystore.schluessel} Disc-Schlüssel vorhanden.</p>
+                    <p className="text-xs mt-1">
+                      {bytesLesbar(keystore.groesse_bytes)} · zuletzt geändert {zeitLesbar(keystore.geaendert)}
+                    </p>
+                  </div>
+                ) : (
+                  <div className="p-3 rounded-lg text-sm bg-amber-500/15 text-amber-600 dark:text-amber-400 border border-amber-500/30">
+                    <p className="font-semibold">Kein einziger Disc-Schlüssel vorhanden.</p>
+                    <p className="text-xs mt-1">
+                      DVDs und normale Blu-rays laufen trotzdem. 4K-UHD-Discs scheitern dagegen mit
+                      „The volume key is unknown for this disc" — solange hier nichts liegt, jede einzelne.
+                    </p>
+                  </div>
+                )}
+
+                <p className="text-xs text-slate-500 dark:text-slate-400">
+                  <strong className="text-slate-700 dark:text-slate-300">Warum das nötig ist:</strong> MakeMKV
+                  holt sich diese Schlüssel eigentlich selbst aus dem Netz. Die <strong>Linux-Version tut das
+                  nicht</strong> — am 25.07.2026 nachgemessen: sie baut dabei nicht eine einzige Verbindung auf.
+                  Die Windows-Version schon. Ein MakeMKV-Update ändert daran nichts, es ist kein Fehler in Rippy.
+                </p>
+                <p className="text-xs text-slate-500 dark:text-slate-400">
+                  <strong className="text-slate-700 dark:text-slate-300">So füllst du den Vorrat:</strong> MakeMKV
+                  auf einem Windows-PC installieren (gleicher Beta-Key), das Laufwerk dort anstecken und die Disc
+                  einmal öffnen. MakeMKV lädt die Schlüssel dabei nach. Danach unter <em>Preferences → General</em>
+                  das „MakeMKV data directory" nachschlagen, die Datei <code>_private_data.tar</code> daraus hier
+                  hochladen — fertig. Für neue Discs von Zeit zu Zeit wiederholen.
+                </p>
+                <p className="text-xs text-slate-500 dark:text-slate-400">
+                  Das ist der Zwischenspeicher <strong className="text-slate-700 dark:text-slate-300">deiner
+                  eigenen</strong> MakeMKV-Installation, über MakeMKVs offiziellen Weg mit deiner eigenen Lizenz
+                  geholt. Rippy liefert keine Schlüssel mit und lädt keine herunter.
+                </p>
+              </div>
+
+              {/*
+                KEYDB.cfg — der NOTNAGEL, nicht der Hauptweg. Sie hilft bei Pressungen,
+                die auch MakeMKV selbst nicht kennt. Der Regelfall laeuft ueber den
+                Schluesselspeicher im Block darueber. Dateiname GROSS geschrieben, unter
+                Linux case-sensitiv. Rippy stellt nur den Platz bereit.
+              */}
+              <div className="p-4 rounded-xl border border-slate-200/80 dark:border-slate-800 bg-slate-50/50 dark:bg-slate-950/80 space-y-3">
+                <div className="flex items-center justify-between">
+                  <p className="text-sm font-semibold text-slate-900 dark:text-slate-200 flex items-center gap-2">
+                    <KeyRound size={16} className="text-amber-500" />
+                    KEYDB.cfg (Notnagel)
+                  </p>
+                  <div className="flex items-center gap-2">
+                    {/*
+                      Versteckter Datei-Dialog: der Inhalt wird im Browser gelesen und als
+                      JSON gepostet. Kein Multipart — der API fehlt python-multipart.
+                    */}
+                    <input
+                      type="file"
+                      className="hidden"
+                      ref={keydbInput}
+                      accept=".cfg,text/plain"
+                      onChange={(e) => {
+                        const datei = e.target.files?.[0]
+                        // Wert leeren, damit dieselbe Datei erneut gewählt werden kann.
+                        e.target.value = ''
+                        if (datei) keydbHochladen(datei)
+                      }}
+                    />
+                    <Button
+                      variant="amber"
+                      size="sm"
+                      onClick={() => keydbInput.current?.click()}
+                      disabled={keydbBusy}
+                    >
+                      <Upload size={14} />
+                      {keydbBusy ? 'Arbeite…' : 'KEYDB.cfg hochladen'}
+                    </Button>
+                    {keydb?.vorhanden && (
+                      <Button variant="danger" size="sm" onClick={keydbEntfernen} disabled={keydbBusy}>
+                        <Trash2 size={14} />
+                        Entfernen
+                      </Button>
+                    )}
+                  </div>
+                </div>
+
+                {keydb?.vorhanden ? (
+                  <div className="p-3 rounded-lg text-sm bg-emerald-500/15 text-emerald-600 dark:text-emerald-400 border border-emerald-500/30">
+                    <p className="font-semibold">Eine KEYDB.cfg liegt bereit.</p>
+                    <p className="text-xs mt-1">
+                      {bytesLesbar(keydb.groesse_bytes)} · {keydb.eintraege} Zeilen mit Disc-Kennung ·
+                      zuletzt geändert {zeitLesbar(keydb.geaendert)}
+                    </p>
+                    <p className="text-xs mt-1 font-mono opacity-80">{keydb.pfad}</p>
+                  </div>
+                ) : (
+                  <div className="p-3 rounded-lg text-sm bg-slate-200 dark:bg-slate-800 text-slate-500 dark:text-slate-400 border border-slate-300 dark:border-slate-700">
+                    <p className="font-semibold">Keine KEYDB.cfg hinterlegt.</p>
+                    <p className="text-xs mt-1">
+                      Das ist normal und meistens auch nicht nötig — der Regelfall läuft über den
+                      Schlüsselspeicher oben.
+                    </p>
+                  </div>
+                )}
+
+                <p className="text-xs text-slate-500 dark:text-slate-400">
+                  Die <strong className="text-slate-700 dark:text-slate-300">KEYDB.cfg</strong> ist eine reine
+                  Textdatei mit Disc-Schlüsseln. Sie ist der <strong className="text-slate-700 dark:text-slate-300">
+                  Notnagel</strong> für den Fall, dass eine Pressung selbst über den Schlüsselspeicher nicht
+                  aufgeht — also auch MakeMKV sie nicht kennt. Zuerst immer den Weg darüber versuchen.
+                </p>
+                <p className="text-xs text-slate-500 dark:text-slate-400">
+                  <strong className="text-slate-700 dark:text-slate-300">Wichtig:</strong> Rippy liefert keine
+                  Schlüssel mit, lädt keine herunter und verteilt keine. Rippy stellt nur den Platz für eine Datei
+                  bereit, die du selbst mitbringst, und zeigt dir ehrlich an, was dort liegt. Die Zahl oben ist
+                  genau das: die gezählten Zeilen mit einer Disc-Kennung in deiner Datei — keine von MakeMKV
+                  bestätigte Anzahl brauchbarer Schlüssel.
+                </p>
+                <p className="text-xs text-slate-500 dark:text-slate-400">
+                  Eine hochgeladene Datei ersetzt die bisherige und wirkt
+                  <strong className="text-slate-700 dark:text-slate-300"> ab dem nächsten Rip</strong> — laufende
+                  Jobs bleiben unberührt, ein Neustart ist nicht nötig. Die Plakette am Worker weiter oben
+                  folgt erst mit dessen nächstem Herzschlag (etwa eine Minute) — dieser Kasten hier ist sofort
+                  aktuell.
+                </p>
+              </div>
+
+              {/*
+                AACS-Dumps: MakeMKV legt sie bei einer unbekannten UHD-Disc ab (Meldung 3332).
+                Seit das Datenverzeichnis persistent gemountet ist, ueberleben sie den
+                Container-Neustart — vorher waren sie nach jedem Rip weg.
+              */}
+              <div className="p-4 rounded-xl border border-slate-200/80 dark:border-slate-800 bg-slate-50/50 dark:bg-slate-950/80 space-y-3">
+                <div className="flex items-center justify-between">
+                  <p className="text-sm font-semibold text-slate-900 dark:text-slate-200">AACS-Dumps</p>
+                  <Button variant="secondary" size="sm" onClick={keydbLaden}>
+                    Liste aktualisieren
+                  </Button>
+                </div>
+                {dumps.length === 0 ? (
+                  <p className="text-xs text-slate-500 dark:text-slate-400">
+                    Noch kein Dump vorhanden. MakeMKV legt hier automatisch einen ab, sobald eine 4K-UHD-Disc
+                    an einem unbekannten Schlüssel scheitert.
+                  </p>
+                ) : (
+                  <div className="space-y-1.5">
+                    {dumps.map(d => (
+                      <a
+                        key={d.name}
+                        href={`/api/system/aacs-dumps/${encodeURIComponent(d.name)}`}
+                        download
+                        className="flex items-center gap-2 px-3 py-2 rounded-lg text-sm transition-colors text-amber-600 dark:text-amber-300 hover:bg-slate-100 dark:hover:bg-slate-800"
+                      >
+                        <Download size={14} className="flex-shrink-0" />
+                        <span className="truncate min-w-0 font-mono">{d.name}</span>
+                        <span className="ml-auto text-xs flex-shrink-0 text-slate-500 dark:text-slate-400 font-mono">
+                          {bytesLesbar(d.groesse_bytes)} · {zeitLesbar(d.geaendert)}
+                        </span>
+                      </a>
+                    ))}
+                  </div>
+                )}
+                <p className="text-xs text-slate-500 dark:text-slate-400">
+                  Ein AACS-Dump ist das, was das Laufwerk von der Disc gelesen hat, bevor der Schlüssel fehlte.
+                  Er enthält keinen Schlüssel und nützt dir allein nichts — aber du kannst ihn herunterladen und
+                  im MakeMKV-Forum im Bereich <strong className="text-slate-700 dark:text-slate-300">Ultra HD
+                  Blu-ray</strong> einreichen. Dort können Leute daraus den Schlüssel für deine Pressung ermitteln;
+                  den trägst du dann in deine KEYDB.cfg ein.
+                </p>
+              </div>
+
               <div className="p-4 rounded-xl border border-slate-200/80 dark:border-slate-800 bg-slate-50/50 dark:bg-slate-950/80 space-y-3">
                 <div className="flex items-center justify-between">
                   <p className="text-sm font-semibold text-slate-900 dark:text-slate-200">Update-Check</p>
@@ -672,7 +1144,9 @@ export default function SettingsPage() {
                           <p className="text-xs mt-1">
                             ⚠️ Update verfügbar — in der .env <code>MAKEMKV_VERSION={updates.makemkv.verfuegbar}</code> setzen,
                             dann auf der Rippy-Maschine <code>docker compose build worker &amp;&amp; docker compose up -d worker</code>.
-                            Neue Versionen bringen auch die neueste Disc-Schlüssel-Datenbank mit.
+                            {/* 25.07.2026 richtiggestellt: ein Update bringt KEINE Disc-Schluessel mit. */}
+                            Neue Versionen bringen Laufwerks-Unterstützung und Fehlerbehebungen — aber
+                            <strong> keine Disc-Schlüssel</strong>: die kommen aus dem Schlüsselspeicher.
                           </p>
                         )
                         : <span className="text-xs ml-1 text-emerald-600 dark:text-emerald-400">✓ aktuell</span>}

docker/worker/Dockerfile

@@ -16,9 +16,13 @@ FROM python:3.12-slim-bookworm AS makemkv-build
 # 1.18er-Laufwerks-Scan-Hängers (Forum t=38128) und der Flash-Fähigkeit
 # gepinnt. Beides erledigt: der Scan wird überall mit --noscan umgangen
 # (info-Lauf mit 1.18.4 auf der BU40N sauber durchgelaufen, 24.07.), und
-# das Laufwerk ist geflasht (LibreDrive v06.3 bestätigt). Die AKTUELLE
-# Version zählt, weil sie die neueste AACS-Schlüssel-Datenbank mitbringt —
-# 1.17.7 kannte z. B. den Key der Summer-Wars-UHD (MKB v82) nicht.
+# das Laufwerk ist geflasht (LibreDrive v06.3 bestätigt).
+# Richtigstellung 25.07.2026: Hier stand, die aktuelle Version zähle, weil sie
+# "die neueste AACS-Schlüssel-Datenbank mitbringt". Das ist widerlegt — MakeMKV
+# bringt gar keine Disc-Schlüssel mit, und der Online-Kanal liefert nichts mehr
+# (Messungen im Modul-Kopf von makemkv_daten.py). Aktuell bleiben lohnt sich
+# trotzdem: Laufwerks-Unterstützung und Fehlerbehebungen. Schlüssel für neue
+# UHD-Pressungen kommen ausschließlich aus der KEYDB.cfg im Datenverzeichnis.
 # MAKEMKV_URL_BASE ist übersteuerbar (Build-Arg): /download hat nur die
 # aktuelle Version, /download/old die älteren. Wenn Cloudflare BuildKit-
 # Downloads drosselt (24.07.: außerhalb des Builds ging alles, im Build

docker/worker/caps.py

@@ -6,26 +6,133 @@ Remote-GPU-Worker meldet sich hier genauso wie der eingebaute CPU-Worker.
 """
 
 import os
+import platform
 import re
 import shutil
 import subprocess
 
 
-def erkenne_encoder() -> list:
-    """Liste der verfügbaren Encoder-Backends auf dieser Maschine."""
-    gefunden = ["cpu-x264", "cpu-x265"]  # HandBrake-Software-Encoder, immer dabei
+HB_ENCODER_KOPF = re.compile(r"^-e,\s*--encoder\b")
 
-    # VAAPI: AMD (VCN) und Intel (QuickSync) melden sich über /dev/dri
-    if os.path.exists("/dev/dri/renderD128"):
+# Reihenfolge = Anzeige-Reihenfolge im UI.
+SIMD_STUFEN = ("avx512f", "avx2", "avx", "sse4_2")
+
+
+def parse_encoder_liste(hilfe_text: str) -> list:
+    """Video-Encoder, die DIESES HandBrake wirklich anbietet.
+
+    Quelle: `HandBrakeCLI --help`, Abschnitt `-e, --encoder <string>`
+    (AGENTS Regel D — im Worker-Image am 25.07.2026 gemessen, nicht geraten):
+
+        -e, --encoder <string>  Select video encoder:
+                                    svt_av1
+                                    x264
+                                    x265
+                                    ...
+           --encoder-preset <string>
+
+    Der Block endet an der nächsten Option — also an der ersten Zeile, deren
+    erstes nicht-leeres Zeichen ein Bindestrich ist.
+    """
+    encoder = []
+    im_block = False
+    for zeile in (hilfe_text or "").splitlines():
+        inhalt = zeile.strip()
+        if not im_block:
+            if HB_ENCODER_KOPF.match(inhalt):
+                im_block = True
+            continue
+        if not inhalt:
+            continue
+        if inhalt.startswith("-"):
+            break
+        encoder.append(inhalt.split()[0])
+    return encoder
+
+
+def leite_backends_ab(hb_encoder, dri_da: bool, nvidia_da: bool) -> list:
+    """Übersetzt die HandBrake-Encoder-Namen in die Backends, die das UI zeigt.
+
+    Zwei Ehrlichkeits-Regeln, die vorher fehlten (Befund 25.07.2026):
+    * Ohne HandBrake gibt es KEINE Encoder. Vorher standen `cpu-x264` und
+      `cpu-x265` fest verdrahtet in der Liste („immer dabei") — ein reiner
+      Rip-Worker ohne HandBrake behauptete damit, komprimieren zu können.
+    * Hardware zählt nur, wenn das Gerät da ist UND HandBrake den Encoder
+      überhaupt kennt. Vorher genügte `/dev/dri` — das Worker-Image kann
+      laut eigener Auskunft aber gar keinen Hardware-Encoder.
+    """
+    namen = {e.lower() for e in (hb_encoder or [])}
+    gefunden = []
+    if any(n.startswith("x264") for n in namen):
+        gefunden.append("cpu-x264")
+    if any(n.startswith("x265") for n in namen):
+        gefunden.append("cpu-x265")
+    if any(n.startswith("svt_av1") for n in namen):
+        gefunden.append("cpu-av1")
+    if dri_da and any(("qsv" in n) or ("vce" in n) or ("vaapi" in n) for n in namen):
         gefunden.append("vaapi")
-
-    # NVENC: NVIDIA-Treiber im Container sichtbar
-    if shutil.which("nvidia-smi") or os.path.exists("/usr/lib/x86_64-linux-gnu/libnvidia-encode.so.1"):
+    if nvidia_da and any("nvenc" in n for n in namen):
         gefunden.append("nvenc")
-
     return gefunden
 
 
+def beste_simd(flags_text: str) -> str:
+    """Höchste Vektor-Befehlsstufe der CPU — entscheidend fürs Software-Encodieren.
+
+    Befund 25.07.2026: Die Rippy-VM läuft auf dem generischen QEMU-CPU-Modell
+    („QEMU Virtual CPU version 2.5+") und hat deshalb KEIN AVX2, nur sse4_2.
+    x265 lebt von diesen Befehlen; ein 4K-Encode brauchte dort gemessene
+    28-55 Stunden. Sichtbar war das nirgends — genau diese Lücke schließt die
+    Anzeige. Abhilfe bei Proxmox/KVM: CPU-Typ der VM auf `host` stellen.
+    """
+    vorhanden = set((flags_text or "").split())
+    for stufe in SIMD_STUFEN:
+        if stufe in vorhanden:
+            return stufe
+    return "unbekannt"
+
+
+def _lies_cpuinfo() -> tuple:
+    """(Modellname, Flags-Text, Kernzahl) aus /proc/cpuinfo — leer auf Windows."""
+    modell, flags, kerne = "", "", 0
+    try:
+        with open("/proc/cpuinfo", encoding="utf-8", errors="replace") as f:
+            for zeile in f:
+                if zeile.startswith("processor"):
+                    kerne += 1
+                elif not modell and zeile.startswith("model name"):
+                    modell = zeile.split(":", 1)[-1].strip()
+                elif not flags and zeile.startswith("flags"):
+                    flags = zeile.split(":", 1)[-1].strip()
+    except OSError:
+        pass
+    return modell, flags, kerne
+
+
+def hole_handbrake_hilfe() -> str:
+    """`HandBrakeCLI --help` einmal abrufen (leer, wenn nicht installiert)."""
+    if not shutil.which("HandBrakeCLI"):
+        return ""
+    try:
+        aus = subprocess.run(
+            ["HandBrakeCLI", "--help"], capture_output=True, text=True, timeout=30
+        )
+        return (aus.stdout or "") + (aus.stderr or "")
+    except (OSError, subprocess.TimeoutExpired):
+        return ""
+
+
+def erkenne_encoder() -> list:
+    """Encoder-Backends, die auf DIESER Maschine wirklich nutzbar sind."""
+    hb_encoder = parse_encoder_liste(hole_handbrake_hilfe())
+    dri_da = os.path.exists("/dev/dri/renderD128")
+    nvidia_da = bool(
+        shutil.which("nvidia-smi")
+        or os.path.exists("/usr/lib/x86_64-linux-gnu/libnvidia-encode.so.1")
+    )
+    return leite_backends_ab(hb_encoder, dri_da, nvidia_da)
+
+
 def erkenne_ip() -> str:
     """Beste erratbare eigene IP (UDP-Route-Trick, KEIN echter Traffic).
 
@@ -56,11 +163,23 @@ def werkzeug_versionen() -> dict:
     """
     import socket
 
+    modell, flags, kerne = _lies_cpuinfo()
     info = {
         # Zuordnung im UI: hostname (für den Celery-Online-Abgleich) + IP
         "hostname": socket.gethostname(),
         "ip": erkenne_ip(),
+        # Rechenleistung fürs Software-Encodieren. Ohne diese drei Angaben war
+        # am 25.07.2026 nicht zu sehen, dass ein 4K-Encode auf dieser Maschine
+        # Tage statt Stunden braucht (kein AVX2, 4 Kerne).
+        "cpu_modell": modell or (platform.processor() or "unbekannt"),
+        "cpu_kerne": str(kerne or os.cpu_count() or 0),
+        "cpu_simd": beste_simd(flags),
     }
+    hb_encoder = parse_encoder_liste(hole_handbrake_hilfe())
+    if hb_encoder:
+        # Die ungefilterte Auskunft von HandBrake — damit im UI nachprüfbar ist,
+        # woher die Backend-Liste kommt.
+        info["handbrake_encoder"] = ",".join(hb_encoder)
     if shutil.which("makemkvcon"):
         info["makemkv"] = os.getenv("MAKEMKV_VERSION") or "installiert"
     if shutil.which("HandBrakeCLI"):
@@ -85,4 +204,31 @@ def werkzeug_versionen() -> dict:
         info["makemkv_key"] = "env"
     else:
         info["makemkv_key"] = "keiner"
+    # Sieht DIESER Worker eine KEYDB.cfg? Die API zeigt ihren eigenen Mount —
+    # bei einem Remote-Worker kann das etwas ganz anderes sein, und nur das
+    # Verzeichnis des rippenden Workers zählt (Befund 25.07.2026).
+    #
+    # Gemeldet wird die Angabe NUR, wenn das Datenverzeichnis hier wirklich
+    # eingehängt ist (os.path.ismount). Ein Remote-Transcode-Worker benutzt
+    # dasselbe Image — makemkvcon ist dort also vorhanden und der entrypoint
+    # legt den Ordner an —, er bekommt den Mount aber nicht und rippt nie.
+    # Ohne diese Prüfung trüge er im UI dauerhaft die Warnung "keine
+    # KEYDB.cfg", obwohl ihn das gar nichts angeht.
+    try:
+        import makemkv_daten
+        daten_dir = makemkv_daten.DATEN_DIR
+    except Exception:
+        daten_dir = ""
+    if shutil.which("makemkvcon") and daten_dir and os.path.ismount(daten_dir):
+        try:
+            info["keydb"] = "ja" if makemkv_daten.keydb_status().get("vorhanden") else "nein"
+        except Exception:
+            info["keydb"] = "unbekannt"
+        # Die entscheidende Zahl für 4K-UHD: wie viele Disc-Schlüssel kennt
+        # dieser Worker? 0 heißt, dass jede unbekannte UHD-Disc scheitert —
+        # makemkvcon holt sie unter Linux nie selbst (Befund 25.07.2026).
+        try:
+            info["schluessel"] = str(makemkv_daten.schluesselspeicher_status().get("schluessel", 0))
+        except Exception:
+            info["schluessel"] = "unbekannt"
     return info

docker/worker/celery_app.py

@@ -33,6 +33,30 @@ celery_app.conf.update(
 # zuverlässig im sys.path (ModuleNotFoundError 'caps', Deploy 23.07.).
 import caps  # noqa: E402
 import db  # noqa: E402
+import zombies  # noqa: E402
+
+
+@worker_ready.connect
+def raeume_job_leichen_auf(**kwargs):
+    """Nach der Gnadenfrist: Jobs, an denen niemand arbeitet, ehrlich auf
+    'failed' setzen (Details und Sicherungen in zombies.py).
+
+    Läuft im Hintergrund-Thread — der Worker soll sofort Aufgaben annehmen und
+    nicht zwei Minuten auf die Aufräumung warten.
+    """
+    import threading
+    import time
+
+    def spaeter():
+        time.sleep(zombies.GNADENFRIST_SEKUNDEN)
+        try:
+            db.init_db()
+            bericht = zombies.raeume_zombies_auf(celery_app, db)
+            print(f"Zombie-Erkennung: {bericht}")
+        except Exception as e:  # darf den Worker nie mitnehmen
+            print(f"Zombie-Erkennung fehlgeschlagen: {e}")
+
+    threading.Thread(target=spaeter, daemon=True, name="zombie-erkennung").start()
 
 
 @worker_ready.connect

docker/worker/db.py

@@ -181,6 +181,42 @@ def get_job_status(job_id: str) -> str:
     return zeile[0] if zeile else ""
 
 
+def list_jobs_mit_status(stati) -> list:
+    """Alle Jobs in einem der genannten Zustände (id/status/title/created_at).
+
+    Basis der Zombie-Erkennung: Jobs, die behaupten, es arbeite gerade jemand
+    an ihnen. Bewusst NUR diese schmale Auswahl statt der ganzen Zeile — die
+    Erkennung braucht nichts weiter.
+    """
+    from sqlalchemy import select
+
+    with engine.connect() as conn:
+        zeilen = conn.execute(
+            select(jobs.c.id, jobs.c.status, jobs.c.title, jobs.c.created_at)
+            .where(jobs.c.status.in_(list(stati)))
+        ).mappings().all()
+    return [dict(z) for z in zeilen]
+
+
+def zaehle_online_worker(sekunden: int = 120) -> int:
+    """Wie viele Worker gelten laut Herzschlag gerade als online?
+
+    Die Zombie-Erkennung vergleicht das mit der Zahl der Celery-Antworten:
+    melden sich weniger Worker als bekannt sind, ist die Auskunft
+    unvollstaendig — dann wird NICHTS als Leiche gewertet.
+    """
+    from datetime import timedelta
+
+    from sqlalchemy import func, select
+
+    grenze = utcnow() - timedelta(seconds=sekunden)
+    with engine.connect() as conn:
+        anzahl = conn.execute(
+            select(func.count()).select_from(workers).where(workers.c.last_seen >= grenze)
+        ).scalar()
+    return int(anzahl or 0)
+
+
 def update_job(job_id: str, **fields) -> None:
     with engine.begin() as conn:
         conn.execute(jobs.update().where(jobs.c.id == job_id).values(**fields))

docker/worker/entrypoint.sh

@@ -1,11 +1,51 @@
 #!/bin/sh
-# Schreibt den MakeMKV-Beta-Key aus der Umgebung in die Settings (falls gesetzt).
-# Ohne Key: DVD-Ripping geht immer, Blu-ray läuft im 30-Tage-Testmodus.
+# Bereitet MakeMKVs Datenverzeichnis vor, BEVOR der Worker startet.
+#
+# Wichtig (Befund 25.07.2026): Dieses Verzeichnis ist jetzt ein persistenter
+# Mount vom Host (docker-compose.yml). Darin liegen KEYDB.cfg (die einzige
+# heute funktionierende Schlüsselquelle für 4K-UHD), die AACS-Dumps
+# fehlgeschlagener Discs und MakeMKVs settings.conf. Deshalb wird die
+# settings.conf hier ERGÄNZT statt überschrieben — vorher hat dieses Skript
+# sie bei jedem Start plattgemacht und dabei alles außer app_Key gelöscht.
+#
+# Ohne Beta-Key: DVD-Ripping geht immer, Blu-ray läuft im 30-Tage-Testmodus.
 set -e
 
-if [ -n "${MAKEMKV_APP_KEY}" ]; then
-    mkdir -p /root/.MakeMKV
-    printf 'app_Key = "%s"\n' "${MAKEMKV_APP_KEY}" > /root/.MakeMKV/settings.conf
+DATEN_DIR="${MAKEMKV_DATA_DIR:-/root/.MakeMKV}"
+CONF="${DATEN_DIR}/settings.conf"
+
+# Die ganze Vorbereitung ist BEST EFFORT und läuft deshalb in einer Subshell
+# ohne set -e. Grund: Das Datenverzeichnis kommt jetzt vom Host und kann
+# schreibgeschützt sein oder einer fremden UID gehören (Freigabe, root_squash).
+# Vorher war das unmöglich — geschrieben wurde containerintern. Bräche der
+# Start daran ab, ergäbe "restart: unless-stopped" eine Endlosschleife, in der
+# auch reines DVD-Rippen tot wäre, obwohl das die Datei gar nicht braucht.
+# Denselben Weg geht tasks.py: OSError wird zur Warnung, der Job läuft weiter.
+if ! (
+    set +e
+    mkdir -p "${DATEN_DIR}" || exit 1
+    [ -f "${CONF}" ] || touch "${CONF}" || exit 1
+
+    # app_Key aus der Umgebung setzen: alte Zeile raus, neue ans Ende. Alles
+    # andere in der Datei bleibt stehen. (grep -v liefert Exit 1, wenn nichts
+    # übrig bleibt — das ist hier kein Fehler.)
+    if [ -n "${MAKEMKV_APP_KEY}" ]; then
+        grep -v '^app_Key' "${CONF}" > "${CONF}.neu" 2>/dev/null
+        printf 'app_Key = "%s"\n' "${MAKEMKV_APP_KEY}" >> "${CONF}.neu" || exit 1
+        mv "${CONF}.neu" "${CONF}" || exit 1
+    fi
+
+    # Web-Kontakt explizit einschalten. MakeMKV hat das per Default ohnehin an
+    # (Meldung 5074, am 25.07. im Worker verifiziert) — explizit steht es hier,
+    # damit die Einstellung nachvollziehbar ist und nicht versehentlich kippt.
+    # Quelle: forum.makemkv.com/forum/viewtopic.php?t=20364 (headless settings.conf)
+    grep -q '^app_UpdateEnable' "${CONF}" || printf 'app_UpdateEnable = "1"\n' >> "${CONF}" || exit 1
+    exit 0
+); then
+    echo "WARNUNG: ${DATEN_DIR} ist nicht beschreibbar." >&2
+    echo "         MakeMKV-Beta-Key und app_UpdateEnable wurden NICHT gesetzt." >&2
+    echo "         Der Worker startet trotzdem. Prüfe Rechte und Eigentümer des" >&2
+    echo "         Host-Verzeichnisses (Standard: /srv/rippy/makemkv)." >&2
 fi
 
 exec "$@"

docker/worker/makemkv_daten.py

@@ -0,0 +1,375 @@
+"""MakeMKV-Datenverzeichnis: Schluesselspeicher, KEYDB.cfg, AACS-Dumps.
+
+WARUM ES DIESE DATEI GIBT (Befund 25.07.2026, auf BEIDEN Maschinen gemessen):
+4K-UHD-Discs scheiterten mit "The volume key is unknown for this disc". Die
+Ursache ist weder die Disc noch das Laufwerk — LibreDrive v06.3 laeuft und
+MakeMKV liest die Disc — sondern:
+
+    makemkvcon unter LINUX ruft die Disc-Schluessel nie ab.
+    Die Windows-Version tut es.
+
+Gemessen, nicht vermutet:
+  * Linux: in KEINEM Lauf auch nur eine Verbindung nach draussen. Geprueft mit
+    leerem UND mit gefuelltem Schluesselspeicher, mit und ohne --noscan, mit
+    dev:/dev/sr0 und mit disc:0, und mit erzwungener frischer Pruefung
+    (update.conf geloescht, Meldung 5074 belegt den Web-Kontakt). Immer:
+    keine Verbindung, kein Schluessel.
+  * Windows, dieselbe Disc, dasselbe Laufwerk: Meldung 3338 "Downloading
+    latest HK to ...", Verbindung nach 185.84.108.20:443
+    (web33.majordomo.ru), _private_data.tar waechst — und die Disc geht auf
+    (TCOUNT:5, "Operation successfully completed").
+  * Der Code dafuer steckt auch im Linux-Binary: die Meldungsvorlage
+    "Downloading latest %1 to %2 ..." steht in makemkvcon. Sie loest nur nie
+    aus. Gleiches Symptom im Forum, seit Jahren offen und unbeantwortet.
+
+FRUEHERE FEHLDIAGNOSE, bewusst festgehalten: An dieser Stelle stand zuerst,
+MakeMKVs Schluessel-Kanal sei abgeschaltet. Das war FALSCH. Die Herleitung
+stuetzte sich auf zwei Hostnamen aus alten Forumsbeitraegen
+(hkdata.fairuse.org, hkdata.crabdance.com), die tatsaechlich nicht mehr
+aufloesen — MakeMKV benutzt sie aber laengst nicht mehr. Der Dienst lebt, der
+Worker erreicht ihn sogar; er wird unter Linux nur nie gefragt.
+
+WAS DARAUS FOLGT: Der Schluesselspeicher (_private_data.tar) muss von einer
+MakeMKV-Installation kommen, die ihn wirklich abruft — praktisch von Windows.
+Rippy nimmt ihn unter Einstellungen -> System entgegen. Die KEYDB.cfg bleibt
+der Notnagel fuer Pressungen, die auch MakeMKV selbst nicht kennt.
+
+Rippy liefert KEINE Schluessel mit, laedt keine herunter und verteilt keine.
+Es verwaltet nur, was der Nutzer selbst mitbringt.
+
+QUELLEN (AGENTS Regel D — externe Schnittstellen nie aus dem Kopf):
+  * Linux laedt keine Hashed Keys — dasselbe Symptom, mehrfach berichtet:
+    https://forum.makemkv.com/forum/viewtopic.php?t=25782
+    https://forum.makemkv.com/forum/viewtopic.php?t=34022
+  * Schluessel liegen als hkd_*.bin in _private_data.tar:
+    https://forum.makemkv.com/forum/viewtopic.php?t=32675
+  * Datenverzeichnis und Dateiname KEYDB.cfg GROSS geschrieben (unter Linux
+    case-sensitiv), dort geloest mit "cp KEYDB.cfg ~/.MakeMKV/":
+    https://forum.makemkv.com/forum/viewtopic.php?t=30636
+  * Zeilenformat der KEYDB.cfg (libaacs): Disc-Kennung = 40 Hex-Zeichen,
+    optional mit 0x-Praefix, dann "= Titel", danach optionale Felder wie
+    "| V | <32 Hex>"; Zeilen ab ";" sind Kommentare:
+    https://github.com/ShiftMediaProject/libaacs/blob/master/KEYDB.cfg
+  * Den AACS-Dump legt MakeMKV selbst ab, Meldung 3332 "Saved AACS dump file
+    as file:///root/.MakeMKV/<name>.tgz" (am 25.07.2026 so beobachtet).
+
+ZWILLINGSDATEI: liegt identisch unter docker/api/ und docker/worker/ — beide
+Images brauchen sie, ein gemeinsames Paket gibt es in diesem Projekt nicht
+(gleiche Lage wie bei db.py). Aenderungen IMMER in BEIDEN Dateien nachziehen.
+"""
+
+import io
+import os
+import re
+import tarfile
+from datetime import datetime, timezone
+
+# Container-Pfad aus der Umgebung: /root/.MakeMKV im Worker (nur dort sucht
+# makemkvcon), /app/makemkv-data in der API. Beide zeigen laut
+# docker-compose.yml auf DASSELBE Host-Verzeichnis.
+DATEN_DIR = os.getenv("MAKEMKV_DATA_DIR", "/root/.MakeMKV")
+
+# GROSS geschrieben — unter Linux case-sensitiv, "keydb.cfg" wird ignoriert.
+KEYDB_NAME = "KEYDB.cfg"
+
+# Obergrenze fuer den Upload. Eine vollstaendige oeffentliche KEYDB.cfg liegt
+# im einstelligen MB-Bereich; 64 MB sind reichlich Luft und verhindern, dass
+# eine versehentlich hochgeladene Riesendatei den Speicher vollschreibt.
+MAX_KEYDB_BYTES = 64 * 1024 * 1024
+
+# Eine Disc-Zeile beginnt mit der 40 Zeichen langen Hex-Kennung (optional mit
+# 0x davor), danach folgt das Gleichheitszeichen. Alles andere (Kommentare ab
+# ";", Leerzeilen, Fortsetzungsfelder) zaehlt nicht als Eintrag.
+_DISC_ZEILE = re.compile(r"^\s*(?:0x)?[0-9a-fA-F]{40}\s*=")
+
+
+def _iso(zeitstempel: float) -> str:
+    """Unix-Zeit -> ISO-8601 in UTC (sekundengenau), wie db.utcnow() es tut."""
+    return datetime.fromtimestamp(zeitstempel, timezone.utc).isoformat(timespec="seconds")
+
+
+def keydb_pfad(daten_dir: str = None) -> str:
+    """Voller Pfad zur KEYDB.cfg im Datenverzeichnis."""
+    return os.path.join(daten_dir or DATEN_DIR, KEYDB_NAME)
+
+
+def zaehle_disc_eintraege(inhalt: str) -> int:
+    """Zeilen mit Disc-Kennung zaehlen (pure Funktion, testbar).
+
+    Bewusst eine Heuristik und keine vollstaendige Auswertung: MakeMKV liest
+    die Datei mit seinem eigenen Parser, und wie viele Eintraege es daraus
+    macht, ist von aussen nicht sichtbar. Die Zahl dient nur dazu, im UI
+    "da liegt wirklich etwas drin" von "leere oder falsche Datei" zu
+    unterscheiden — sie wird deshalb auch genau so beschriftet.
+    """
+    return sum(1 for zeile in inhalt.splitlines() if _DISC_ZEILE.match(zeile))
+
+
+def keydb_pruefen(inhalt: str) -> str:
+    """Prueft hochgeladenen Inhalt; gibt deutschen Fehlertext oder "" zurueck.
+
+    Verhindert den haeufigsten Bedienfehler: statt der KEYDB.cfg landet die
+    HTML-Fehlerseite eines Downloads oder eine leere Datei im Verzeichnis —
+    MakeMKV wuerde dann still weiter "volume key is unknown" melden.
+    """
+    if not inhalt.strip():
+        return "Die Datei ist leer."
+    if len(inhalt.encode("utf-8")) > MAX_KEYDB_BYTES:
+        return (
+            "Die Datei ist groesser als "
+            f"{MAX_KEYDB_BYTES // (1024 * 1024)} MB — das ist keine KEYDB.cfg."
+        )
+    if inhalt.lstrip()[:1] == "<":
+        return (
+            "Das sieht nach HTML aus, nicht nach einer KEYDB.cfg — "
+            "vermutlich wurde eine Fehlerseite statt der Datei geladen."
+        )
+    if zaehle_disc_eintraege(inhalt) == 0:
+        return (
+            "Keine einzige Zeile mit Disc-Kennung gefunden (40 Hex-Zeichen, "
+            "dann ein Gleichheitszeichen). Das ist keine KEYDB.cfg."
+        )
+    return ""
+
+
+def keydb_status(daten_dir: str = None) -> dict:
+    """Zustand der KEYDB.cfg. Fehlt sie, ist das der Normalfall, kein Fehler."""
+    pfad = keydb_pfad(daten_dir)
+    try:
+        angaben = os.stat(pfad)
+    except OSError:
+        return {
+            "vorhanden": False,
+            "pfad": pfad,
+            "groesse_bytes": 0,
+            "eintraege": 0,
+            "geaendert": "",
+        }
+    eintraege = 0
+    try:
+        with open(pfad, encoding="utf-8", errors="replace") as datei:
+            eintraege = zaehle_disc_eintraege(datei.read())
+    except OSError:
+        pass  # Datei da, aber unlesbar: Groesse/Datum stimmen trotzdem
+    return {
+        "vorhanden": True,
+        "pfad": pfad,
+        "groesse_bytes": angaben.st_size,
+        "eintraege": eintraege,
+        "geaendert": _iso(angaben.st_mtime),
+    }
+
+
+def keydb_schreiben(inhalt: str, daten_dir: str = None) -> dict:
+    """Schreibt die KEYDB.cfg atomar und meldet den neuen Zustand.
+
+    Erst in eine Nebendatei, dann os.replace: waehrend ein Rip laeuft, darf
+    makemkvcon niemals eine halb geschriebene Datei zu sehen bekommen.
+    """
+    pfad = keydb_pfad(daten_dir)
+    os.makedirs(os.path.dirname(pfad), exist_ok=True)
+    neben = pfad + ".neu"
+    try:
+        with open(neben, "w", encoding="utf-8", newline="\n") as datei:
+            datei.write(inhalt)
+        os.replace(neben, pfad)
+    except OSError:
+        # Die Nebendatei nie liegen lassen: eine halb geschriebene
+        # KEYDB.cfg.neu verwirrt jeden, der ins Verzeichnis schaut, und
+        # belegt im Extremfall 64 MB, die niemand mehr aufräumt.
+        try:
+            os.remove(neben)
+        except OSError:
+            pass
+        raise
+    return keydb_status(daten_dir)
+
+
+def keydb_loeschen(daten_dir: str = None) -> dict:
+    """Entfernt die KEYDB.cfg (z. B. nach einem Fehlgriff beim Hochladen).
+
+    Nur "Datei war schon weg" wird geschluckt — das ist das gewünschte
+    Ergebnis. Jeder andere Fehler (schreibgeschützter Mount, fremder
+    Eigentümer) MUSS nach oben durch: sonst meldete die API einen Erfolg,
+    den es nicht gab, und die Datei wirkte beim nächsten Rip weiter.
+    """
+    try:
+        os.remove(keydb_pfad(daten_dir))
+    except FileNotFoundError:
+        pass
+    return keydb_status(daten_dir)
+
+
+def ist_aacs_dump(name: str) -> bool:
+    """Dateiname eines AACS-Dumps? (pure Funktion, testbar)
+
+    MakeMKV legt ihn als <MKB..._NAME_....>.tgz direkt im Datenverzeichnis ab
+    (Meldung 3332). Pfadtrenner und fuehrende Punkte werden hier schon
+    ausgeschlossen, damit der Download-Endpunkt keine Pfad-Tricks erlaubt.
+    """
+    return (
+        name.endswith(".tgz")
+        and "/" not in name
+        and "\\" not in name
+        and not name.startswith(".")
+    )
+
+
+def dumps_auflisten(daten_dir: str = None) -> list:
+    """Alle AACS-Dumps im Datenverzeichnis, neueste zuerst."""
+    ordner = daten_dir or DATEN_DIR
+    try:
+        namen = os.listdir(ordner)
+    except OSError:
+        return []
+    liste = []
+    for name in namen:
+        if not ist_aacs_dump(name):
+            continue
+        try:
+            angaben = os.stat(os.path.join(ordner, name))
+        except OSError:
+            continue
+        liste.append(
+            {
+                "name": name,
+                "groesse_bytes": angaben.st_size,
+                "geaendert": _iso(angaben.st_mtime),
+                "_sort": angaben.st_mtime,
+            }
+        )
+    liste.sort(key=lambda eintrag: eintrag["_sort"], reverse=True)
+    for eintrag in liste:
+        del eintrag["_sort"]
+    return liste
+
+
+# --- Schluesselspeicher (_private_data.tar) -------------------------------
+#
+# Das ist MakeMKVs eigener Speicher fuer die "Hashed Keys": ein tar-Archiv mit
+# hkd_*.bin-Eintraegen. Unter Windows fuellt MakeMKV es selbst (Meldung 3338),
+# unter Linux nie — siehe Modul-Kopf. Rippy nimmt die Datei deshalb entgegen
+# und legt sie ins Datenverzeichnis; MakeMKV liest sie beim naechsten Start.
+
+PRIVATE_DATA_NAME = "_private_data.tar"
+
+# Der Speicher lag am 25.07.2026 bei rund 6 MB und waechst mit jeder neuen
+# Pressung. 64 MB sind reichlich Luft — und derselbe Wert wie
+# client_max_body_size in docker/ui/nginx.conf: waere die Grenze hier hoeher,
+# wuerde nginx den Upload abweisen, bevor die API ihn ueberhaupt sieht.
+MAX_PRIVATE_DATA_BYTES = 64 * 1024 * 1024
+
+
+def private_data_pfad(daten_dir: str = None) -> str:
+    """Voller Pfad zum Schluesselspeicher im Datenverzeichnis."""
+    return os.path.join(daten_dir or DATEN_DIR, PRIVATE_DATA_NAME)
+
+
+def zaehle_schluessel(rohdaten: bytes) -> int:
+    """Anzahl der hkd_*.bin-Eintraege im Archiv (pure Funktion, testbar).
+
+    Das ist die ehrliche Kennzahl fuer "wie viele Disc-Schluessel kennt diese
+    Installation". Ein frischer, leerer Speicher enthaelt nur eine
+    Index-Datei und kommt hier auf 0 — genau der Zustand, in dem jede
+    unbekannte UHD-Disc scheitert.
+    """
+    try:
+        with tarfile.open(fileobj=io.BytesIO(rohdaten)) as archiv:
+            return sum(1 for name in archiv.getnames() if name.startswith("hkd_"))
+    except (tarfile.TarError, OSError, EOFError):
+        return 0
+
+
+def private_data_pruefen(rohdaten: bytes) -> str:
+    """Prueft hochgeladene Rohdaten; deutscher Fehlertext oder "".
+
+    Faengt die beiden Bedienfehler ab, die sonst still danebengehen: eine
+    voellig andere Datei hochladen, oder den Speicher einer Installation, die
+    selbst noch keine Schluessel geholt hat (dann aendert sich nichts, und
+    niemand versteht warum).
+    """
+    if not rohdaten:
+        return "Die Datei ist leer."
+    if len(rohdaten) > MAX_PRIVATE_DATA_BYTES:
+        return (
+            "Die Datei ist groesser als "
+            f"{MAX_PRIVATE_DATA_BYTES // (1024 * 1024)} MB — das ist kein "
+            "MakeMKV-Schluesselspeicher."
+        )
+    try:
+        with tarfile.open(fileobj=io.BytesIO(rohdaten)) as archiv:
+            namen = archiv.getnames()
+    except (tarfile.TarError, OSError, EOFError):
+        return (
+            "Das ist kein tar-Archiv. Erwartet wird die Datei "
+            f"{PRIVATE_DATA_NAME} aus dem MakeMKV-Datenverzeichnis."
+        )
+    if not any(name.startswith("hkd_") for name in namen):
+        return (
+            "In dieser Datei steckt kein einziger Schluessel (kein hkd_*.bin). "
+            "Sie stammt vermutlich von einer MakeMKV-Installation, die selbst "
+            "noch keine geholt hat — oeffne dort erst einmal eine Disc."
+        )
+    return ""
+
+
+def schluesselspeicher_status(daten_dir: str = None) -> dict:
+    """Zustand des Schluesselspeichers. Fehlt er, ist das kein Fehler."""
+    pfad = private_data_pfad(daten_dir)
+    try:
+        angaben = os.stat(pfad)
+        with open(pfad, "rb") as datei:
+            schluessel = zaehle_schluessel(datei.read())
+    except OSError:
+        return {
+            "vorhanden": False,
+            "pfad": pfad,
+            "groesse_bytes": 0,
+            "schluessel": 0,
+            "geaendert": "",
+        }
+    return {
+        "vorhanden": True,
+        "pfad": pfad,
+        "groesse_bytes": angaben.st_size,
+        "schluessel": schluessel,
+        "geaendert": _iso(angaben.st_mtime),
+    }
+
+
+def private_data_schreiben(rohdaten: bytes, daten_dir: str = None) -> dict:
+    """Legt den Schluesselspeicher atomar ab und meldet den neuen Zustand.
+
+    Atomar aus demselben Grund wie bei der KEYDB.cfg: waehrend ein Rip laeuft,
+    darf makemkvcon nie ein halb geschriebenes Archiv sehen.
+    """
+    pfad = private_data_pfad(daten_dir)
+    os.makedirs(os.path.dirname(pfad), exist_ok=True)
+    neben = pfad + ".neu"
+    try:
+        with open(neben, "wb") as datei:
+            datei.write(rohdaten)
+        os.replace(neben, pfad)
+    except OSError:
+        try:
+            os.remove(neben)
+        except OSError:
+            pass
+        raise
+    return schluesselspeicher_status(daten_dir)
+
+
+def settings_conf_zusammenfuehren(inhalt: str, key: str) -> str:
+    """app_Key setzen, ohne den Rest der settings.conf zu verlieren (pure).
+
+    Bis zum 25.07.2026 haben entrypoint.sh UND tasks.py die Datei komplett
+    ueberschrieben. Mit dem jetzt persistenten Datenverzeichnis waere damit
+    bei jedem Containerstart und vor jedem Rip alles andere weg — z. B.
+    app_UpdateEnable. Leerer Key laesst die vorhandene Zeile ebenfalls fallen,
+    damit ein bewusst geleerter Key nicht heimlich weiterwirkt.
+    """
+    zeilen = [z for z in inhalt.splitlines() if not z.lstrip().startswith("app_Key")]
+    if key:
+        zeilen.append('app_Key = "{}"'.format(key))
+    text = "\n".join(zeilen).strip("\n")
+    return text + "\n" if text else ""

docker/worker/ripping.py

@@ -25,6 +25,36 @@ class RipAbbruch(Exception):
     Nutzer den Job abgebrochen hat (Status 'canceling' in der DB)."""
 
 
+# include/uapi/linux/cdrom.h — dasselbe ioctl wie in api/devices.py
+CDROMEJECT = 0x5309
+
+
+def wirf_disc_aus(device_path: str) -> bool:
+    """Wirft die Disc aus; gibt zurück, ob es geklappt hat. Wirft NIE.
+
+    Befund 25.07.2026: Die Einstellung „Automatischer Auswurf" (Standard: ein,
+    Beschreibung „Disc nach erfolgreichem Ripping automatisch auswerfen") wurde
+    von niemandem gelesen — bei DVD/Blu-ray warf Rippy nie aus.
+
+    Bewusst hier und nicht in detection.py: das Modul ist ein byteweiser
+    Zwilling der API-Kopie. `fcntl` gibt es nur unter Linux — der native
+    Windows-Worker lädt ripping.py ebenfalls, rippt dort aber nie.
+    """
+    try:
+        from fcntl import ioctl
+    except ImportError:  # Windows
+        return False
+    try:
+        fd = os.open(device_path, os.O_RDONLY | os.O_NONBLOCK)
+        try:
+            ioctl(fd, CDROMEJECT, 0)
+        finally:
+            os.close(fd)
+        return True
+    except OSError:
+        return False
+
+
 def check_makemkv_installed() -> bool:
     """Prüft, ob makemkvcon installiert ist."""
     return shutil.which("makemkvcon") is not None
@@ -114,7 +144,7 @@ def lies_titel_info(device_path: str, timeout: int = 300) -> list:
 
 
 def rip_titel_auswahl(device_path: str, output_dir: str, titel_liste: list,
-                      progress_cb=None) -> dict:
+                      progress_cb=None, log_cb=None) -> dict:
     """Rippt GENAU die gewählten Titel (makemkvcon kann pro Aufruf nur einen
     Titel oder 'all' — also ein Aufruf je Titel, Fortschritt anteilig)."""
     gesamt = len(titel_liste)
@@ -124,7 +154,8 @@ def rip_titel_auswahl(device_path: str, output_dir: str, titel_liste: list,
             if progress_cb:
                 progress_cb(int((_i * 100 + p) / gesamt))
 
-        ergebnis = run_makemkv(device_path, output_dir, progress_cb=anteilig, titel=str(nr))
+        ergebnis = run_makemkv(device_path, output_dir, progress_cb=anteilig, titel=str(nr),
+                               log_cb=log_cb)
         if ergebnis.get("status") == "cancelled":
             return ergebnis
         if ergebnis.get("status") != "success":
@@ -181,6 +212,27 @@ def lies_datei_dauer(pfad: str, timeout: int = 120) -> int:
     return parse_scan_dauer((ergebnis.stdout or "") + (ergebnis.stderr or ""))
 
 
+_MSG_RE = re.compile(r'^MSG:(\d+),\d+,\d+,"((?:[^"\\]|\\.)*)"')
+
+
+def parse_msg(zeile: str):
+    """MSG-Zeile -> (code, klartext) oder None (pure Funktion, testbar).
+
+    Format laut https://www.makemkv.com/developers/usage.txt:
+    MSG:code,flags,count,"message","format","param0",... — Feld 4 ist der
+    fertig zusammengesetzte Klartext.
+
+    Bis zum 25.07.2026 stand hier line.split(",", 4)[3]: das schnitt JEDE
+    Meldung ab, die selbst ein Komma enthaelt — und MakeMKV schreibt solche
+    laufend ("Title #1 has length of 12 seconds, which is less than ...").
+    Deshalb eine Regex, die die Anfuehrungszeichen respektiert.
+    """
+    treffer = _MSG_RE.match(zeile.strip())
+    if not treffer:
+        return None
+    return int(treffer.group(1)), treffer.group(2).replace('\\"', '"')
+
+
 def get_progress_from_prgv(line: str) -> int:
     """Extrahiert Gesamt-Fortschritt (0-100) aus einer PRGV-Zeile.
 
@@ -203,6 +255,33 @@ def check_handbrake_installed() -> bool:
 
 DEFAULT_HB_PRESET = "H.265 MKV 1080p30"
 
+# Ein Preset je Disc-Typ (Befund 25.07.2026). Vorher galt EIN Preset für
+# alles: eine 4K-UHD wurde damit auf 1080p heruntergerechnet und eine DVD auf
+# 1080p hochskaliert — beides Unsinn, und beim ersten UHD-Rip wäre die 4K-
+# Auflösung still verlorengegangen. Den Disc-Typ kennt Rippy ohnehin.
+PRESET_SCHLUESSEL = {
+    "dvd": "transcodePresetDvd",
+    "bluray": "transcodePresetBluray",
+    "uhd": "transcodePresetUhd",
+}
+
+
+def preset_fuer(disc_type: str, einstellungen: dict) -> str:
+    """Welches HandBrake-Preset gilt für diesen Disc-Typ? (pure, testbar)
+
+    Reihenfolge: Preset des Disc-Typs → allgemeines transcodePreset →
+    DEFAULT_HB_PRESET. Diese Kette hält Bestandsinstallationen am Leben, in
+    denen nur `transcodePreset` gesetzt ist: solange der Nutzer die neuen
+    Felder nicht speichert, ändert sich sein Verhalten nicht.
+    """
+    einstellungen = einstellungen or {}
+    schluessel = PRESET_SCHLUESSEL.get(disc_type or "")
+    if schluessel:
+        eigen = (einstellungen.get(schluessel) or "").strip()
+        if eigen:
+            return eigen
+    return (einstellungen.get("transcodePreset") or "").strip() or DEFAULT_HB_PRESET
+
 
 def build_handbrake_cmd(input_path: str, output_path: str, preset: str = DEFAULT_HB_PRESET) -> list:
     """Baut das HandBrake-Kommando für die Kompressions-Stufe (pure Funktion).
@@ -222,20 +301,57 @@ def build_handbrake_cmd(input_path: str, output_path: str, preset: str = DEFAULT
     ]
 
 
+HB_ENCODE_RE = re.compile(
+    r'^Encoding:\s*task\s+(\d+)\s+of\s+(\d+),\s*(\d+(?:\.\d+)?)\s*%'
+)
+
+
 def get_progress_from_line(line: str) -> int:
-    """Extrahiert Fortschritt in Prozent aus HandBrake-Ausgabe.
+    """Extrahiert den ENCODE-Fortschritt in Prozent aus HandBrake-Ausgabe.
 
-    Testfund 22.07.: echtes HandBrake schreibt „45.50 %" MIT Leerzeichen vor
-    dem Prozentzeichen — eine Regex ohne \\s* parst NIE echte Ausgabe.
+    Gibt **-1** zurück, wenn die Zeile kein Encode-Fortschritt ist — genau wie
+    get_progress_from_prgv. Sonst wäre ein echtes „0 %" nicht von „keine
+    Angabe" zu unterscheiden, und der Anfang des Encodes bliebe unsichtbar.
+
+    Formatstrings aus dem HandBrakeCLI-Binary im Worker-Image gelesen
+    (AGENTS Regel D — nicht aus dem Kopf):
+      Scanning title %d of %d, preview %d, %.2f %%              → Scan, NICHT Encode
+      Encoding: task %d of %d, %.2f %%       (%.2f fps, avg     → Encode
+      Encoding: task %d of %d, Searching for start time, %.2f   → Vorlauf, NICHT Encode
+
+    Befund 25.07.2026 (Akira-UHD, live gemessen): Die alte Regex nahm JEDE
+    Zahl vor einem Prozentzeichen — also auch den Scan-Durchlauf, der VOR dem
+    Encodieren einmal bis 100 % hochläuft. Die Anzeige stand deshalb auf 99 %,
+    während der eigentliche Encode bei 1 % war. Zusammen mit dem alten Filter
+    `progress > 0` im Aufrufer blieb sie dort stundenlang kleben, weil
+    int(0.87) == 0 verworfen wurde.
+
+    `task N of M` wird mitgerechnet: Presets mit zwei Durchläufen zählen die
+    Prozente je Durchlauf neu, sonst sprang die Anzeige mitten in der Datei
+    zurück auf 0.
     """
-    match = re.search(r'(\d+\.\d+)\s*%', line)
-    if match:
-        return int(float(match.group(1)))
-    return 0
+    match = HB_ENCODE_RE.match(line.strip())
+    if not match:
+        return -1
+    aktuell, gesamt, prozent = int(match.group(1)), int(match.group(2)), float(match.group(3))
+    if gesamt < 1 or aktuell < 1:
+        return -1
+    return int(((aktuell - 1) * 100 + prozent) / gesamt)
 
 
-def run_handbrake(input_path: str, output_path: str, preset: str = DEFAULT_HB_PRESET, progress_cb=None) -> dict:
-    """Komprimiert eine MKV-Datei mit HandBrakeCLI; meldet Fortschritt."""
+def run_handbrake(input_path: str, output_path: str, preset: str = DEFAULT_HB_PRESET,
+                  progress_cb=None, abbruch_cb=None) -> dict:
+    """Komprimiert eine MKV-Datei mit HandBrakeCLI; meldet Fortschritt.
+
+    `abbruch_cb` wird bei JEDER Ausgabezeile aufgerufen und soll RipAbbruch
+    werfen, wenn der Nutzer abgebrochen hat. Bewusst ein eigener Kanal neben
+    `progress_cb` — aus demselben Grund wie `log_cb` bei run_makemkv: der
+    Fortschritts-Callback verwirft Aufrufe mit unveränderter Prozentzahl, und
+    genau daran hing der Abbruch früher. Bei einem 4K-Encode mit einem Prozent
+    je halber Stunde sah „Abbrechen" deshalb minutenlang wirkungslos aus
+    (Befund 25.07.2026). Zusätzlich greift es damit auch während des
+    Scan-Durchlaufs, der gar keine Encode-Prozente ausgibt.
+    """
     if not check_handbrake_installed():
         return {"status": "error", "error": "HandBrakeCLI ist nicht installiert"}
 
@@ -247,44 +363,64 @@ def run_handbrake(input_path: str, output_path: str, preset: str = DEFAULT_HB_PR
             text=True,
             bufsize=1
         )
-
-        try:
-            for line in process.stdout:
-                progress = get_progress_from_line(line)
-                if progress > 0 and progress_cb:
-                    progress_cb(progress)
-        except RipAbbruch:
-            process.kill()
-            process.wait()
-            return {"status": "cancelled", "error": "Abgebrochen durch Nutzer"}
-
-        process.wait()
-
-        if process.returncode == 0 and os.path.exists(output_path):
-            return {"status": "success", "output_path": output_path}
-        return {
-            "status": "error",
-            "error": f"HandBrake endete mit Code {process.returncode}",
-            "return_code": process.returncode,
-        }
+        return _handbrake_schleife(process, output_path, abbruch_cb, progress_cb)
     except Exception as e:
         return {"status": "error", "error": str(e)}
 
 
-def build_abcde_cmd(device_path: str, config_path: str) -> list:
+def _handbrake_schleife(process, output_path: str, abbruch_cb=None, progress_cb=None) -> dict:
+    """Liest HandBrakes Ausgabe und wertet sie aus. Eigene Funktion, damit die
+    Reihenfolge (Abbruch VOR Fortschritt) ohne echtes HandBrake testbar ist."""
+    try:
+        for line in process.stdout:
+            # Zuerst der Abbruch — unabhängig davon, ob die Zeile überhaupt
+            # einen Fortschritt enthält. Sonst haengt „Abbrechen" daran, dass
+            # sich die Prozentzahl bewegt (Befund 25.07.2026).
+            if abbruch_cb:
+                abbruch_cb()
+            progress = get_progress_from_line(line)
+            # >= 0: ein echtes 0 % ist eine Angabe und muss durch. Der alte
+            # Filter `> 0` verwarf den gesamten ersten Prozentpunkt — bei
+            # einem 4K-Encode sind das Stunden ohne sichtbare Bewegung.
+            if progress >= 0 and progress_cb:
+                progress_cb(progress)
+    except RipAbbruch:
+        process.kill()
+        process.wait()
+        return {"status": "cancelled", "error": "Abgebrochen durch Nutzer"}
+
+    process.wait()
+
+    if process.returncode == 0 and os.path.exists(output_path):
+        return {"status": "success", "output_path": output_path}
+    return {
+        "status": "error",
+        "error": f"HandBrake endete mit Code {process.returncode}",
+        "return_code": process.returncode,
+    }
+
+
+def build_abcde_cmd(device_path: str, config_path: str, auswerfen: bool = True) -> list:
     """Baut das abcde-Kommando (pure Funktion, testbar).
 
     -o = Ausgabeformat (flac), -N = nicht-interaktiv, -x = Eject am Ende,
     -c = Config-Datei (enthält OUTPUTDIR). NIE ein Verzeichnis an -o geben.
+
+    Befund 25.07.2026: `-x` stand fest verdrahtet drin. Damit warf eine
+    Audio-CD IMMER aus, während eine DVD/Blu-ray NIE auswarf — und die
+    Einstellung „Automatischer Auswurf" regelte keines von beidem, weil sie
+    nirgends gelesen wurde. Jetzt entscheidet sie hier mit.
     """
-    return [
+    cmd = [
         "abcde",
         "-d", device_path,
         "-o", "flac",
         "-N",
-        "-x",
-        "-c", config_path
     ]
+    if auswerfen:
+        cmd.append("-x")
+    cmd += ["-c", config_path]
+    return cmd
 
 
 def write_abcde_config(output_dir: str) -> str:
@@ -297,8 +433,17 @@ def write_abcde_config(output_dir: str) -> str:
     return tmp.name
 
 
-def run_makemkv(device_path: str, output_dir: str, progress_cb=None, titel: str = "all") -> dict:
-    """Rippt eine DVD/Blu-ray verlustfrei mit makemkvcon; meldet Fortschritt."""
+def run_makemkv(device_path: str, output_dir: str, progress_cb=None, titel: str = "all",
+                log_cb=None) -> dict:
+    """Rippt eine DVD/Blu-ray verlustfrei mit makemkvcon; meldet Fortschritt.
+
+    log_cb(code, text) bekommt JEDE MakeMKV-Meldung. Bewusst ein eigener
+    Kanal statt progress_cb: der Fortschritts-Callback in tasks.py verwirft
+    Aufrufe, bei denen sich die Prozentzahl nicht geaendert hat — Meldungen
+    waeren dort also grossteils verschwunden. Ohne diesen Kanal war am
+    25.07.2026 nicht von aussen erkennbar, dass MakeMKV bei der UHD-Disc
+    nicht einmal versucht, einen Schluessel zu holen (siehe makemkv_daten).
+    """
     if not check_makemkv_installed():
         return {"status": "error", "error": "makemkvcon ist nicht installiert"}
 
@@ -328,15 +473,23 @@ def run_makemkv(device_path: str, output_dir: str, progress_cb=None, titel: str
         try:
             for line in process.stdout:
                 progress = get_progress_from_prgv(line)
-                if progress >= 0 and progress_cb:
-                    progress_cb(progress)
-                elif line.startswith("MSG:"):
-                    # MSG:code,flags,count,"message",... — Klartext ist Feld 4
-                    teile = line.split(",", 4)
-                    if len(teile) >= 4:
-                        letzte_meldung = teile[3].strip('"')
-                        if any(muster in letzte_meldung for muster in KRITISCH):
-                            kritische_meldungen.append(letzte_meldung)
+                if progress >= 0:
+                    if progress_cb:
+                        progress_cb(progress)
+                    continue
+                meldung = parse_msg(line)
+                if meldung is None:
+                    continue
+                code, letzte_meldung = meldung
+                if any(muster in letzte_meldung for muster in KRITISCH):
+                    kritische_meldungen.append(letzte_meldung)
+                if log_cb:
+                    try:
+                        log_cb(code, letzte_meldung)
+                    except RipAbbruch:
+                        raise
+                    except Exception:
+                        pass  # Protokollieren darf einen laufenden Rip nie beenden
         except RipAbbruch:
             process.kill()
             process.wait()
@@ -373,7 +526,7 @@ def run_makemkv(device_path: str, output_dir: str, progress_cb=None, titel: str
 
 def rip_video(device_path: str, disc_id: str, disc_type: str = "dvd", progress_cb=None,
               output_dir: str = None, nur_hauptfilm: bool = False,
-              titel_liste: list = None) -> dict:
+              titel_liste: list = None, log_cb=None) -> dict:
     """Rippt eine DVD oder Blu-ray verlustfrei mit MakeMKV.
 
     Bewusst KEIN eigener Celery-Task: der einzige Task ist worker.tasks.rip_disc,
@@ -388,7 +541,7 @@ def rip_video(device_path: str, disc_id: str, disc_type: str = "dvd", progress_c
 
     if titel_liste:
         os.makedirs(output_dir, exist_ok=True)
-        return rip_titel_auswahl(device_path, output_dir, titel_liste, progress_cb)
+        return rip_titel_auswahl(device_path, output_dir, titel_liste, progress_cb, log_cb)
 
     titel = "all"
     if nur_hauptfilm:
@@ -397,11 +550,14 @@ def rip_video(device_path: str, disc_id: str, disc_type: str = "dvd", progress_c
         if haupt is not None:
             titel = str(haupt)
         # Kein Titel ermittelbar → ehrlich auf 'all' zurückfallen statt raten
-    return run_makemkv(device_path, output_dir, progress_cb=progress_cb, titel=titel)
+    return run_makemkv(device_path, output_dir, progress_cb=progress_cb, titel=titel,
+                       log_cb=log_cb)
 
 
-def rip_cd(device_path: str, disc_id: str, progress_cb=None, output_dir: str = None) -> dict:
-    """Rippt eine CD mit abcde (FLAC)."""
+def rip_cd(device_path: str, disc_id: str, progress_cb=None, output_dir: str = None,
+           auswerfen: bool = True) -> dict:
+    """Rippt eine CD mit abcde (FLAC). `auswerfen` = Einstellung „Automatischer
+    Auswurf" (abcde macht das selbst per -x)."""
     if not check_abcde_installed():
         return {
             "status": "error",
@@ -425,7 +581,7 @@ def rip_cd(device_path: str, disc_id: str, progress_cb=None, output_dir: str = N
 
     try:
         process = subprocess.Popen(
-            build_abcde_cmd(device_path, config_path),
+            build_abcde_cmd(device_path, config_path, auswerfen=auswerfen),
             stdout=subprocess.PIPE,
             stderr=subprocess.STDOUT,
             text=True,

docker/worker/tasks.py

@@ -12,14 +12,18 @@ komprimiert danach auf Arbeitsgröße. Die Rohdatei liegt nur temporär in
 /app/temp und wird nach Erfolg gelöscht (Setting keepOriginal behält sie).
 """
 
+import errno
 import glob
 import json
 import os
+import posixpath
 import shutil
+import time
 
 import requests
 
 import db
+import makemkv_daten
 import medien
 import notify
 from celery_app import celery_app
@@ -34,14 +38,15 @@ except ImportError:  # Windows: kein fcntl
     disc_size_bytes = None
 
 from ripping import (
-    DEFAULT_HB_PRESET,
     RIP_OUTPUT_DIR,
     RipAbbruch,
     lies_datei_dauer,
     lies_titel_info,
+    preset_fuer,
     rip_cd,
     rip_video,
     run_handbrake,
+    wirf_disc_aus,
 )
 
 API_URL = os.getenv("API_URL", "http://api:8000")
@@ -88,29 +93,69 @@ def pfad_lokal(pfad: str, mapping: str = None) -> str:
 RAW_DIR = os.getenv("RAW_DIR", "/app/temp/raw")
 MEDIA_ROOT = "/app/media"
 
+# Wie oft während einer Kompression nachgesehen wird, ob der Nutzer abgebrochen
+# hat. Eine DB-Abfrage alle paar Sekunden ist nichts gegen einen Encode, der
+# Stunden läuft — und „Abbrechen" fühlt sich damit sofort an.
+ABBRUCH_INTERVALL_SEKUNDEN = 5
+
+
+def unter_wurzel(pfad: str, wurzel: str) -> bool:
+    """Liegt `pfad` wirklich unterhalb von `wurzel` (oder IST es die Wurzel)?
+
+    Pure Funktion, testbar. Ein nacktes `startswith()` genügt nicht:
+    „/app/media-boese/x" beginnt mit „/app/media", liegt aber ausserhalb
+    (Befund 25.07.2026 bei der Durchsicht). Immer „/" als Trenner — das sind
+    Container-Pfade, auch wenn ein nativer Windows-Worker das Modul lädt.
+
+    Gleichlautend in docker/api/main.py; es gibt kein geteiltes Paket zwischen
+    den Containern.
+    """
+    if not pfad or not wurzel:
+        return False
+    sauber = wurzel.rstrip("/") or "/"
+    return pfad == sauber or pfad.startswith(sauber + "/")
+
 
 def _zielbasis(target_dir, disc_type: str) -> str:
-    """Ablagebasis: vom Nutzer gewähltes Ziel (validiert) oder Standard."""
+    """Ablagebasis: vom Nutzer gewähltes Ziel (validiert) oder Standard.
+
+    posixpath statt os.path — aus demselben Grund wie in _arbeitsverzeichnis:
+    das sind IMMER Container-Pfade. os.path.normpath macht unter Windows
+    Backslashes daraus, und dann greift die MEDIA_ROOT-Prüfung nicht mehr, das
+    gewählte Ziel fiele still auf den Standard zurück. Aufgefallen 25.07.2026,
+    als der Test dafür erstmals unter Windows lief. Live war es nie: aufgerufen
+    wird nur aus rip_disc, und das ist auf Windows-Workern verriegelt.
+    """
     if target_dir:
-        normalisiert = os.path.normpath(target_dir)
-        if normalisiert.startswith(MEDIA_ROOT):
+        normalisiert = posixpath.normpath(target_dir)
+        if unter_wurzel(normalisiert, MEDIA_ROOT):
             return normalisiert
-    return os.path.join(RIP_OUTPUT_DIR, disc_type)
+    return posixpath.join(RIP_OUTPUT_DIR, disc_type)
 
 
-def _arbeitsverzeichnis(einstellungen: dict) -> str:
-    """Basis für Roh-Rips: UI-Setting `workDir` (unter /app/media, z. B. eine
-    NAS-Freigabe) schlägt den Container-Default /app/temp/raw.
+def _arbeitsverzeichnis(einstellungen: dict, job_wahl: str = "") -> str:
+    """Basis für Roh-Rips. Reihenfolge: Wahl DIESES Rips → UI-Setting
+    `workDir` → Container-Default /app/temp/raw.
 
     Hintergrund (Commander 24.07.): Die VM-Platte (150 GB) reicht für BD-50,
     aber eine 4K-UHD (bis 100 GB roh + Kompression daneben) sprengt sie —
     das Arbeitsverzeichnis muss deshalb auf ein großes Ziel umlegbar sein.
+
+    Pro Rip wählbar seit 25.07.2026 (Commander-Wunsch): beim „Rippen starten"
+    entscheidet man je Disc, wo die Rohdaten landen. Das Setting bleibt der
+    Standard — und ist damit der Wert, der bei Vollautomatik-Rips greift, bei
+    denen niemand gefragt wird.
     """
-    work_dir = (einstellungen.get("workDir") or "").strip()
-    if work_dir:
-        normalisiert = os.path.normpath(work_dir)
-        if normalisiert.startswith(MEDIA_ROOT):
-            return normalisiert
+    # posixpath statt os.path: Das sind IMMER Container-Pfade (/app/media/...),
+    # auch wenn ein nativer Windows-Worker dieses Modul lädt — der übersetzt
+    # sie erst später mit pfad_lokal(). os.path.normpath macht unter Windows
+    # Backslashes daraus, und dann greift die MEDIA_ROOT-Prüfung nicht mehr.
+    for kandidat in (job_wahl, einstellungen.get("workDir")):
+        wert = (kandidat or "").strip()
+        if wert:
+            normalisiert = posixpath.normpath(wert)
+            if unter_wurzel(normalisiert, MEDIA_ROOT):
+                return normalisiert
     return RAW_DIR
 
 
@@ -147,19 +192,117 @@ def _makemkv_key_anwenden(einstellungen: dict) -> None:
 
     Damit ist der Monats-Key ohne Rebuild/Neustart aktualisierbar
     (Einstellungen → System). Format wie entrypoint.sh: settings.conf.
+
+    Ergänzend statt überschreibend (Befund 25.07.2026): das Datenverzeichnis
+    ist jetzt persistent, und hier stand vorher ein open(..., "w") — das warf
+    vor JEDEM Rip alles andere aus der settings.conf, z. B. app_UpdateEnable
+    aus dem entrypoint. Beide Schreiber müssen gleich arbeiten, sonst kommt
+    der Fehler beim nächsten Rip still zurück.
     """
     key = (einstellungen.get("makemkvAppKey") or "").strip()
     if not key:
         return
-    ordner = os.path.expanduser("~/.MakeMKV")
+    pfad = os.path.join(makemkv_daten.DATEN_DIR, "settings.conf")
     try:
-        os.makedirs(ordner, exist_ok=True)
-        with open(os.path.join(ordner, "settings.conf"), "w") as f:
-            f.write(f'app_Key = "{key}"\n')
+        os.makedirs(makemkv_daten.DATEN_DIR, exist_ok=True)
+        try:
+            with open(pfad, encoding="utf-8", errors="replace") as f:
+                alt = f.read()
+        except OSError:
+            alt = ""
+        with open(pfad, "w", encoding="utf-8", newline="\n") as f:
+            f.write(makemkv_daten.settings_conf_zusammenfuehren(alt, key))
     except OSError as e:
         db.add_log("warning", "worker", f"MakeMKV-Key konnte nicht gesetzt werden: {e}")
 
 
+def _ordner_groesse(pfad: str) -> int:
+    """Belegter Platz eines Ordners in Bytes (0, wenn nicht lesbar)."""
+    summe = 0
+    for wurzel, _, dateien in os.walk(pfad):
+        for name in dateien:
+            try:
+                summe += os.path.getsize(os.path.join(wurzel, name))
+            except OSError:
+                pass
+    return summe
+
+
+def _original_aufheben(job_id: str, raw_dir: str, final_dir: str) -> None:
+    """Roh-Rip zusätzlich aufheben — darf den Job NIEMALS scheitern lassen.
+
+    Befund 25.07.2026 (Akira-UHD, echter Schaden): Hier stand ein nacktes
+    shutil.move(). Zwischen Arbeitsverzeichnis (/app/temp) und Ziel
+    (/app/media) scheitert os.rename mit EXDEV, shutil.move fällt auf Kopieren
+    zurück — eine 74-GB-Vollkopie auf dieselbe Platte, bis sie mit ENOSPC voll
+    war. Ergebnis: Platte 100 % voll, Worker-Container startete nicht mehr, und
+    der Job galt als FEHLGESCHLAGEN, obwohl die komprimierte Datei längst
+    fertig war. Der Nutzer sah nur „nichts da".
+
+    ## Warum hier NICHT vorhergesagt, sondern versucht wird
+
+    Die erste Fassung dieses Schutzes verglich `os.stat(...).st_dev` und
+    schloss aus gleichen Werten auf „reines Umhängen, kein Platz nötig". Am
+    25.07.2026 im Worker-Container nachgemessen — beides zugleich wahr:
+
+        st_dev /app/temp  = 2050
+        st_dev /app/media = 2050      → also identisch
+        os.rename(...)    → EXDEV, „Invalid cross-device link"
+
+    Der Kernel vergleicht bei rename() den **Mount**, nicht das Gerät. /app/temp
+    (Docker-Volume) und /app/media (Bind-Mount) sind zwei Mounts DERSELBEN
+    ext4-Partition. Die st_dev-Prüfung war deshalb wirkungslos: sie sah
+    „gleiches Dateisystem", übersprang die Platzprüfung, und shutil.move kopierte
+    doch. Der Schutz hätte genau den Schaden zugelassen, gegen den er gebaut war.
+
+    Also: erst rename VERSUCHEN. Klappt es, ist es umgehängt und fertig.
+    Kommt EXDEV, steht fest, dass kopiert werden müsste — und erst dann wird
+    der Platz geprüft. Das ist keine Vermutung mehr, sondern die Antwort des
+    Kernels.
+    """
+    ziel_original = os.path.join(final_dir, "original")
+    try:
+        # Der billige Weg zuerst — und er ist gleichzeitig der einzige
+        # verlässliche Test, ob überhaupt umgehängt werden kann.
+        try:
+            os.rename(raw_dir, ziel_original)
+            db.add_log(
+                "info", "worker",
+                f"Job {job_id}: Original behalten unter {ziel_original} (umgehängt, "
+                "kein zusätzlicher Platz nötig)",
+            )
+            return
+        except OSError as e:
+            if e.errno != errno.EXDEV:
+                raise  # etwas anderes ist schiefgelaufen → unten ehrlich melden
+
+        # Ab hier ist eine echte Kopie unvermeidlich. Jetzt lohnt die Platzfrage.
+        benoetigt = _ordner_groesse(raw_dir)
+        frei = _frei_bytes(final_dir)
+        if frei < benoetigt * 1.05:
+            db.add_log(
+                "warning", "worker",
+                f"Job {job_id}: Original NICHT aufgehoben — Ziel liegt auf einem "
+                f"anderen Mount, es müsste kopiert werden. Dafür wären "
+                f"{benoetigt / 1024**3:.1f} GB nötig, frei sind nur "
+                f"{frei / 1024**3:.1f} GB. Die Roh-Datei bleibt unter "
+                f"{raw_dir} liegen. Abhilfe: Arbeitsverzeichnis "
+                "(Einstellungen → Verarbeitung) auf dieselbe Freigabe legen "
+                "wie das Ziel — dann wird nur umgehängt statt kopiert."
+            )
+            return
+        shutil.move(raw_dir, ziel_original)
+        db.add_log("info", "worker", f"Job {job_id}: Original behalten unter {ziel_original}")
+    except OSError as e:
+        # Halb geschriebene Kopie wegräumen, sonst belegt sie für immer Platz.
+        shutil.rmtree(ziel_original, ignore_errors=True)
+        db.add_log(
+            "warning", "worker",
+            f"Job {job_id}: Original konnte nicht aufgehoben werden ({e}). "
+            f"Die komprimierte Datei ist fertig; die Roh-Datei bleibt unter {raw_dir}."
+        )
+
+
 def _abbruch_angefordert(job_id: str) -> bool:
     """Kooperativer Abbruch: hat der Nutzer über die API abgebrochen?"""
     return db.get_job_status(job_id) == "canceling"
@@ -344,6 +487,22 @@ def rip_disc(self, device_path: str, job_id: str, target_dir: str = None):
         )
         db.update_job(job_id, progress=progress)
 
+    # MakeMKV-Meldungen ins Log (Befund 25.07.2026): Bis dahin überlebte NUR
+    # die letzte Zeile ("Failed to open disc"), und die sagt nichts. Dass
+    # MakeMKV bei der UHD-Disc nicht einmal versucht, einen Schlüssel zu
+    # holen, war deshalb nur per Hand-Lauf im Container zu sehen.
+    # Gedrosselt, weil das UI global nur die letzten 200 Zeilen zeigt: jede
+    # Meldung höchstens einmal, insgesamt höchstens MAX_MELDUNGEN je Rip.
+    # Code 1003 ist MakeMKVs eigenes DEBUG-Rauschen (am 25.07. beobachtet).
+    MAX_MELDUNGEN = 40
+    gesehen = set()
+
+    def melde_makemkv(code: int, text: str):
+        if code == 1003 or len(gesehen) >= MAX_MELDUNGEN or text in gesehen:
+            return
+        gesehen.add(text)
+        db.add_log("info", "makemkv", f"Job {job_id}: {text[:300]}")
+
     einstellungen = db.get_settings()
     ist_video = disc_type in ("dvd", "bluray", "uhd")
     transcode_an = ist_video and einstellungen.get("transcodeEnabled", True)
@@ -382,7 +541,8 @@ def rip_disc(self, device_path: str, job_id: str, target_dir: str = None):
     # Geplantes Ziel sofort sichtbar machen (UI-Detail + retry-transcode)
     db.update_job(job_id, output_path=final_dir)
 
-    raw_dir = os.path.join(_arbeitsverzeichnis(einstellungen), job_id)
+    # meta["work_dir"] = die Wahl aus dem Rip-Dialog; leer = Setting/Default.
+    raw_dir = os.path.join(_arbeitsverzeichnis(einstellungen, meta.get("work_dir")), job_id)
 
     # Platz-Check VOR dem Rip: Disc-Größe ist per ioctl bekannt — eine volle
     # Platte nach 40 GB wäre der teuerste Fehlschlag (4K-UHD: bis 100 GB roh).
@@ -402,7 +562,10 @@ def rip_disc(self, device_path: str, job_id: str, target_dir: str = None):
             return ergebnis
 
     if disc_type == "cd":
-        ergebnis = rip_cd(device_path, job_id, progress_cb=fortschritt, output_dir=final_dir)
+        ergebnis = rip_cd(
+            device_path, job_id, progress_cb=fortschritt, output_dir=final_dir,
+            auswerfen=bool(einstellungen.get("autoEject", True)),
+        )
     elif transcode_an:
         # Roh-Rip ins Arbeitsverzeichnis (wird nach erfolgreicher Kompression gelöscht)
         ergebnis = rip_video(
@@ -411,6 +574,7 @@ def rip_disc(self, device_path: str, job_id: str, target_dir: str = None):
             output_dir=raw_dir,
             nur_hauptfilm=nur_hauptfilm,
             titel_liste=titel_liste,
+            log_cb=melde_makemkv,
         )
     else:
         ergebnis = rip_video(
@@ -418,26 +582,44 @@ def rip_disc(self, device_path: str, job_id: str, target_dir: str = None):
             progress_cb=fortschritt, output_dir=final_dir,
             nur_hauptfilm=nur_hauptfilm,
             titel_liste=titel_liste,
+            log_cb=melde_makemkv,
         )
 
-    # UHD-Fehler in Klartext übersetzen — "Failed to open disc" allein hilft
-    # niemandem. Zwei bekannte Ursachen (Befunde 24.07., Summer-Wars-UHD):
-    if ergebnis.get("status") == "error" and disc_type == "uhd":
+    # MakeMKV-Fehler in Klartext übersetzen — "Failed to open disc" allein
+    # hilft niemandem.
+    if ergebnis.get("status") == "error":
         fehler_text = ergebnis.get("error") or ""
         if "volume key is unknown" in fehler_text:
-            # LibreDrive lief bereits — MakeMKV kennt nur den Disc-Schlüssel
-            # nicht: Version zu alt ODER Disc neuer als die Key-Datenbank.
+            # Befund 25.07.2026, auf BEIDEN Maschinen gemessen: Laufwerk und
+            # MakeMKV sind in Ordnung. makemkvcon unter Linux ruft die
+            # Disc-Schlüssel schlicht nie ab — die Windows-Version tut es
+            # (Meldung 3338). Hier stand vorher erst "Disc zu neu" und danach
+            # "der Schlüssel-Kanal ist tot"; beides war falsch und hat in die
+            # Irre geschickt. Herleitung im Kopf von makemkv_daten.py.
+            speicher = makemkv_daten.schluesselspeicher_status()
+            anzahl = speicher.get("schluessel", 0)
             ergebnis["error"] += (
-                " — Klartext: Das Laufwerk liest die Disc (LibreDrive OK), "
-                "aber MakeMKV kennt den Schlüssel dieser Disc nicht. Erst "
-                "prüfen: MakeMKV aktuell? (Einstellungen → System; Update = "
-                "Image-Rebuild). Ist es aktuell, ist die Disc neuer als die "
-                "Schlüssel-Datenbank — MakeMKV hat einen AACS-Dump unter "
-                "/root/.MakeMKV/ im Worker gespeichert; im MakeMKV-Forum "
-                "(Bereich 'Ultra HD Blu-ray') einreichen, mit einem der "
-                "nächsten Updates ist die Disc dann rippbar."
+                " — Klartext: Laufwerk und Rippy sind in Ordnung, MakeMKV "
+                "liest die Disc. Es fehlt nur der Schlüssel dieser Pressung. "
+                "Der Grund: makemkvcon holt Schlüssel unter Linux nie selbst "
+                "nach — die Windows-Version schon. "
+                + (
+                    "Dieser Worker kennt aktuell GAR KEINEN Disc-Schlüssel. "
+                    if not anzahl
+                    else f"Dieser Worker kennt {anzahl} Disc-Schlüssel, "
+                    "diese Pressung ist nicht dabei. "
+                )
+                + "Abhilfe: MakeMKV auf einem Windows-PC installieren, die "
+                "Disc dort einmal öffnen, dann die Datei _private_data.tar "
+                "aus dem MakeMKV-Datenverzeichnis unter Einstellungen → "
+                "System hochladen. Wirkt ab dem nächsten Rip. Klappt auch "
+                "das nicht, kennt MakeMKV die Pressung selbst nicht — dann "
+                "hilft nur eine KEYDB.cfg (ebenfalls dort hochladbar) oder "
+                "das Einreichen des AACS-Dumps im MakeMKV-Forum, Bereich "
+                "'Ultra HD Blu-ray'. Der Dump steht unter Einstellungen → "
+                "System zum Download bereit."
             )
-        elif "Failed to open disc" in fehler_text:
+        elif disc_type == "uhd" and "Failed to open disc" in fehler_text:
             ergebnis["error"] += (
                 " — 4K-UHD erkannt: Das Laufwerk kann UHD-Discs vermutlich "
                 "nicht entschlüsseln. Dafür ist eine LibreDrive-Firmware nötig "
@@ -445,6 +627,23 @@ def rip_disc(self, device_path: str, job_id: str, target_dir: str = None):
                 "Normale BD/DVD gehen weiterhin."
             )
 
+    # Automatischer Auswurf. Die Disc ist nach dem Rip nicht mehr nötig — die
+    # Kompression arbeitet auf der Datei, nicht am Laufwerk.
+    #
+    # Befund 25.07.2026: Die Einstellung („Disc nach erfolgreichem Ripping
+    # automatisch auswerfen", Standard ein) wurde von NIEMANDEM gelesen. Bei
+    # DVD/Blu-ray warf Rippy deshalb nie aus, bei Audio-CD dagegen immer, weil
+    # abcde `-x` fest verdrahtet bekam. Jetzt entscheidet die Einstellung beides.
+    if ergebnis.get("status") == "success" and ist_video and einstellungen.get("autoEject", True):
+        if wirf_disc_aus(device_path):
+            db.add_log("info", "worker", f"Job {job_id}: Disc ausgeworfen")
+        else:
+            db.add_log(
+                "warning", "worker",
+                f"Job {job_id}: Disc konnte nicht ausgeworfen werden ({device_path}) — "
+                "der Rip ist davon unberührt.",
+            )
+
     if ergebnis.get("status") == "success" and transcode_an:
         # Kompression als eigener Task — an den im Rip-Dialog GEWÄHLTEN Worker
         # (worker_direct), sonst an die geteilte transcode-Queue (irgendein
@@ -518,18 +717,47 @@ def transcode_files(self, job_id: str, raw_dir: str, final_dir: str):
         return ergebnis
 
     einstellungen = db.get_settings()
-    preset = einstellungen.get("transcodePreset") or DEFAULT_HB_PRESET
+    # Preset nach Disc-Typ (Befund 25.07.2026): vorher lief JEDE Quelle durch
+    # dasselbe Preset — eine 4K-UHD wurde damit auf 1080p heruntergerechnet.
+    job = db.get_job(job_id) or {}
+    disc_type = job.get("disc_type") or ""
+    preset = preset_fuer(disc_type, einstellungen)
     original_behalten = einstellungen.get("keepOriginal", False)
 
     os.makedirs(final_dir, exist_ok=True)
     db.update_job(job_id, status="transcoding", progress=0, error=None)
     db.add_log(
         "info", "worker",
-        f"Job {job_id}: Kompression gestartet ({len(quellen)} Datei(en), Preset '{preset}')",
+        f"Job {job_id}: Kompression gestartet ({len(quellen)} Datei(en), "
+        f"Disc-Typ '{disc_type or 'unbekannt'}', Preset '{preset}')",
     )
 
     anzahl = len(quellen)
     letzter = [-1]
+    letzte_abbruchpruefung = [0.0]
+
+    def abbruch_pruefen():
+        """Zeitgesteuert prüfen, ob der Nutzer abgebrochen hat. Wirft RipAbbruch.
+
+        Befund 25.07.2026 (Commander, am laufenden Akira-Job beobachtet): Der
+        Abbruch wurde NUR in `datei_fortschritt` geprüft — und diese Closure
+        stieg oben sofort wieder aus, wenn sich die Prozentzahl nicht geändert
+        hatte. Bei einem 4K-Encode, der pro Prozent eine halbe Stunde braucht,
+        sah „Abbrechen" entsprechend lange wirkungslos aus (gemessen: 3,4 min
+        zwischen Anforderung 18:30:17 und Bestätigung 18:33:38 — bei noch
+        langsamerem Fortschritt entsprechend mehr).
+
+        Deshalb hängt die Prüfung jetzt an der Zeit statt am Fortschritt und
+        läuft bei JEDER Ausgabezeile von HandBrake — auch während des
+        Scan-Durchlaufs, der überhaupt keine Encode-Prozente liefert.
+        """
+        jetzt = time.monotonic()
+        if jetzt - letzte_abbruchpruefung[0] < ABBRUCH_INTERVALL_SEKUNDEN:
+            return
+        letzte_abbruchpruefung[0] = jetzt
+        if _abbruch_angefordert(job_id):
+            raise RipAbbruch()
+
     for index, quelle in enumerate(quellen):
         ziel = os.path.join(final_dir, os.path.basename(quelle))
 
@@ -538,11 +766,13 @@ def transcode_files(self, job_id: str, raw_dir: str, final_dir: str):
             if gesamt == letzter[0]:
                 return
             letzter[0] = gesamt
-            if _abbruch_angefordert(job_id):
-                raise RipAbbruch()
             db.update_job(job_id, progress=min(99, gesamt))
 
-        hb = run_handbrake(quelle, ziel, preset=preset, progress_cb=datei_fortschritt)
+        hb = run_handbrake(
+            quelle, ziel, preset=preset,
+            progress_cb=datei_fortschritt,
+            abbruch_cb=abbruch_pruefen,
+        )
         if hb.get("status") == "cancelled":
             _job_abschliessen(job_id, hb)
             return hb
@@ -558,9 +788,7 @@ def transcode_files(self, job_id: str, raw_dir: str, final_dir: str):
             return ergebnis
 
     if original_behalten:
-        ziel_original = os.path.join(final_dir, "original")
-        shutil.move(raw_dir, ziel_original)
-        db.add_log("info", "worker", f"Job {job_id}: Original behalten unter {ziel_original}")
+        _original_aufheben(job_id, raw_dir, final_dir)
     else:
         shutil.rmtree(raw_dir, ignore_errors=True)
 

docker/worker/test_caps.py

@@ -0,0 +1,115 @@
+"""Tests der Fähigkeiten-Erkennung — reine Funktionen, keine Infrastruktur.
+
+Die Testdaten sind ECHTE Ausgaben, am 25.07.2026 im Worker-Image der Rippy-VM
+abgenommen (AGENTS Regel D). Erfundene Formate hätten hier keinen Wert: genau
+daran ist die Erkennung vorher gescheitert.
+"""
+
+import caps
+
+# Wörtlich aus `docker exec rippy-worker-1 HandBrakeCLI --help` (HandBrake im
+# Worker-Image, 25.07.2026). Bemerkenswert: KEIN Hardware-Encoder dabei.
+HB_HILFE_ECHT = """
+   -Z, --preset <string>   Select preset by name
+   -e, --encoder <string>  Select video encoder:
+                               svt_av1
+                               svt_av1_10bit
+                               x264
+                               x264_10bit
+                               x265
+                               x265_10bit
+                               x265_12bit
+                               mpeg4
+                               mpeg2
+                               VP8
+                               VP9
+                               VP9_10bit
+                               theora
+       --encoder-preset <string>
+                           Adjust video encoding settings
+"""
+
+# Wie dieselbe Stelle auf einer Maschine MIT Hardware-Encodern aussieht
+# (HandBrake-Windows-Build; Struktur identisch, nur mehr Namen).
+HB_HILFE_MIT_HARDWARE = """
+   -e, --encoder <string>  Select video encoder:
+                               x264
+                               x265
+                               nvenc_h264
+                               nvenc_h265
+                               qsv_h264
+                               qsv_h265
+       --encoder-preset <string>
+"""
+
+
+def test_encoder_liste_wird_aus_echter_hilfe_gelesen():
+    encoder = caps.parse_encoder_liste(HB_HILFE_ECHT)
+    assert encoder == [
+        "svt_av1", "svt_av1_10bit",
+        "x264", "x264_10bit",
+        "x265", "x265_10bit", "x265_12bit",
+        "mpeg4", "mpeg2", "VP8", "VP9", "VP9_10bit", "theora",
+    ]
+    # Der Block endet an der nächsten Option — sie darf nicht mitgelesen werden
+    assert not any("encoder-preset" in e for e in encoder)
+    assert not any(e.startswith("-") for e in encoder)
+
+
+def test_encoder_liste_ohne_handbrake_ist_leer():
+    assert caps.parse_encoder_liste("") == []
+    assert caps.parse_encoder_liste(None) == []
+    assert caps.parse_encoder_liste("irgendein Text ohne Encoder-Abschnitt") == []
+
+
+def test_ohne_handbrake_keine_encoder():
+    """Der wichtigste Fall: vorher standen cpu-x264/cpu-x265 fest verdrahtet in
+    der Liste. Ein Rip-Worker ohne HandBrake behauptete damit, komprimieren zu
+    können — und jeder Transcode dort endete sofort mit 'nicht installiert'."""
+    assert caps.leite_backends_ab([], dri_da=True, nvidia_da=True) == []
+
+
+def test_backends_aus_echter_liste():
+    encoder = caps.parse_encoder_liste(HB_HILFE_ECHT)
+    # Kein /dev/dri, kein NVIDIA — und HandBrake kann hier ohnehin keine Hardware
+    assert caps.leite_backends_ab(encoder, dri_da=False, nvidia_da=False) == [
+        "cpu-x264", "cpu-x265", "cpu-av1",
+    ]
+
+
+def test_hardware_nur_wenn_geraet_UND_handbrake_es_kann():
+    """Befund 25.07.2026: Vorher genügte /dev/dri, um 'vaapi' zu melden. Das
+    Worker-Image kann laut eigener Auskunft aber gar keinen Hardware-Encoder —
+    Rippy hätte VAAPI versprochen und wäre beim Encodieren gescheitert."""
+    ohne_hw = caps.parse_encoder_liste(HB_HILFE_ECHT)
+    assert "vaapi" not in caps.leite_backends_ab(ohne_hw, dri_da=True, nvidia_da=True)
+    assert "nvenc" not in caps.leite_backends_ab(ohne_hw, dri_da=True, nvidia_da=True)
+
+    mit_hw = caps.parse_encoder_liste(HB_HILFE_MIT_HARDWARE)
+    # Gerät fehlt → trotz Können kein Hardware-Backend
+    assert caps.leite_backends_ab(mit_hw, dri_da=False, nvidia_da=False) == [
+        "cpu-x264", "cpu-x265",
+    ]
+    # Beides da → beides gemeldet
+    beides = caps.leite_backends_ab(mit_hw, dri_da=True, nvidia_da=True)
+    assert "vaapi" in beides   # qsv_* vorhanden
+    assert "nvenc" in beides
+
+
+def test_simd_stufe_erkennt_die_hoechste():
+    assert caps.beste_simd("fpu vme de sse4_2 avx avx2") == "avx2"
+    assert caps.beste_simd("sse4_2 avx avx2 avx512f") == "avx512f"
+    assert caps.beste_simd("fpu vme de pse tsc sse4_2") == "sse4_2"
+    assert caps.beste_simd("") == "unbekannt"
+    assert caps.beste_simd(None) == "unbekannt"
+
+
+def test_simd_stufe_der_rippy_vm_ist_sse4_2():
+    """Echt gemessen auf der Rippy-VM (25.07.2026): generisches QEMU-CPU-Modell,
+    `grep -c avx2 /proc/cpuinfo` = 0. Genau das macht Software-4K dort so lahm."""
+    flags_vm = (
+        "fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 "
+        "clflush mmx fxsr sse sse2 syscall nx lm rep_good nopl cpuid "
+        "pni cx16 sse4_1 sse4_2 x2apic popcnt aes hypervisor lahf_lm"
+    )
+    assert caps.beste_simd(flags_vm) == "sse4_2"

docker/worker/test_makemkv_daten_worker.py

@@ -0,0 +1,244 @@
+"""Tests fuer makemkv_daten.py: die reinen Helfer rund um das MakeMKV-Datenverzeichnis.
+
+WARUM ES DIESE TESTS GIBT (Befund 25.07.2026, live im Worker nachgemessen):
+Eine 4K-UHD-Disc (Akira UHD, MKB v76) scheiterte mit "The volume key is unknown
+for this disc", obwohl Laufwerk und MakeMKV in Ordnung waren. Der einzige heute
+noch funktionierende Weg ist eine selbst mitgebrachte KEYDB.cfg im
+Datenverzeichnis. Damit haengt einiges an diesen kleinen Funktionen: erkennen wir
+die Datei falsch, meldet das UI "alles gut", waehrend MakeMKV weiter scheitert.
+
+Getestet wird nur, was ohne Postgres, Redis und ohne Laufwerk laeuft — also die
+puren Funktionen mit echten Beispieldaten. Zeilenformat der KEYDB.cfg laut
+libaacs (AGENTS Regel D, externe Schnittstellen nie aus dem Kopf):
+https://github.com/ShiftMediaProject/libaacs/blob/master/KEYDB.cfg
+
+WARUM DER DATEINAME "_worker" HINTEN DRANHAENGT (25.07.2026): makemkv_daten.py
+ist eine Zwillingsdatei, es gibt sie unter docker/api/ UND docker/worker/, und
+beide Seiten haben Tests. Da im Projekt keine __init__.py liegen, importiert
+pytest Testdateien unter ihrem blossen Dateinamen — zwei Dateien namens
+test_makemkv_daten.py brechen deshalb die Sammelphase ab ("import file
+mismatch") und faerben die ganze Ampel rot. Nicht zurueckbenennen.
+"""
+
+import hashlib
+import importlib.util
+import os
+
+# WICHTIG (Prüfbefund 25.07.2026): Ein schlichtes "from makemkv_daten import ..."
+# lädt bei "pytest -q" vom Repo-Wurzelverzeichnis NICHT diese Datei, sondern die
+# API-Kopie — docker/api wird zuerst gesammelt, und jeder weitere Import trifft
+# nur noch den sys.modules-Cache. Die Tests hier hätten den Worker-Zwilling also
+# nie angefasst und eine Abweichung wäre grün durchgelaufen. Deshalb wird er
+# ausdrücklich über seinen Pfad geladen.
+_HIER = os.path.dirname(os.path.abspath(__file__))
+_WORKER_MODUL = os.path.join(_HIER, "makemkv_daten.py")
+_API_MODUL = os.path.abspath(os.path.join(_HIER, "..", "api", "makemkv_daten.py"))
+
+_spec = importlib.util.spec_from_file_location("makemkv_daten_worker_kopie", _WORKER_MODUL)
+_modul = importlib.util.module_from_spec(_spec)
+_spec.loader.exec_module(_modul)
+
+ist_aacs_dump = _modul.ist_aacs_dump
+keydb_pruefen = _modul.keydb_pruefen
+settings_conf_zusammenfuehren = _modul.settings_conf_zusammenfuehren
+zaehle_disc_eintraege = _modul.zaehle_disc_eintraege
+private_data_pruefen = _modul.private_data_pruefen
+zaehle_schluessel = _modul.zaehle_schluessel
+
+
+def _tar_mit(namen):
+    """Baut ein tar-Archiv im Speicher — so sieht MakeMKVs Schluesselspeicher aus.
+
+    Echte Eintragsnamen aus dem Speicher der Windows-Installation vom
+    25.07.2026: hkd_<8 Hex>.bin fuer die Schluessel, dazu Index-Dateien.
+    """
+    import io
+    import tarfile
+
+    puffer = io.BytesIO()
+    with tarfile.open(fileobj=puffer, mode="w") as archiv:
+        for name in namen:
+            eintrag = tarfile.TarInfo(name)
+            eintrag.size = 3
+            archiv.addfile(eintrag, io.BytesIO(b"abc"))
+    return puffer.getvalue()
+
+
+def test_zaehle_schluessel_zaehlt_nur_hkd_eintraege():
+    # Nur hkd_*.bin sind Disc-Schluessel. Index- und sdf-Dateien gehoeren zum
+    # Speicher dazu, sind aber keine Schluessel — sonst meldete das UI
+    # "1 Schluessel vorhanden" fuer einen komplett leeren Vorrat.
+    voll = _tar_mit([
+        "hkd_00000059.bin",
+        "hkd_0000005a.bin",
+        "sdf_000000a6.bin",
+        "--index-A2E950B3C3FC57DA9CB856DCAFBA5275F40423DB.bin",
+    ])
+    assert zaehle_schluessel(voll) == 2
+
+
+def test_zaehle_schluessel_leerer_speicher_ist_null():
+    # Genau dieser Zustand lag am 25.07.2026 auf der VM vor: ein Archiv mit
+    # ausschliesslich der Index-Datei. Jede unbekannte UHD-Disc scheitert dann.
+    leer = _tar_mit(["--index-4EF73C3560D489497ACE763962A7F07A4A1545C4.bin"])
+    assert zaehle_schluessel(leer) == 0
+
+
+def test_zaehle_schluessel_bei_muell_kein_absturz():
+    # Darf niemals werfen — die Zahl landet im Worker-Herzschlag.
+    assert zaehle_schluessel(b"") == 0
+    assert zaehle_schluessel(b"das ist kein tar") == 0
+
+
+def test_private_data_pruefen_nimmt_echten_speicher_an():
+    assert private_data_pruefen(_tar_mit(["hkd_00000059.bin"])) == ""
+
+
+def test_private_data_pruefen_lehnt_leere_und_falsche_dateien_ab():
+    assert "leer" in private_data_pruefen(b"")
+    assert "tar-Archiv" in private_data_pruefen(b"<html>Fehlerseite</html>")
+
+
+def test_private_data_pruefen_lehnt_speicher_ohne_schluessel_ab():
+    # Der teuerste Bedienfehler: den Speicher einer Installation hochladen,
+    # die selbst noch nie Schluessel geholt hat. Ohne diese Pruefung aendert
+    # sich nichts und niemand versteht, warum.
+    leer = _tar_mit(["--index-4EF73C3560D489497ACE763962A7F07A4A1545C4.bin"])
+    assert "kein einziger Schluessel" in private_data_pruefen(leer)
+
+
+def test_zwillinge_sind_byteweise_identisch():
+    """docker/api/makemkv_daten.py MUSS dieselbe Datei sein wie diese hier.
+
+    Das Modul existiert bewusst doppelt — es gibt in diesem Projekt kein
+    gemeinsames Paket für API und Worker (gleiche Lage wie bei db.py). Genau
+    deshalb braucht es einen Wächter: laufen die beiden auseinander, zeigt das
+    UI etwas anderes an, als der rippende Worker tatsächlich sieht, und es
+    fällt niemandem auf. Dieser Test ist die einzige Stelle, die das
+    mechanisch prüft.
+    """
+    with open(_WORKER_MODUL, "rb") as datei:
+        worker = hashlib.sha256(datei.read()).hexdigest()
+    with open(_API_MODUL, "rb") as datei:
+        api = hashlib.sha256(datei.read()).hexdigest()
+    assert worker == api, (
+        "docker/worker/makemkv_daten.py und docker/api/makemkv_daten.py sind "
+        "auseinandergelaufen - Aenderungen immer in BEIDE Dateien uebernehmen."
+    )
+
+# Eine kleine, aber echte KEYDB.cfg im libaacs-Format: Kommentarkopf, eine
+# Disc-Zeile MIT 0x-Praefix, eine OHNE, dazu ein Fortsetzungsfeld und eine
+# Leerzeile. Erwartete Zahl der Eintraege: 2.
+BEISPIEL_KEYDB = """; KEYDB.cfg
+; Kommentarzeilen beginnen mit einem Semikolon
+
+0x8F4E2C1A9B7D3E5F0A6C8B2D4E1F3A5C7B9D0E2F = AKIRA
+| V | 0123456789ABCDEF0123456789ABCDEF
+
+A1B2C3D4E5F60718293A4B5C6D7E8F90A1B2C3D4 = BLADE RUNNER 2049
+"""
+
+
+def test_zaehle_disc_eintraege_zaehlt_nur_echte_disc_zeilen():
+    """Nur Zeilen mit 40 Hex-Zeichen und Gleichheitszeichen sind Eintraege.
+
+    Kommentare, Leerzeilen und Fortsetzungsfelder duerfen nicht mitzaehlen —
+    sonst meldet das UI bei einer reinen Kommentardatei stolz "42 Eintraege".
+    """
+    assert zaehle_disc_eintraege(BEISPIEL_KEYDB) == 2
+
+
+def test_zaehle_disc_eintraege_ignoriert_kommentare_und_leerzeilen():
+    # Eine Datei ganz ohne Disc-Zeile hat null Eintraege, nicht drei.
+    nur_beiwerk = "; nur ein Kommentar\n\n| V | 0123456789ABCDEF0123456789ABCDEF\n"
+    assert zaehle_disc_eintraege(nur_beiwerk) == 0
+
+
+def test_zaehle_disc_eintraege_ignoriert_zu_kurze_kennung():
+    """39 Hex-Zeichen sind keine Disc-Kennung.
+
+    Genau so sieht eine beim Kopieren verstuemmelte Datei aus — die darf nicht
+    als gueltig durchgehen, sonst sucht der Commander den Fehler beim Laufwerk.
+    """
+    zu_kurz = "A1B2C3D4E5F60718293A4B5C6D7E8F90A1B2C3D = KAPUTT\n"
+    assert zaehle_disc_eintraege(zu_kurz) == 0
+
+
+def test_keydb_pruefen_meldet_leere_datei():
+    # Haeufigster Fehlgriff: das Textfeld war leer, es wird trotzdem gespeichert.
+    assert keydb_pruefen("") != ""
+    assert keydb_pruefen("   \n\n  ") != ""
+
+
+def test_keydb_pruefen_erkennt_html_fehlerseite():
+    """Der zweithaeufigste Fehlgriff: der Download lieferte eine HTML-Seite.
+
+    MakeMKV wuerde die Datei still ignorieren und weiter "volume key is unknown"
+    melden — deshalb muss der Fehler schon beim Hochladen sichtbar werden.
+    """
+    html = "<!DOCTYPE html>\n<html><body><h1>404 Not Found</h1></body></html>\n"
+    meldung = keydb_pruefen(html)
+    assert meldung != ""
+    assert "HTML" in meldung
+
+
+def test_keydb_pruefen_meldet_text_ohne_disc_zeile():
+    # Irgendein Text (hier: eine README) ist keine KEYDB.cfg.
+    meldung = keydb_pruefen("Diese Datei enthaelt keine Schluessel, nur Prosa.\n")
+    assert meldung != ""
+
+
+def test_keydb_pruefen_akzeptiert_gueltigen_inhalt():
+    # Leerer Rueckgabewert heisst laut Vertrag: alles in Ordnung.
+    assert keydb_pruefen(BEISPIEL_KEYDB) == ""
+
+
+def test_ist_aacs_dump_akzeptiert_echten_namen():
+    """Name aus der Praxis: so legt MakeMKV den Dump laut Meldung 3332 ab
+    (am 25.07.2026 im Worker so beobachtet)."""
+    assert ist_aacs_dump("MKB20_v76_UHD_AKIRA_C02B.tgz") is True
+
+
+def test_ist_aacs_dump_lehnt_pfad_tricks_und_fremde_dateien_ab():
+    """Der Download-Endpunkt haengt den Namen an das Datenverzeichnis an —
+    ohne diese Pruefung koennte man sich damit aus dem Verzeichnis heraus
+    lesen. Versteckte Dateien und Nicht-Dumps sind ebenfalls nichts fuer die
+    Liste."""
+    assert ist_aacs_dump("../ausbruch.tgz") is False
+    assert ist_aacs_dump(".versteckt.tgz") is False
+    assert ist_aacs_dump("irgendwas.txt") is False
+    assert ist_aacs_dump("..\\windows\\ausbruch.tgz") is False
+
+
+def test_settings_conf_ersetzt_key_und_behaelt_den_rest():
+    """DIE Regression, um die es geht: bis zum 25.07.2026 haben entrypoint.sh
+    und tasks.py die settings.conf komplett ueberschrieben. Mit dem jetzt
+    persistenten Datenverzeichnis waere damit bei jedem Containerstart und vor
+    jedem Rip alles andere weg — allen voran app_UpdateEnable."""
+    alt = 'app_Key = "T-alterSchluessel"\napp_UpdateEnable = "1"\napp_DefaultSelectionString = "+sel:all"\n'
+    neu = settings_conf_zusammenfuehren(alt, "T-neuerSchluessel")
+    assert 'app_Key = "T-neuerSchluessel"' in neu
+    assert 'app_Key = "T-alterSchluessel"' not in neu
+    assert 'app_UpdateEnable = "1"' in neu
+    assert 'app_DefaultSelectionString = "+sel:all"' in neu
+    # Genau EINE app_Key-Zeile, sonst gewinnt am Ende die falsche.
+    assert neu.count("app_Key") == 1
+
+
+def test_settings_conf_leerer_key_entfernt_die_zeile():
+    # Ein bewusst geleerter Key darf nicht heimlich weiterwirken.
+    alt = 'app_Key = "T-alterSchluessel"\napp_UpdateEnable = "1"\n'
+    neu = settings_conf_zusammenfuehren(alt, "")
+    assert "app_Key" not in neu
+    assert 'app_UpdateEnable = "1"' in neu
+
+
+def test_settings_conf_aus_dem_nichts_ergibt_saubere_datei():
+    """Erststart: die Datei gibt es noch gar nicht. Der abschliessende
+    Zeilenumbruch ist Absicht — MakeMKV liest die Datei zeilenweise."""
+    assert settings_conf_zusammenfuehren("", "T-neuerSchluessel") == 'app_Key = "T-neuerSchluessel"\n'
+
+
+def test_settings_conf_ohne_key_und_ohne_inhalt_bleibt_leer():
+    # Kein Inhalt, kein Key: keine Datei mit einer einsamen Leerzeile erzeugen.
+    assert settings_conf_zusammenfuehren("", "") == ""

docker/worker/test_medien.py

@@ -112,3 +112,64 @@ def test_pfad_lokal_uebersetzt_fuer_windows_worker():
     assert pfad_lokal("/app/media/movies/Film (2020)", mapping) == "Z:\\media\\movies\\Film (2020)"
     assert pfad_lokal("/woanders/x", mapping) == "/woanders/x"
     assert pfad_lokal("/app/temp/raw/abc", "") == "/app/temp/raw/abc"
+
+
+# Die beiden frueheren Tests zu _original_aufheben sind nach
+# test_original_aufheben.py gewandert und dort erweitert. Sie pruefen jetzt das
+# richtige Kriterium: Vorher taeuschten sie per gefaelschtem os.stat
+# „verschiedene Dateisysteme" vor — genau die Annahme, an der der Schutz in der
+# Praxis scheiterte (st_dev war identisch, os.rename trotzdem EXDEV).
+
+
+def test_arbeitsverzeichnis_wahl_des_rips_schlaegt_die_einstellung():
+    """Pro Rip waehlbar (Commander 25.07.2026), Einstellung bleibt Standard.
+
+    Reihenfolge: Wahl dieses Rips -> Setting -> Container-Default. Der
+    Setting-Wert ist genau der, der bei Vollautomatik-Rips greift, weil dort
+    niemand gefragt wird.
+    """
+    import tasks
+
+    einst = {"workDir": "/app/media/movies"}
+    assert tasks._arbeitsverzeichnis(einst, "/app/media/rippy") == "/app/media/rippy"
+    assert tasks._arbeitsverzeichnis(einst) == "/app/media/movies"
+    assert tasks._arbeitsverzeichnis({}) == tasks.RAW_DIR
+    # Ausbruchsversuche und Pfade ausserhalb /app/media fallen durch
+    assert tasks._arbeitsverzeichnis({}, "/etc") == tasks.RAW_DIR
+    assert tasks._arbeitsverzeichnis({}, "/app/media/../etc") == tasks.RAW_DIR
+    # Leere Wahl faellt sauber auf die Einstellung zurueck
+    assert tasks._arbeitsverzeichnis(einst, "   ") == "/app/media/movies"
+
+
+def test_unter_wurzel_faellt_nicht_auf_praefix_namen_herein():
+    """Befund 25.07.2026: Elf Stellen prueften mit nacktem startswith().
+    „/app/media-boese/x" beginnt mit „/app/media", liegt aber ausserhalb."""
+    import tasks
+
+    assert tasks.unter_wurzel("/app/media", "/app/media") is True
+    assert tasks.unter_wurzel("/app/media/movies", "/app/media") is True
+    assert tasks.unter_wurzel("/app/media/movies/Film (2020)", "/app/media") is True
+    # Der Fall, den startswith() durchgelassen haette
+    assert tasks.unter_wurzel("/app/media-boese/x", "/app/media") is False
+    assert tasks.unter_wurzel("/app/mediaX", "/app/media") is False
+    assert tasks.unter_wurzel("/etc/passwd", "/app/media") is False
+    assert tasks.unter_wurzel("", "/app/media") is False
+    assert tasks.unter_wurzel("/app/media", "") is False
+    # Wurzel mit Schrägstrich am Ende darf nichts aendern
+    assert tasks.unter_wurzel("/app/media/movies", "/app/media/") is True
+
+
+def test_zielbasis_lehnt_praefix_ausbruch_ab():
+    import tasks
+
+    assert tasks._zielbasis("/app/media/movies", "bluray") == "/app/media/movies"
+    # Ausbruch per Praefix-Namen faellt auf den Standard zurueck
+    assert tasks._zielbasis("/app/media-boese", "bluray") != "/app/media-boese"
+    assert tasks._zielbasis("/etc", "bluray") != "/etc"
+
+
+def test_arbeitsverzeichnis_lehnt_praefix_ausbruch_ab():
+    import tasks
+
+    assert tasks._arbeitsverzeichnis({}, "/app/media-boese") == tasks.RAW_DIR
+    assert tasks._arbeitsverzeichnis({"workDir": "/app/mediaX"}) == tasks.RAW_DIR

docker/worker/test_original_aufheben.py

@@ -0,0 +1,124 @@
+"""Tests fuer _original_aufheben — der Pfad, der am 25.07.2026 die Platte fuellte.
+
+Der Kern: Es wird NICHT vorhergesagt, ob umgehaengt werden kann, sondern
+os.rename versucht. Die alte Fassung verglich st_dev und lag damit falsch —
+auf der Rippy-VM sind st_dev von /app/temp und /app/media identisch (2050),
+os.rename scheitert zwischen ihnen trotzdem mit EXDEV, weil der Kernel den
+Mount vergleicht und nicht das Geraet. Die Platzpruefung wurde deshalb
+uebersprungen und shutil.move kopierte 75 GB bei 37 GB frei.
+"""
+
+import errno
+import os
+
+import pytest
+
+import tasks
+
+
+class FakeDb:
+    """Faengt nur die Log-Zeilen ab — mehr braucht _original_aufheben nicht."""
+
+    def __init__(self):
+        self.logs = []
+
+    def add_log(self, level, source, message):
+        self.logs.append((level, message))
+
+    def meldungen(self):
+        return " ".join(m for _, m in self.logs)
+
+
+@pytest.fixture
+def fake_db(monkeypatch):
+    ersatz = FakeDb()
+    monkeypatch.setattr(tasks, "db", ersatz)
+    return ersatz
+
+
+def _lege_rohdaten_an(tmp_path, groesse=2048):
+    raw = tmp_path / "raw" / "job-1"
+    raw.mkdir(parents=True)
+    (raw / "title_t00.mkv").write_bytes(b"x" * groesse)
+    final = tmp_path / "media" / "Film (2020)"
+    final.mkdir(parents=True)
+    return str(raw), str(final)
+
+
+def test_umhaengen_wenn_derselbe_mount(tmp_path, fake_db):
+    """Der gute Fall: rename klappt, nichts wird kopiert, kein Platz noetig."""
+    raw, final = _lege_rohdaten_an(tmp_path)
+
+    tasks._original_aufheben("job-1", raw, final)
+
+    assert os.path.isdir(os.path.join(final, "original"))
+    assert os.path.isfile(os.path.join(final, "original", "title_t00.mkv"))
+    assert not os.path.exists(raw)
+    assert "umgehängt" in fake_db.meldungen()
+
+
+def test_bei_exdev_und_zu_wenig_platz_wird_nur_gewarnt(tmp_path, fake_db, monkeypatch):
+    """Der Fall, der die Platte fuellte: rename geht nicht, Platz reicht nicht.
+
+    Vorher lief hier eine Vollkopie an, weil die st_dev-Pruefung „gleiches
+    Dateisystem" meldete und die Platzpruefung deshalb ausblieb.
+    """
+    raw, final = _lege_rohdaten_an(tmp_path)
+
+    def kein_rename(*_a, **_k):
+        raise OSError(errno.EXDEV, "Invalid cross-device link")
+
+    monkeypatch.setattr(tasks.os, "rename", kein_rename)
+    monkeypatch.setattr(tasks, "_frei_bytes", lambda _p: 1024)  # weniger als die Rohdaten
+
+    tasks._original_aufheben("job-1", raw, final)
+
+    # Rohdaten bleiben unangetastet liegen, es wurde NICHTS kopiert
+    assert os.path.isfile(os.path.join(raw, "title_t00.mkv"))
+    assert not os.path.exists(os.path.join(final, "original"))
+    meldungen = fake_db.meldungen()
+    assert "NICHT aufgehoben" in meldungen
+    assert "anderen Mount" in meldungen
+    assert "Arbeitsverzeichnis" in meldungen  # nennt die Abhilfe
+
+
+def test_bei_exdev_und_genug_platz_wird_kopiert(tmp_path, fake_db, monkeypatch):
+    raw, final = _lege_rohdaten_an(tmp_path)
+
+    echtes_rename = os.rename
+    aufrufe = {"n": 0}
+
+    def rename_erst_exdev(*args, **kwargs):
+        # Nur der Versuch von _original_aufheben scheitert; shutil.move darf
+        # intern weiter umbenennen (es kopiert selbst und benennt Teile um).
+        aufrufe["n"] += 1
+        if aufrufe["n"] == 1:
+            raise OSError(errno.EXDEV, "Invalid cross-device link")
+        return echtes_rename(*args, **kwargs)
+
+    monkeypatch.setattr(tasks.os, "rename", rename_erst_exdev)
+    monkeypatch.setattr(tasks, "_frei_bytes", lambda _p: 10 * 1024**3)
+
+    tasks._original_aufheben("job-1", raw, final)
+
+    assert os.path.isfile(os.path.join(final, "original", "title_t00.mkv"))
+    assert "Original behalten" in fake_db.meldungen()
+
+
+def test_anderer_fehler_wird_ehrlich_gemeldet_und_reisst_job_nicht_mit(
+    tmp_path, fake_db, monkeypatch
+):
+    """Ein Fehler beim Aufheben darf den Job NIE scheitern lassen — die
+    komprimierte Datei ist zu diesem Zeitpunkt fertig und in Ordnung."""
+    raw, final = _lege_rohdaten_an(tmp_path)
+
+    def zugriff_verweigert(*_a, **_k):
+        raise OSError(errno.EACCES, "Permission denied")
+
+    monkeypatch.setattr(tasks.os, "rename", zugriff_verweigert)
+
+    tasks._original_aufheben("job-1", raw, final)  # darf nicht werfen
+
+    meldungen = fake_db.meldungen()
+    assert "konnte nicht aufgehoben werden" in meldungen
+    assert raw in meldungen  # sagt, WO die Rohdatei liegt

docker/worker/test_ripping_helpers.py

@@ -13,6 +13,7 @@ from ripping import (
     build_makemkv_cmd,
     get_progress_from_line,
     get_progress_from_prgv,
+    parse_msg,
     write_abcde_config,
 )
 
@@ -42,10 +43,43 @@ def test_handbrake_cmd_arbeitet_auf_datei_nicht_geraet():
 
 
 def test_handbrake_progress_parsing():
-    # Testfund 22.07.: echtes HandBrake schreibt „45.50 %" MIT Leerzeichen
+    # Testfund 22.07.: echtes HandBrake schreibt 45.50 % MIT Leerzeichen
     assert get_progress_from_line("Encoding: task 1 of 1, 45.50 %") == 45
     assert get_progress_from_line("Encoding: task 1 of 1, 100.00 %") == 100
-    assert get_progress_from_line("kein Fortschritt hier") == 0
+    # Echte Zeile mit fps-Anhang, wie sie im Binary steht
+    assert get_progress_from_line(
+        "Encoding: task 1 of 1, 12.34 % (5.67 fps, avg 4.32 fps, ETA 00h12m34s)"
+    ) == 12
+    # Ein echtes 0 % ist eine ANGABE, keine Leermeldung
+    assert get_progress_from_line("Encoding: task 1 of 1, 0.00 %") == 0
+
+
+def test_handbrake_progress_ignoriert_scan_durchlauf():
+    """Befund 25.07.2026 (Akira-UHD, live gemessen): HandBrake läuft VOR dem
+    Encodieren einen Scan-Durchlauf, der ebenfalls Prozente ausgibt und dabei
+    bis 100 % steigt. Die alte Regex nahm jede Zahl vor einem Prozentzeichen
+    und meldete deshalb 99 %, während der Encode bei 1 % stand.
+
+    -1 heißt „keine Encode-Fortschrittszeile" — dasselbe Muster wie bei
+    get_progress_from_prgv. Fremde Zeilen dürfen NIE als 0 % gelten.
+    """
+    assert get_progress_from_line("Scanning title 1 of 1, preview 3, 30.00 %") == -1
+    assert get_progress_from_line("Scanning title 1 of 1, preview 10, 100.00 %") == -1
+    # Vorlauf-Phase: Prozente beziehen sich auf die Suche, nicht auf den Encode
+    assert get_progress_from_line(
+        "Encoding: task 1 of 1, Searching for start time, 42.00 %"
+    ) == -1
+    assert get_progress_from_line("kein Fortschritt hier") == -1
+    assert get_progress_from_line("Muxing: this may take awhile...") == -1
+    assert get_progress_from_line("") == -1
+
+
+def test_handbrake_progress_rechnet_zwei_durchlaeufe_zusammen():
+    """Presets mit zwei Durchläufen zählen die Prozente je Durchlauf neu.
+    Ohne Verrechnung sprang die Anzeige mitten in der Datei zurück auf 0."""
+    assert get_progress_from_line("Encoding: task 1 of 2, 50.00 %") == 25
+    assert get_progress_from_line("Encoding: task 2 of 2, 0.00 %") == 50
+    assert get_progress_from_line("Encoding: task 2 of 2, 100.00 %") == 100
 
 
 def test_prgv_parsing():
@@ -63,6 +97,60 @@ def test_prgv_parsing_ignoriert_fremde_zeilen():
     assert get_progress_from_prgv("PRGV:kaputt") == -1
 
 
+def test_parse_msg_trennt_code_und_klartext():
+    """Echte Zeilen aus einem makemkvcon-Lauf vom 25.07.2026 (Akira UHD).
+
+    Feld 4 ist laut https://www.makemkv.com/developers/usage.txt der fertig
+    zusammengesetzte Klartext — genau der landet im Rippy-Log.
+    """
+    assert parse_msg(
+        'MSG:1005,0,1,"MakeMKV v1.18.4 linux(x64-release) started","%1 started","MakeMKV v1.18.4 linux(x64-release)"'
+    ) == (1005, "MakeMKV v1.18.4 linux(x64-release) started")
+    assert parse_msg(
+        'MSG:1011,0,1,"Using LibreDrive mode (v06.3 id=866A98CB9C4E)","%1","Using LibreDrive mode (v06.3 id=866A98CB9C4E)"'
+    ) == (1011, "Using LibreDrive mode (v06.3 id=866A98CB9C4E)")
+
+
+def test_parse_msg_liest_die_uhd_fehlermeldung():
+    """3303 ist der Befund, um den es beim ganzen KEYDB-Thema geht: das
+    Laufwerk laeuft im LibreDrive-Modus, MakeMKV kennt nur den Schluessel
+    DIESER Pressung nicht. Ohne diese Zeile im Log raet der Commander."""
+    assert parse_msg(
+        'MSG:3303,16777216,0,"The volume key is unknown for this disc - video can\'t be decrypted","The volume key is unknown for this disc - video can\'t be decrypted"'
+    ) == (3303, "The volume key is unknown for this disc - video can't be decrypted")
+    assert parse_msg('MSG:5010,0,0,"Failed to open disc","Failed to open disc"') == (
+        5010,
+        "Failed to open disc",
+    )
+
+
+def test_parse_msg_schneidet_meldungen_mit_komma_nicht_ab():
+    """DER Grund fuer die Regex (Stand 25.07.2026): vorher stand hier
+    line.split(",", 4)[3]. Das schnitt jede Meldung ab, die selbst ein Komma
+    enthaelt — und MakeMKV schreibt solche laufend. Im Log stand dann nur noch
+    ein Satzfragment, das mehr verwirrt als hilft."""
+    zeile = (
+        'MSG:3025,0,3,"Title #1 has length of 12 seconds, which is less than '
+        'minimum title length of 120 seconds and was therefore skipped",'
+        '"Title #%1 has length of %2 seconds which is less than minimum title '
+        'length of %3 seconds and was therefore skipped","1","12","120"'
+    )
+    code, text = parse_msg(zeile)
+    assert code == 3025
+    assert text.endswith("and was therefore skipped")
+    assert "which is less than" in text
+
+
+def test_parse_msg_ignoriert_fremde_zeilen():
+    # Alles ausser MSG muss None liefern, sonst landet Fortschritts-Rauschen
+    # (PRGV kommt mehrmals pro Sekunde) als Log-Eintrag in der Datenbank.
+    assert parse_msg("PRGV:100,32768,65536") is None
+    assert parse_msg('DRV:0,2,999,12,"BD-RE ASUS BW-16D1HT","AKIRA","/dev/sr0"') is None
+    assert parse_msg("TCOUNT:5") is None
+    assert parse_msg("") is None
+    assert parse_msg("irgendwelcher Muell ohne Struktur") is None
+
+
 def test_abcde_cmd_hat_genau_ein_ausgabeformat():
     """Review-Fund 22.07.: '-o' stand doppelt (Format UND Verzeichnis) — abcde
     parste das Verzeichnis als Format, CD-Ripping war nie funktionsfähig."""
@@ -74,6 +162,20 @@ def test_abcde_cmd_hat_genau_ein_ausgabeformat():
     assert "-N" in cmd  # nicht-interaktiv, sonst hängt der Worker
 
 
+def test_abcde_auswurf_folgt_der_einstellung():
+    """Befund 25.07.2026: `-x` (Auswurf) stand fest verdrahtet drin. Eine
+    Audio-CD warf damit IMMER aus, eine DVD/Blu-ray NIE — und die Einstellung
+    „Automatischer Auswurf" regelte keines von beidem, weil sie nirgends
+    gelesen wurde."""
+    assert "-x" in build_abcde_cmd("/dev/sr0", "/tmp/c.conf", auswerfen=True)
+    assert "-x" not in build_abcde_cmd("/dev/sr0", "/tmp/c.conf", auswerfen=False)
+    # Standard bleibt „auswerfen" — so war das Verhalten bisher
+    assert "-x" in build_abcde_cmd("/dev/sr0", "/tmp/c.conf")
+    # Die Config darf durch das weggefallene -x nicht verrutschen
+    ohne = build_abcde_cmd("/dev/sr0", "/tmp/c.conf", auswerfen=False)
+    assert ohne[ohne.index("-c") + 1] == "/tmp/c.conf"
+
+
 def test_abcde_config_enthaelt_zielverzeichnis():
     pfad = write_abcde_config("/app/media/cd/test123")
     try:
@@ -83,3 +185,90 @@ def test_abcde_config_enthaelt_zielverzeichnis():
         assert "INTERACTIVE=n" in inhalt
     finally:
         os.unlink(pfad)
+
+
+def test_preset_fuer_nimmt_das_preset_des_disc_typs():
+    # Befund 25.07.2026: vorher galt EIN Preset fuer alles — eine 4K-UHD wurde
+    # damit auf 1080p heruntergerechnet, und beim ersten echten UHD-Rip waere
+    # die 4K-Aufloesung still verlorengegangen.
+    from ripping import preset_fuer
+
+    einstellungen = {
+        "transcodePreset": "HQ 1080p30 Surround",
+        "transcodePresetDvd": "H.265 MKV 576p25",
+        "transcodePresetBluray": "H.265 MKV 1080p30",
+        "transcodePresetUhd": "H.265 MKV 2160p60 4K",
+    }
+    assert preset_fuer("uhd", einstellungen) == "H.265 MKV 2160p60 4K"
+    assert preset_fuer("bluray", einstellungen) == "H.265 MKV 1080p30"
+    assert preset_fuer("dvd", einstellungen) == "H.265 MKV 576p25"
+
+
+def test_preset_fuer_faellt_auf_das_allgemeine_preset_zurueck():
+    # Bestandsinstallationen kennen die drei neuen Felder nicht. Solange der
+    # Nutzer sie nicht speichert, MUSS sich sein Verhalten nicht aendern.
+    from ripping import preset_fuer
+
+    alt = {"transcodePreset": "HQ 1080p30 Surround"}
+    assert preset_fuer("uhd", alt) == "HQ 1080p30 Surround"
+    assert preset_fuer("dvd", alt) == "HQ 1080p30 Surround"
+    # Leere Zeichenkette zaehlt als "nicht gesetzt" (leeres Select-Feld im UI)
+    assert preset_fuer("uhd", {"transcodePresetUhd": "  ", "transcodePreset": "X"}) == "X"
+
+
+def test_preset_fuer_ohne_einstellungen_nimmt_den_eingebauten_standard():
+    # Unbekannter Disc-Typ, leere oder fehlende Einstellungen: nie None, nie
+    # Absturz — sonst stirbt die Kompression an einem leeren --preset-Argument.
+    from ripping import DEFAULT_HB_PRESET, preset_fuer
+
+    assert preset_fuer("uhd", {}) == DEFAULT_HB_PRESET
+    assert preset_fuer("", None) == DEFAULT_HB_PRESET
+    assert preset_fuer(None, {}) == DEFAULT_HB_PRESET
+    assert preset_fuer("cd", {"transcodePresetUhd": "egal"}) == DEFAULT_HB_PRESET
+
+
+def test_handbrake_prueft_abbruch_bei_jeder_zeile_nicht_nur_bei_fortschritt():
+    """Befund 25.07.2026 (am laufenden Akira-Job beobachtet): Der Abbruch hing
+    am Fortschritts-Callback, und der stieg bei unveraenderter Prozentzahl
+    sofort aus. Bei einem 4K-Encode mit einem Prozent je halber Stunde sah
+    „Abbrechen" minutenlang wirkungslos aus (gemessen: 3,4 min).
+
+    Der Abbruch-Kanal muss deshalb JEDE Ausgabezeile sehen — auch die des
+    Scan-Durchlaufs, der gar keine Encode-Prozente liefert.
+    """
+    import ripping
+
+    zeilen = [
+        "Scanning title 1 of 1, preview 1, 10.00 %\n",
+        "Scanning title 1 of 1, preview 2, 20.00 %\n",
+        "Encoding: task 1 of 1, 0.00 %\n",
+        "Encoding: task 1 of 1, 0.00 %\n",
+    ]
+    gesehen = []
+
+    class FakeProcess:
+        def __init__(self):
+            self.stdout = iter(zeilen)
+            self.returncode = 0
+            self.getoetet = False
+
+        def kill(self):
+            self.getoetet = True
+
+        def wait(self):
+            return 0
+
+    prozess = FakeProcess()
+
+    def abbruch_cb():
+        gesehen.append(1)
+        if len(gesehen) == 2:  # beim zweiten Mal abbrechen
+            raise ripping.RipAbbruch()
+
+    ergebnis = ripping._handbrake_schleife(prozess, "/x.mkv", abbruch_cb, None)
+
+    assert ergebnis["status"] == "cancelled"
+    assert prozess.getoetet is True
+    # Zwei Scan-Zeilen genuegten — es musste NICHT auf eine Encode-Zeile gewartet
+    # werden. Genau das war der Fehler.
+    assert len(gesehen) == 2

docker/worker/test_zombies.py

@@ -0,0 +1,190 @@
+"""Tests der Zombie-Erkennung — ohne Postgres und ohne Redis.
+
+Der Schwerpunkt liegt bewusst auf dem, was WEHTUT: ein laufender Job darf
+niemals als Leiche gelten. Genau das wäre am 25.07.2026 passiert, wenn die
+Erkennung nach dem Alter des Jobs geurteilt hätte — der Akira-Job war seit
+neun Stunden offen und lief trotzdem.
+"""
+
+import zombies
+
+
+# --- reine Funktionen -------------------------------------------------------
+
+def test_belegte_job_ids_findet_id_an_beliebiger_stelle():
+    """job_id steht bei rip_disc an zweiter, bei transcode_files an erster
+    Stelle — die Erkennung darf sich auf keine Position verlassen."""
+    aktiv = {
+        "celery@node1": [
+            {"name": "worker.tasks.transcode_files", "args": ["job-eins", "/raw", "/final"]},
+            {"name": "worker.tasks.rip_disc", "args": ["/dev/sr0", "job-zwei"]},
+        ]
+    }
+    belegt = zombies.belegte_job_ids([aktiv], ["job-eins", "job-zwei", "job-drei"])
+    assert belegt == {"job-eins", "job-zwei"}
+
+
+def test_belegte_job_ids_versteht_args_als_text():
+    """Celery liefert args je nach Version als Liste ODER als Text-Repräsentation."""
+    aktiv = {"celery@node1": [{"name": "x", "args": "('job-eins', '/raw', '/final')"}]}
+    assert zombies.belegte_job_ids([aktiv], ["job-eins", "job-zwei"]) == {"job-eins"}
+
+
+def test_belegte_job_ids_ohne_auskunft_ist_leer():
+    assert zombies.belegte_job_ids(None, ["a"]) == set()
+    assert zombies.belegte_job_ids([None, None, None], ["a"]) == set()
+    assert zombies.belegte_job_ids([{}, None], ["a"]) == set()
+
+
+def test_antwortende_knoten_sammelt_ueber_alle_abfragen():
+    aktiv = {"celery@a": []}
+    vorgemerkt = {"celery@b": []}
+    assert zombies.antwortende_knoten([aktiv, None, vorgemerkt]) == {"celery@a", "celery@b"}
+    assert zombies.antwortende_knoten([None, None]) == set()
+
+
+def test_auskunft_nur_vollstaendig_wenn_alle_bekannten_antworten():
+    assert zombies.auskunft_vollstaendig(1, 1) is True
+    assert zombies.auskunft_vollstaendig(2, 1) is True
+    # Ein bekannter Worker schweigt → NICHT urteilen
+    assert zombies.auskunft_vollstaendig(1, 2) is False
+    # Niemand antwortet → wir wissen nichts
+    assert zombies.auskunft_vollstaendig(0, 0) is False
+
+
+def test_finde_zombies_verschont_belegte_jobs():
+    offene = [{"id": "a", "status": "transcoding"}, {"id": "b", "status": "ripping"}]
+    assert zombies.finde_zombies(offene, {"a"}) == [{"id": "b", "status": "ripping"}]
+    assert zombies.finde_zombies(offene, {"a", "b"}) == []
+
+
+def test_fehlertext_nennt_zustand_und_den_weg_zurueck():
+    text = zombies.fehlertext({"status": "transcoding"})
+    assert "transcoding" in text
+    assert "Neu komprimieren" in text
+    assert "NICHT gelöscht" in text
+
+
+# --- Attrappen für den Gesamtdurchlauf --------------------------------------
+
+class FakeInspektor:
+    def __init__(self, aktiv=None, vorgemerkt=None, geplant=None):
+        self._aktiv, self._vorgemerkt, self._geplant = aktiv, vorgemerkt, geplant
+
+    def active(self):
+        return self._aktiv
+
+    def reserved(self):
+        return self._vorgemerkt
+
+    def scheduled(self):
+        return self._geplant
+
+
+class FakeCelery:
+    def __init__(self, inspektor):
+        self.control = self
+        self._inspektor = inspektor
+
+    def inspect(self, timeout=None):
+        return self._inspektor
+
+
+class FakeDb:
+    def __init__(self, offene, online=1):
+        self._offene, self._online = offene, online
+        self.aktualisierungen = []
+        self.logs = []
+
+    def list_jobs_mit_status(self, stati):
+        return [j for j in self._offene if j["status"] in stati]
+
+    def zaehle_online_worker(self, sekunden=120):
+        return self._online
+
+    def update_job(self, job_id, **felder):
+        self.aktualisierungen.append((job_id, felder))
+
+    def add_log(self, level, source, message):
+        self.logs.append((level, message))
+
+    def utcnow(self):
+        return "jetzt"
+
+
+# --- Gesamtdurchlauf --------------------------------------------------------
+
+def test_laufender_job_wird_nicht_angetastet():
+    """Der Fall, der wehtut: Job läuft seit Stunden und IST aktiv."""
+    db = FakeDb([{"id": "lebt", "status": "transcoding", "title": "Akira"}])
+    aktiv = {"celery@a": [{"name": "worker.tasks.transcode_files", "args": ["lebt"]}]}
+    celery = FakeCelery(FakeInspektor(aktiv=aktiv, vorgemerkt={}, geplant={}))
+
+    bericht = zombies.raeume_zombies_auf(celery, db)
+
+    assert bericht["aufgeraeumt"] == []
+    assert db.aktualisierungen == []
+
+
+def test_echte_leiche_wird_auf_failed_gesetzt():
+    db = FakeDb([{"id": "leiche", "status": "transcoding", "title": "Akira"}])
+    # Der Knoten antwortet — er arbeitet nur an nichts.
+    celery = FakeCelery(FakeInspektor(aktiv={"celery@a": []}, vorgemerkt={}, geplant={}))
+
+    bericht = zombies.raeume_zombies_auf(celery, db)
+
+    assert bericht["aufgeraeumt"] == ["leiche"]
+    job_id, felder = db.aktualisierungen[0]
+    assert job_id == "leiche"
+    assert felder["status"] == "failed"
+    assert "Neu komprimieren" in felder["error"]
+    assert felder["finished_at"] == "jetzt"
+
+
+def test_schweigender_worker_verhindert_jedes_urteil():
+    """Zwei Worker gelten als online, nur einer antwortet — der andere könnte
+    genau diesen Job bearbeiten. Also: Finger weg."""
+    db = FakeDb([{"id": "unklar", "status": "transcoding", "title": "X"}], online=2)
+    celery = FakeCelery(FakeInspektor(aktiv={"celery@a": []}, vorgemerkt={}, geplant={}))
+
+    bericht = zombies.raeume_zombies_auf(celery, db)
+
+    assert bericht["aufgeraeumt"] == []
+    assert db.aktualisierungen == []
+    assert "unvollständige Auskunft" in bericht["uebersprungen"]
+
+
+def test_gar_keine_antwort_fuehrt_zu_keinem_urteil():
+    db = FakeDb([{"id": "unklar", "status": "ripping", "title": "X"}], online=0)
+    celery = FakeCelery(FakeInspektor(aktiv=None, vorgemerkt=None, geplant=None))
+
+    bericht = zombies.raeume_zombies_auf(celery, db)
+
+    assert bericht["aufgeraeumt"] == []
+    assert db.aktualisierungen == []
+
+
+def test_fertige_jobs_werden_gar_nicht_betrachtet():
+    db = FakeDb([
+        {"id": "fertig", "status": "completed", "title": "A"},
+        {"id": "kaputt", "status": "failed", "title": "B"},
+        {"id": "wartet", "status": "pending", "title": "C"},
+    ])
+    celery = FakeCelery(FakeInspektor(aktiv={"celery@a": []}, vorgemerkt={}, geplant={}))
+
+    bericht = zombies.raeume_zombies_auf(celery, db)
+
+    # pending bleibt bewusst unberührt: die Aufgabe kann noch in der
+    # Warteschlange liegen und wird von selbst abgeholt.
+    assert bericht["geprueft"] == 0
+    assert db.aktualisierungen == []
+
+
+def test_fehler_reisst_den_worker_start_nicht_mit():
+    class KaputteDb(FakeDb):
+        def list_jobs_mit_status(self, stati):
+            raise RuntimeError("Postgres weg")
+
+    db = KaputteDb([])
+    bericht = zombies.raeume_zombies_auf(FakeCelery(FakeInspektor()), db)
+    assert "Postgres weg" in bericht["uebersprungen"]

docker/worker/zombies.py

@@ -0,0 +1,149 @@
+"""Erkennt Job-Leichen: Jobs, die behaupten zu laufen, an denen aber niemand arbeitet.
+
+Befund 25.07.2026 (Akira-UHD): Nach einem Absturz stand ein Job auf
+`transcoding` bei 96 %, obwohl weder ein Prozess lief noch etwas in den
+Celery-Queues stand. Folge für den Nutzer: kein Fortschritt, kein Download —
+und der Knopf „Neu komprimieren" fehlte, weil `_kann_neu_komprimieren`
+(api/main.py) `status == "failed"` verlangt. Der Job war damit unerreichbar,
+obwohl die Rohdateien vollständig dalagen.
+
+## Die Leitregel: ohne vollständige Auskunft wird NICHTS angetastet
+
+Ein falsch als Leiche markierter Job ist teurer als eine stehengebliebene
+Leiche. Deshalb drei Sicherungen:
+
+1. **Nur beim Worker-Start.** Da ist die Aussage eindeutig: „als ich hochkam,
+   lief nichts". Ein periodischer Lauf könnte einen Job erwischen, der legitim
+   in der Warteschlange wartet, weil alle Arbeitsplätze belegt sind — der ist
+   für `active()`/`reserved()` unsichtbar. Bewusst nicht gebaut.
+2. **Gnadenfrist.** Nach einem Neustart stellt Celery unbestätigte Aufgaben
+   erneut zu. Erst abwarten, dann urteilen.
+3. **Vollzähligkeit.** Es wird nur geurteilt, wenn mindestens so viele
+   Celery-Knoten antworten, wie laut Herzschlag online sind. Antwortet ein
+   beschäftigter Remote-Worker nicht rechtzeitig, wäre sein laufender Job
+   sonst eine falsche Leiche.
+
+Die Kernfunktionen sind bewusst rein (kein Postgres, kein Redis), damit die
+Ampel sie ohne Infrastruktur prüfen kann.
+"""
+
+# Zustände, die behaupten: hier arbeitet gerade jemand.
+ARBEITS_STATI = ("ripping", "transcoding", "canceling")
+
+# Wartezeit nach dem Worker-Start, bevor geurteilt wird. Deckt die
+# Wiederzustellung unbestätigter Aufgaben durch Celery ab.
+GNADENFRIST_SEKUNDEN = 120
+
+# Wie lange auf Antworten der Celery-Knoten gewartet wird. Großzügig, weil ein
+# Worker mitten in einem 4K-Encode träge antwortet.
+INSPEKT_TIMEOUT_SEKUNDEN = 10
+
+
+def belegte_job_ids(inspektionen, kandidaten) -> set:
+    """Welche der `kandidaten`-IDs kommen in irgendeiner Celery-Aufgabe vor?
+
+    Bewusst als Textsuche über die ganze Inspektions-Antwort: `job_id` steht
+    bei `rip_disc` an ZWEITER, bei `transcode_files` an ERSTER Stelle, und
+    Celery liefert `args` je nach Version als Liste oder als Text. Eine
+    Positions-Auswertung wäre an beidem zerbrechlich. Eine Job-ID ist eine
+    36-stellige UUID — Fehltreffer sind praktisch ausgeschlossen.
+
+    `inspektionen` ist die Liste der Antworten (active/reserved/scheduled);
+    `None`-Einträge werden übersprungen.
+    """
+    vorhandene = [i for i in (inspektionen or []) if i]
+    if not vorhandene:
+        return set()
+    text = repr(vorhandene)
+    return {jid for jid in kandidaten if jid and jid in text}
+
+
+def antwortende_knoten(inspektionen) -> set:
+    """Namen aller Celery-Knoten, die auf die Inspektion geantwortet haben."""
+    knoten = set()
+    for antwort in (inspektionen or []):
+        if antwort:
+            knoten.update(antwort.keys())
+    return knoten
+
+
+def auskunft_vollstaendig(anzahl_antworten: int, anzahl_bekannt: int) -> bool:
+    """Darf aus dieser Auskunft überhaupt ein Urteil folgen?
+
+    Nein, wenn niemand geantwortet hat (dann wissen wir nichts), und nein, wenn
+    weniger Knoten antworten als laut Herzschlag online sind (dann fehlt uns
+    genau der Knoten, der den Job vielleicht gerade bearbeitet).
+    """
+    if anzahl_antworten < 1:
+        return False
+    return anzahl_antworten >= anzahl_bekannt
+
+
+def finde_zombies(offene_jobs, belegte) -> list:
+    """Jobs aus `offene_jobs`, zu denen keine Celery-Aufgabe existiert."""
+    return [job for job in offene_jobs if job.get("id") not in belegte]
+
+
+def fehlertext(job) -> str:
+    """Ehrlicher Klartext für die Job-Karte — was war, und was jetzt hilft."""
+    zuletzt = job.get("status") or "unbekannt"
+    return (
+        f"Abgebrochen: Der Vorgang lief nicht mehr (zuletzt gemeldet: {zuletzt}). "
+        "Beim Start des Workers war dazu weder ein Prozess noch eine Aufgabe in "
+        "der Warteschlange zu finden — meistens ein Absturz oder ein Neustart "
+        "mitten im Lauf. Die Rohdateien wurden NICHT gelöscht: mit "
+        "'Neu komprimieren' läuft die Kompression erneut, ohne die Disc noch "
+        "einmal zu rippen."
+    )
+
+
+def raeume_zombies_auf(celery_app, db) -> dict:
+    """Sucht Leichen und setzt sie ehrlich auf `failed`. Wirft nie.
+
+    Rückgabe (auch für den Log): was geprüft und was getan wurde.
+    """
+    bericht = {"geprueft": 0, "aufgeraeumt": [], "uebersprungen": ""}
+    try:
+        offene = db.list_jobs_mit_status(ARBEITS_STATI)
+        bericht["geprueft"] = len(offene)
+        if not offene:
+            return bericht
+
+        inspektor = celery_app.control.inspect(timeout=INSPEKT_TIMEOUT_SEKUNDEN)
+        inspektionen = [inspektor.active(), inspektor.reserved(), inspektor.scheduled()]
+
+        knoten = antwortende_knoten(inspektionen)
+        bekannt = db.zaehle_online_worker()
+        if not auskunft_vollstaendig(len(knoten), bekannt):
+            bericht["uebersprungen"] = (
+                f"unvollständige Auskunft ({len(knoten)} von {bekannt} Worker "
+                "haben geantwortet) — es wird nichts als Leiche gewertet"
+            )
+            db.add_log(
+                "info", "worker",
+                f"Zombie-Erkennung übersprungen: {bericht['uebersprungen']}",
+            )
+            return bericht
+
+        belegte = belegte_job_ids(inspektionen, [j.get("id") for j in offene])
+        for job in finde_zombies(offene, belegte):
+            db.update_job(
+                job["id"],
+                status="failed",
+                error=fehlertext(job),
+                finished_at=db.utcnow(),
+            )
+            db.add_log(
+                "warning", "worker",
+                f"Job {job['id']} ({job.get('title') or 'ohne Titel'}) stand auf "
+                f"'{job.get('status')}', es arbeitet aber niemand daran — "
+                "ehrlich auf 'failed' gesetzt. Rohdateien bleiben liegen.",
+            )
+            bericht["aufgeraeumt"].append(job["id"])
+    except Exception as e:  # Erkennung darf den Worker-Start NIEMALS verhindern
+        bericht["uebersprungen"] = f"Fehler: {e}"
+        try:
+            db.add_log("warning", "worker", f"Zombie-Erkennung fehlgeschlagen: {e}")
+        except Exception:
+            pass
+    return bericht