# Durchsicht Rippy v5 (5.6.1) — Bericht vom 12.09.2026

> Anlass: Drei Filme (Der Patriot, Déjà Vu, Training Day) lassen sich auf
> einem ANDEREN PC mit Rippy nicht bearbeiten, während MakeMKV allein sie
> lesen und öffnen kann. Dazu die Bitte um einen kompletten Check von
> Kern, Haupt und Fenster.
>
> Was hier steht, ist GEMESSEN oder im Quelltext mit Zeile belegt — nichts
> ist geraten. Wo ich etwas nicht messen konnte, steht das dabei.

Stand des Repos: Branch `worktree-windows-electron`, Spitze `473eea7`,
Arbeitsbaum sauber. `npm run typecheck` grün, `npm test` grün
(450 Tests bestanden, 12 übersprungen — die Messungen, die ein Laufwerk
brauchen). Gelesen wurden ALLE 92 Quelldateien unter `rippy-windows/src`
(16 081 Zeilen), die Tests, die Bau-Konfiguration und die Protokolle des
echten Rippy auf diesem PC.

---

## 1. Die drei Filme — was am anderen PC dahintersteckt

Ich habe die Disc-Ausgaben des anderen PCs nicht; ich habe aber ALLE Wege
gefunden, auf denen Rippy scheitert, während MakeMKV allein weiterkommt.
Sie stehen in der Reihenfolge, in der ich sie für wahrscheinlich halte —
mit der Zeile, an der man sie am anderen PC in einer Minute erkennt.

**Die Protokoll-Datei liegt dort unter `%APPDATA%\Rippy\logs\rippy-JJJJ-MM-TT.log`**
(im Programm: Einstellungen → Allgemein → „Protokoll öffnen"). Die Zeilen
des Tages, an dem einer der drei Filme versucht wurde, entscheiden.

### Kandidat 1 — MakeMKV läuft dort ohne gültigen Schlüssel (Beta-Key-Fehler in Rippy)

Der frei veröffentlichte Beta-Key vom September 2026 enthält ein `@`:
`T-vwvn…6Ox4BI@N5rPp` (68 Zeichen, heute von der Herstellerseite geladen,
„valid until end of September 2026"). Rippys Muster
`KEY_MUSTER = /T-[A-Za-z0-9_]{50,}/` (`kern/werkzeuge/schluessel.ts:19`)
kennt kein `@` und schneidet den Schlüssel auf 62 Zeichen ab (Sonde 9,
gemessen an der echten Seite). Den verstümmelten Schlüssel lehnt MakeMKV
ab (5020), Rippy nimmt ihn „damit MakeMKV im Beta-Modus weiterläuft" wieder
zurück (`schluessel.ts:214-219`) — und MakeMKV läuft ohne Schlüssel.
Für DVDs ist das egal (laut Hersteller dauerhaft frei), **für Blu-rays
schaltet MakeMKV nach Ablauf des Testzeitraums ab** — nach der
Gnadenfrist („noch einige Tage", MSG 5051) beim Speichern, je nach
Fassung auch beim Öffnen. Ob das GUI am anderen PC noch in der
Gnadenfrist ist, sagt dessen Startmeldung; Rippy dagegen meldet den
Zustand nicht als Ausfall (siehe F1/F5).

Warum es bei DIR läuft: In der echten Datenbank dieses PCs steht unter
`makemkvAppKey` ein 68-Zeichen-Schlüssel MIT `@` — du hast den Key von
Hand als „Eigener Schlüssel" eingetragen. Der andere PC verlässt sich
vermutlich auf die Automatik, und die liefert den kaputten Key.

*Erkennen:* Einstellungen → MakeMKV zeigt dort gelb „BETA-MODUS — RIPS
LAUFEN" oder rot; im Protokoll steht `Schlüssel: Beta-Key abgelehnt … —
wieder entfernt`; ein gescheiterter Rip trägt `Ursache: MakeMKV ist nicht
freigeschaltet (Testzeitraum abgelaufen)`; MakeMKV-GUI zeigt beim Start
„Der Testzeitraum ist abgelaufen".
*Sofort-Abhilfe ohne neue Version:* den vollständigen Key (mit `@`) von
Hand unter Einstellungen → MakeMKV → „Eigener Schlüssel" eintragen,
„Schlüssel neu prüfen". Gilt bis 30.09.2026 — danach braucht es den
Rippy-Fix (Fund 1 unten) oder wieder Handarbeit.

### Kandidat 2 — Titel lesen bricht nach fünf Minuten ab (der Timeout, nicht die Disc)

`erkennung.titelLesen` tötet `makemkvcon info` nach 300 s
(`kern/dienste/erkennung.ts:315`, `kern/rip/makemkv.ts:170-173`) und
meldet „MakeMKV hat die Titel nach fünf Minuten nicht gelesen. Bei einer
beschädigten Disc kann das passieren". Ältere DVDs mit Kopierschutz
(Sony-ARccOS, Disney-99-Titel-Struktur) und Discs mit vielen Playlisten
brauchen im MakeMKV-GUI regelmäßig länger als fünf Minuten zum Öffnen —
das GUI wartet, Rippy nicht. Ein hart beendetes makemkvcon hinterlässt
außerdem gern den 5042-Zustand („findet kein Laufwerk"), sodass der
NÄCHSTE Versuch sofort scheitert.
*Erkennen:* `Titel-Lauf X gescheitert: MakeMKV hat die Titel nach fünf
Minuten nicht gelesen`; im GUI dauert „Disc wird geöffnet" länger als 5 min.

### Kandidat 3 — der Rip startet still nicht (Ablage oder Arbeitsordner nicht erreichbar)

`Pipeline.starten` legt den Roh-Ordner mit `mkdirSync` an
(`kern/ablauf/pipeline.ts:258`) — ohne Fangnetz. Ist die Ablage oder der
Arbeitsordner gerade nicht da (NAS aus, Netzlaufwerk noch nicht
verbunden, Buchstabe weg), fliegt eine Ausnahme aus `starten()`, der
Aufruf `void laufwerke.bereit.then(() => ripVerwaltung.starten(…))`
(`kern/index.ts:198`) verschluckt sie: **keine Meldung im Fenster, keine
Zeile im Protokoll, der Dialog schließt sich, nichts passiert** (Sonde 10:
`ENOENT … mkdir 'Q:\rippy-nicht-da\roh\…'`, gemeldet: nichts). Der Kern
stirbt dabei nicht (in Electron 44 gemessen: ein utilityProcess überlebt
eine unbehandelte Promise-Ablehnung) — er schweigt nur.
*Erkennen:* Nach `Titel-Lauf X: … s, N Titel` folgt KEINE Zeile
`Vorgang … beginnt`; die Kachel bleibt ohne Balken.

### Kandidat 4 — Disc-Typ „unbekannt" → Rippy sichert ein ISO statt zu rippen

Der Typ kommt aus `IOCTL_CDROM_DISK_TYPE` + Größe (`kern/laufwerk/disc.ts:52-59`).
Antwortet das Laufwerk darauf nicht (bei manchen USB-Brücken
`ERROR_INVALID_FUNCTION`) oder ohne Bits, steht `unknown` — die Kachel
zeigt „unbekannt" und PRESET „ISO-Abbild", der Knopf „Rippen" öffnet
trotzdem den Titel-Dialog (`LaufwerkKachel.tsx:157-166`), und nach der
Auswahl legt die Pipeline ein 1:1-Abbild an statt der gewählten Titel
(`pipeline.ts:236-241`).
*Erkennen:* `Disc eingelegt in X: unknown, … Bytes`, Kachel MEDIUM
„unbekannt", Statuszeile „Sichere 1:1-Abbild …".

### Kandidat 5 — Erkennung bleibt bei 60 %, die Automatik wartet (kein Fehler, aber „tut nichts")

Alle drei Discs tragen vermutlich englische Labels (`THE_PATRIOT`,
`DEJA_VU`, `TRAINING_DAY`). TMDb antwortet auf Deutsch („Der Patriot",
„Déjà Vu – Wettlauf gegen die Zeit"); der wörtliche Vergleich
`gleichBedeutend` (`kern/metadaten/zuordnung.ts:184-195`) vergleicht nur
den deutschen `title`, nie `original_title`, und kennt keine Akzente
(Sonde 1: „Déjà Vu" ≠ „Deja Vu", „Der Patriot" ≠ „The Patriot"). Ergebnis:
Vorschlag mit 60 % statt 95 % — die Automatik startet nicht
(`automatik.ts:79-82`), im Kasten steht „Automatik wartet: Die Erkennung
ist nicht sicher genug". Wer auf Zero-Click wartet, sieht: nichts.
*Erkennen:* Kachel „Vorschlag" (gelb) statt „sehr wahrscheinlich"; die
Automatik-Zeile.

### Was ich vom anderen PC brauche, um es festzunageln

1. Die Protokoll-Zeilen des Tages (siehe oben) — am besten die ganze Datei.
2. Einstellungen → MakeMKV: der Text der Schlüssel-Karte, und MakeMKV-Version.
3. Ob die drei Discs DVD, Blu-ray oder 4K sind.
4. Was genau „nicht bearbeiten" war: kein Start, roter Text, ISO, oder ewig „liest die Titel".

---

## 2. Fehler — nach Schwere, mit Beleg

Schwere: **HOCH** = Datenverlust, Ausfall oder stilles Scheitern ·
**MITTEL** = falsches Verhalten, das der Nutzer bemerkt · **NIEDRIG** =
Schönheit, Bedienung, Nebensache. Jede Nummer verweist auf Datei:Zeile im
Stand `473eea7`.

### HOCH

**F1 · Beta-Key mit `@` wird abgeschnitten → MakeMKV unlizenziert**
`kern/werkzeuge/schluessel.ts:19` (`KEY_MUSTER`), `:24-27`, `:212-219`.
Beleg: Sonde 9 an der heute geladenen Forum-Seite: Seite 68 Zeichen mit
`@`, Rippy zieht 62. Wirkung: siehe Kandidat 1 — auf jedem PC ohne
Hand-Key laufen Blu-ray-Rips nach dem Testzeitraum nicht mehr, und Rippy
zeigt dazu GELB „BETA-MODUS — RIPS LAUFEN" (`Karten.tsx:409-413`,
`App.tsx:115`). Dazu: `extractGueltigBis` (`:32-37`) erkennt „end of
September 2026" nicht → kein Ablaufdatum im Fenster (gemessen: leer).
Fix: Muster auf alles bis Leerzeichen/`<` (z. B. `/T-[^\s<"']{50,}/`),
Ablehnung ROT mit Klartext „Blu-ray-Rips laufen nicht", und ein Test mit
dem echten September-Schlüssel.

**F2 · Rip-Start ohne erreichbare Ablage/Arbeitsordner scheitert STILL**
`kern/ablauf/pipeline.ts:258` (`mkdirSync` ohne try), ebenso `:646`
(Audio-CD) und `:721` (ISO); Aufrufer `kern/index.ts:198` und `:236`.
Beleg: Sonde 10 + Electron-Messung (utilityProcess lebt weiter, Fehler
unsichtbar). Verstößt gegen R4. Fix: `starten()` in try/catch, Fehler als
`rip-status fehler` melden UND ins Protokoll; zusätzlich vor dem Start
eine Schreibprobe am Roh-Ordner, damit die Kachel sagt „Ablage nicht
erreichbar" statt zu schweigen; im Kern ein `process.on('unhandledRejection')`,
das ins Protokoll schreibt.

**F3 · Serien: zweite Disc derselben Staffel — Folgen werden nicht benannt, Überschreiben möglich**
`kern/ablage/struktur.ts:224-246`: `episodenUmbenennen` zählt ALLE `.mkv`
im Season-Ordner; liegen dort schon `S01E01`/`S01E02` der ersten Disc,
heißt es „Umbenennen übersprungen: 4 Dateien, 2 Zuordnungen" (Sonde 2,
real ausgeführt). Der Serien-Merker (5.5.0) und „ab Folge" laufen damit ab
Disc 2 ins Leere. Schlimmer: Folgen behalten bis dahin MakeMKVs Namen
(`ablegen.ts:198-209`, `dateinamen.ts:121`), und `title_t00.mkv` der
zweiten Disc landet im SELBEN Ordner (`ablegen.ts:152-156`) — HandBrake
bzw. `renameSync` (`ablegen.ts:95-104`) überschreiben eine gleichnamige
Datei der ersten Disc ohne Warnung, wenn deren Umbenennung ausgefallen
war (kein TMDb). Der bestehende Test `test/ablage.test.ts:106-116`
schreibt das Verhalten sogar fest. Fix: nur die NEUEN Dateien dieser
Disc umbenennen (Liste übergeben statt Ordner lesen); Zielnamen vor dem
Encode auf Kollision prüfen und nie überschreiben.

**F4 · Kern-Neustart: das Fenster bleibt taub**
`haupt/kernstart.ts:59-74` startet den Kern bis zu 3× je Minute neu, aber
`fensterVerbinden` läuft nur bei `did-finish-load` (`haupt/index.ts:245-253`);
das Fenster hält den toten Port (`kernverbindung.ts:268-282`), `anKern`
schickt ins Leere, und `App.tsx:92` zeigt keinen Fehler, weil
`verbindung.kern` noch die alte Bereit-Meldung ist. Wirkung: Laufwerke
frieren ein, Knöpfe tun nichts — bis Rippy komplett neu gestartet wird.
Das KONZEPT verspricht „Der Kern ist abgestürzt, ich starte ihn neu".
Fix: im `spawn`-Ereignis des neuen Kerns `fensterVerbinden` erneut
aufrufen und eine Zeile im Fenster zeigen.

### MITTEL

**F5 · Schlüssel-Prüfung urteilt ohne Grundlage**
`schluessel.ts:108-131`: `info disc:9999` liefert ohne angeschlossenes
Laufwerk NUR 5042/5010 (heute gemessen) — keine Lizenzzeile, also
`ok: true` und „angenommen", egal was im Register steht. `:179`:
das Ergebnis von `keyAblegen` (reg add) wird ignoriert — „hinterlegt"
steht auch dann im Protokoll, wenn nichts geschrieben wurde. `:194-237`:
Ablehnung liefert `weiterBetrieb: true` (gelb) statt rot.

**F6 · Jeder Auswurf legt eine weitere Takt-Kette der Disc-Wache an**
`kern/laufwerk/wache.ts:285-303`: `runde()` plant IMMER einen neuen
Timer, ohne den laufenden zu löschen; `laufwerke.ts:175` ruft `runde()`
nach jedem Auswurf. Beleg: Sonde 3 — drei Ketten, neunmal statt fünfmal
gelesen. Wirkung: nach 20 Discs fragt Rippy die Laufwerke alle 150 ms
statt alle 3 s (CreateFileW + IOCTL je Runde). Fix: vorhandenen Timer
in `runde()` erst löschen.

**F7 · Während der Kompression wird jede Sekunde die ganze Welt neu vermessen**
Kette: HandBrake-Fortschritt (mit ETA ≈ 1×/s, `handbrake.ts:152-158`) →
`warteschlange.ts:141-146` → `vorgaenge.ts:118-124` `senden()` →
`stand()` (`:217-260`) läuft mit `ordnerGroesse` rekursiv durch JEDEN
Roh-Ordner plus `fremdeOrdner`, danach `speicher.senden()` mit zwei
`statfsSync` (`speicher.ts:237-247`) — alles synchron im Kern; dann geht
die volle Vorgangsliste an Haupt und Fenster, das komplett neu zeichnet
(`kernverbindung.ts:123-125`). Auf einer NAS als Arbeitsordner ist das
ein Netz-Ordnerlauf pro Sekunde. Fix: Fortschritt als kleine Nachricht
getrennt vom Vorgangs-Stand; Roh-Größen nur bei Phasenwechsel oder
gedrosselt (z. B. alle 30 s) messen.

**F8 · Das Rettungs-Abbild wird gelöscht, wenn der Rip daraus leer ausgeht**
`pipeline.ts:279-300`: `beenden()` entfernt den ganzen Roh-Ordner, wenn
keine MKV entstand — inklusive `rettung.iso`, für das die Disc stundenlang
Sektor für Sektor gelesen wurde (`halbeDateienEntfernen` schont es,
`beenden` nicht). Fix: `rettung.iso` + Bericht vor dem `rmSync` verschonen.

**F9 · Halbe HandBrake-Ausgabe bleibt nach Abbruch/Fehler liegen**
`handbrake.ts:282-285,300-308`, `ablegen.ts:279-286`: nach `kill()` oder
Fehler wird die angefangene Datei nicht entfernt. Ohne Arbeitsordner
liegt sie direkt in `Filme\<Titel>\` — Jellyfin zeigt einen kaputten
Film. Fix: nach `.part`/Zwischenname encodieren, erst am Ende umbenennen;
bei Abbruch löschen.

**F10 · Typ „unbekannt" heißt stumm ISO, obwohl der Nutzer Titel gewählt hat**
`pipeline.ts:236-241` gegen `LaufwerkKachel.tsx:157-166`/`Uebersicht.tsx:114-120`
(siehe Kandidat 4). Dazu `disc.ts:49`: UHD wird allein an ≥ 55 GiB
erkannt — eine 4K-Disc mit 48 GB Daten wird „bluray" (Sonde 4) und
bekommt das Blu-ray-Preset. Fix: liegt ein Titel-Auftrag vor, immer
MakeMKV; UHD-Merkmal am Gerät nachmessen (Regel D) statt Größe.

**F11 · Laufwerks-Gesundheit beschuldigt das falsche Gerät**
`kern/laufwerk/ereignisse.ts:41-44`: der XPath nimmt Provider `cdrom` UND
`disk` für ALLE Geräte; `:67-76` filtert nicht nach `\Device\CdRomN`.
Eine hustende Festplatte oder ein zweites Laufwerk erzeugt „VERDACHT:
DIE HARDWARE" für die Kachel des Blu-ray-Laufwerks. Fix: Gerät des
Laufwerksbuchstabens ermitteln und nur dessen Ereignisse zählen.

**F12 · Zeiten stehen in UTC, nicht in deiner Uhrzeit**
`bausteine.tsx:35-38` (`datumKurz`), `Karten.tsx:269,276,418,574`,
`VerlaufKarte.tsx:295`: ISO-Strings werden abgeschnitten — 21:30 Uhr
erscheint als 19:30 (Sonde 5). Fix: lokal formatieren.

**F13 · Eigener Werkzeug-Pfad eingetragen → Anzeige bleibt „NICHT GEFUNDEN"**
`kern/index.ts:245-254`: nach `werkzeug.*` wird `werkzeuge.senden()` nicht
angestoßen (auch `makemkvAppKey` löst keinen Schlüssel-Lauf aus). In der
Erst-Einrichtung (`ErstEinrichtung.tsx:112-121`) bleibt die rote Zeile
stehen, obwohl der Pfad stimmt. Fix: nach diesen Schlüsseln messen bzw.
prüfen.

**F14 · Erkennung kennt weder Originaltitel noch Akzente**
`zuordnung.ts:184-195,302-309`, `tmdb.ts:24-34` (kein `original_title`).
Siehe Kandidat 5. Fix: `original_title`/`original_name` mitvergleichen,
Akzente falten (NFD + Kombinationszeichen entfernen).

**F15 · Tray „Beenden" tötet einen laufenden Rip ohne Rückfrage**
`haupt/index.ts:278-281,383-387`, `tray.ts:291-297`: `app.quit()` → Kern
`kill()` → die Leine reißt makemkvcon/HandBrake mit — 40 Minuten Rip weg.
Fix: bei aktiven Vorgängen nachfragen.

**F16 · MakeMKV-Installer aus dem Internet Archive mit Adminrechten**
`beschaffen.ts:143-155,193-232`, `haupt/index.ts:206-216`: fällt der
Hersteller aus, wird eine EXE vom Archiv geladen und per UAC gestartet;
geprüft wird nur die Versions-Ressource (fälschbar). Für ein Programm im
Bekanntenkreis ein Risiko. Fix: SHA-256 einer bekannten Fassung
mitführen oder Archiv-Quelle nur nach Bestätigung.

### NIEDRIG

**F17** „Roh-Dateien löschen" und „Ordner löschen" ohne Rückfrage — ein Klick, 30 GB weg (`Karten.tsx:315-319,351-353`; `vorgaenge.ts:305-349`).
**F18** Eingabefelder speichern nur beim Verlassen; Enter und Bereichswechsel verlieren Tipparbeit (`bausteine.tsx:356-389`).
**F19** Dialoge ohne Escape, Fokus-Fang, `role="dialog"` (`bausteine.tsx:453-473`).
**F20** Toast „Disc erkannt" bis zu dreimal je Disc — Erkennung, Nachprüfung, „Ändern" (`haupt/index.ts:126-134`).
**F21** Poster-Fehler wird verschluckt: Rückgabe von `posterSpeichern` ignoriert (`ablegen.ts:385-387`, R4).
**F22** `finden()` ruft bei fehlendem MakeMKV dreimal `reg query … /s` synchron (bis 45 s) — bei jedem Aufruf, auch alle 15 s im Update-Lauf (`katalog.ts:168-203`).
**F23** NFO ohne `<uniqueid type="tmdb">` — Jellyfin muss über Titel/Jahr raten (`nfo.ts:187-209`).
**F24** Doppelter Zielordner bekommt den Zusatz „[bluray-2]" (`struktur.ts:158-170`, `vorgangsName.slice(0,8)`).
**F25** ASCII-Umlaute in Knopftexten: „auswaehlen", „Titel ueberspringen", „naechsten" (`LaufwerkKachel.tsx:161,413,415`).
**F26** Phase `rettet` fehlt in der Haupt-Liste aktiver Vorgänge (`haupt/index.ts:184`) — Update-Sperre und Taskleiste greifen im Rettungs-Abbild nicht.
**F27** „Neu komprimieren" wird auch für verschobene (unkomprimierte) Vorgänge angeboten (`vorgaenge.ts:245`) — Klick endet in „Roh-Dateien sind nicht mehr da".
**F28** Automatik schweigt bei Typ `unknown`/`cd` (`automatik.ts:77`) — kein Grund im Kasten.
**F29** Ton: `--first-audio` nimmt je Sprache genau EINE Spur (`handbrake.ts:56`) — Kommentar- oder Stereo-Spuren derselben Sprache fallen weg. Bewusst? Dann ins Fenster schreiben.
**F30** Audio-CD: `audioSpurLesen` blockiert den Kern synchron je Spur (`disc.ts:200-220`) — Abbrechen wirkt erst zwischen zwei Spuren.

---

## 3. Auffälligkeiten (keine Fehler, aber wissenswert)

**A1 · Der „Datenbank-Befund vom 01.09." ist gelöst — ein Messartefakt.**
Das Terminal der Claude-Desktop-App läuft in einem MSIX-Paket; alles,
was daraus startet, sieht `%APPDATA%`, `%LOCALAPPDATA%` und `HKCU`
virtualisiert (Schattenkopie unter
`%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\…`). Deshalb
zeigte `%APPDATA%\Rippy\rippy.db` hier Schema 3 vom 01.09. — die ECHTE
Datei (über `\\localhost\C$\…` gelesen) ist Schema 4, 36 864 Bytes, Stand
04.09. 22:02, mit allen Einstellungen. Rippy ist unschuldig. Folge: die
Lizenzzeilen 5054/5051 in `beweise/messungen/2026-09-03-makemkvcon-info-kizuna.txt`
kamen aus dem Paket-Register ohne Schlüssel — kein Beleg für deinen
echten Zustand. (Als Gedächtnis-Notiz für künftige Sitzungen hinterlegt.)

**A2 · Rippy schreibt in MakeMKVs eigene Einstellungen** (`HKCU\Software\MakeMKV`:
`app_Key`, `app_DefaultSelectionString`, `app_UpdateEnable`). Damit
nimmt auch das MakeMKV-GUI seitdem ALLE Spuren mit (größere Dateien beim
Handbetrieb) — beabsichtigt, aber nirgends im Fenster gesagt.

**A3 · Das Rettungs-Abbild ist bei AACS-Discs (Blu-ray/4K) ungeprüft.**
Ein Sektor-Abbild bleibt verschlüsselt; ob makemkvcon es als `iso:` ohne
Laufwerk öffnet, hängt an MakeMKVs Schlüsseldaten. Bei DVDs (CSS) sollte
es gehen. Am Gerät messen, bevor es jemand im Ernstfall braucht.

**A4 · 4K wird standardmäßig komprimiert** — mit dem 8-Bit-Preset
„H.265 … 2160p 4K" bzw. auf CPU mit „H.265 MKV 1080p30" (`presets.ts:23-49`,
`preset-empfehlung.ts:321-335`). HDR-Metadaten und 10 Bit gehen dabei
verloren, der Encode dauert Stunden. Das Docker-Rippy hatte „4K
verlustfrei" als Regel. Entscheid nötig: Standard „keine" für UHD oder
ein 10-Bit-Preset.

**A5 · Toter Schlüssel `transcodePreset`** in `presets.ts:47-48` — seit
5.5.0 nicht mehr in `PIPELINE_EINSTELLUNGEN`, kann nie greifen.

**A6 · Titel-Lesen: 300 s fest verdrahtet**, kein Regler, Meldung nennt
die Disc „beschädigt" (`erkennung.ts:354-356`) — siehe Kandidat 2.

**A7 · Der Klick-Beweis und die 450 Tests sind gut, aber blind für genau
die Funde oben:** kein Test mit Bestandsdateien im Season-Ordner, keiner
für mehrfaches `runde()`, keiner mit einem Key mit `@`, keiner für den
Rip-Start ohne Ablage, keiner für den Kern-Neustart.

**A8 · Sicherheit/Härtung ist sonst gut:** contextIsolation + sandbox im
Fenster, CSP im Bau, keine Shell-Aufrufe mit Nutzerdaten, PowerShell-
Pfad wird korrekt gequotet, Update nur über HTTPS.

---

## 4. Vorschläge zur Verbesserung — in dieser Reihenfolge

1. **F1 sofort** (eine Zeile plus Test, plus rote Ampel) — vor dem 30.09.
   ist das der einzige Fund, der beide PCs betrifft.
2. **F2 + F4 + F6** — die drei „stillen" Fehler; jeder ist klein, alle
   drei kosten Vertrauen („tut nichts, sagt nichts").
3. **F3** — Serien mit mehr als einer Disc gehen sonst kaputt; Test mit
   vorhandenen Dateien im Ordner dazu.
4. **F8 + F9** — Aufräumen, das nicht zu viel und nicht zu wenig löscht.
5. **Kandidat 2** — Titel-Lesen-Grenze auf 10–15 min, Meldung ehrlich
   („die Disc braucht länger — läuft weiter / abbrechen"), Grenze in den
   Einstellungen.
6. **F7** — Fortschritt von Vorgangs-Stand trennen; spürbar auf NAS.
7. **F14** — Originaltitel + Akzente: schlägt sich direkt in der
   Trefferquote der Automatik nieder.
8. **F10/F11/F12/F13** — sichtbare Kleinigkeiten, je ein halber Nachmittag.
9. **F15/F17** — zwei Rückfragen, die Daten retten.
10. **A4** — dein Entscheid zu 4K.

---

## 5. Was gemessen wurde (nachvollziehbar)

* Typprüfung und Tests: `npm run typecheck`, `npx vitest run` — grün
  (450 bestanden, 12 übersprungen).
* Sonden gegen den echten Code (Vitest, außerhalb des Repos):
  S1 Akzente/Originaltitel · S2 Episoden-Umbenennung mit Bestand ·
  S3 Wache-Takt-Ketten (9 statt ~5 Runden) · S4 Typ-Zuordnung ·
  S5 UTC-Anzeige · S6 Labels der drei Filme · S7 99-Titel-Muster ·
  S8 `halbeDateienEntfernen` · S9 Beta-Key von der echten Forum-Seite ·
  S10 Rip-Start mit unerreichbarer Ablage.
* Electron 44: utilityProcess überlebt unbehandelte Promise-Ablehnung
  (zwei Läufe, mit und ohne Horcher).
* Forum-Seite t=1053 heute geladen: Key mit `@`, „valid until end of
  September 2026".
* Echte `rippy.db` dieses PCs über `\\localhost\C$`: Schema 4,
  `makemkvAppKey` 68 Zeichen mit `@`, `ablage E:\Rippy`, `automatik aus`,
  Jellyfin, TMDb- und OMDb-Schlüssel gesetzt, keine Vorgänge (Verlauf
  leer), Bibliothek leer.
* Protokolle dieses PCs (02.–05.09.): Rippy 5.5.0 → 5.6.0 → 5.6.1,
  Kizuna erkannt (95 %), Titel-Lauf 22–92 s, Laufwerk G am 02.09. mit
  „2 Controllerfehler, 112 fehlerhafte Blöcke" (siehe F11 — ob das dein
  BU40N war oder eine Platte, weiß der Bericht nicht).
* `makemkvcon64 -r --noscan info disc:9999` heute: nur 5042/5010 — ohne
  Laufwerk keine Lizenzauskunft (F5).

Nichts davon hat etwas am Repo, an deinen Einstellungen oder am Register
verändert; die Sonden liegen im Sitzungs-Scratchpad.