docs: Durchsicht 12.09.2026 — Bericht mit 30 Funden, fünf Ursachen-Kandidaten für die drei Filme, Messungen

Kompletter Check von Kern, Haupt und Fenster (5.6.1). Wichtigster Fund:
der Forum-Beta-Key vom September enthält ein @, Rippys Muster schneidet
ihn ab, MakeMKV läuft dann unlizenziert. Dazu: stiller Rip-Start ohne
Ablage, Serien-Disc-2-Umbenennung, tauber Kern-Neustart, Wache-Takt-
Ketten, Vorgangs-Stand pro HandBrake-Tick. Der Datenbank-Befund vom
01.09. war ein Messartefakt der MSIX-Schattensicht des Claude-Terminals.

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

beweise/berichte/2026-09-12-durchsicht.md

@@ -0,0 +1,384 @@
+# 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.