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

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.