From 6f1add480ea7505228c1941aa25ca1c0073700f0 Mon Sep 17 00:00:00 2001 From: Hitonabi Date: Sat, 12 Sep 2026 21:13:40 +0200 Subject: [PATCH] =?UTF-8?q?docs:=20Durchsicht=2012.09.2026=20=E2=80=94=20B?= =?UTF-8?q?ericht=20mit=2030=20Funden,=20f=C3=BCnf=20Ursachen-Kandidaten?= =?UTF-8?q?=20f=C3=BCr=20die=20drei=20Filme,=20Messungen?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- beweise/berichte/2026-09-12-durchsicht.md | 384 ++++++++++++++++++++++ 1 file changed, 384 insertions(+) create mode 100644 beweise/berichte/2026-09-12-durchsicht.md diff --git a/beweise/berichte/2026-09-12-durchsicht.md b/beweise/berichte/2026-09-12-durchsicht.md new file mode 100644 index 0000000..d8fdf7d --- /dev/null +++ b/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\\` — 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 `` — 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.