HitonabiandClaude Fable 5.1
f5dab5d1c1
Die sechs Punkte des Commanders vom 02.09.2026 abends und seine Entscheide:
* Restzeit der Kompression aus HandBrakes eigener ETA-Klammer (Formatstring
aus dem Binary 1.11.2 gelesen), KompressionStand.restS.
* Kachel zeigt nach dem Rip nur noch eine Zeile — Balken, Prozent, Ziel in
der Kompressions-Karte und im Verlauf ("nur in der Kompressions-Karte").
* Kopfzeile bleibt beim Scrollen stehen (sticky), Sektionswahl darunter.
* Untertitel-Vorwahl je Extra ("NUR für Extras, IMMER OPTIONAL"): welche
Untertitel-Spur beim Abspielen an ist — weiche Spur, nie eingebrannt;
RipAuftragTitel/RohDatei.untertitelVorwahl, sprachwahl.
* Mehrere Filme je Disc: "anderer Film …" je Titel mit TMDb-Suche;
filme.ts filmGruppen trennt am Rip-Ende in eigene Roh-Ordner, Vorgänge
und Kompressions-Aufträge mit voller Zuordnung (erkennung.zuordnungAus).
* Roh-Ordner und Dateien tragen den Filmnamen (filme.ts rohOrdnerName,
ablage/dateinamen.ts: Akira (1988).mkv, - Fassung n, - Extra nn).
* Hell-Modus: Einstellung design (dunkel/hell/system), data-design auf
<html>, Token --color-tinte statt white/-Alpha-Klassen.
* Vorgangs-Leiste (Commander: "Phase 1–4 plus Komprimierung — zu einem
machen"): gemeinsam/vorgangsleiste.ts + uebersicht/VorgangsLeiste.tsx,
vier Stationen (Rettung als Zwischenstation), Segment-Balken in der
aktiven Station; Kachel, Kompressions-Karte, Verlauf. PHASE-x/4-Texte weg.
* Automatik-Kasten leert sich, sobald ein Rip startet.
Beweise: 446 Tests (neu: filme, dateinamen, vorgangsleiste; erweitert:
auftrag, handbrake, automatik, ablegen), drei Typprüfungen, Klick-Beweis
33 Schritte inkl. Vorwahl, anderer Film, Vorgangs-Leiste, Restzeit,
Hell-Modus (Bilder beweise/klick/01…11).
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Beweise — die Messungen zu KONZEPT-WINDOWS.md § 3
Diese zwei Skripte sind die Grundlage für die Entscheidung, Rippy v5 in TypeScript/Node zu bauen. Sie beantworten die einzige Frage, an der das ganze Konzept hängt:
Kann Node überhaupt alles, was Rippy am Laufwerk braucht?
Wäre die Antwort nein gewesen, wäre das Konzept wertlos gewesen. Deshalb sind sie zuerst gelaufen — vor der ersten Zeile Konzept.
AGENTS.md Regel D: „Externe Schnittstellen NIE aus dem Kopf."
Nachstellen
npm install koffi
node laufwerk.js
Gemessen am 30.08.2026 mit Node v24.19.0, koffi 3.1.6, an einem HL-DT-ST BD-RE BU40N (USB) mit eingelegter Blu-ray.
laufwerk.js — Win32-Laufwerkszugriff
Ruft dieselben Steuercodes auf wie src/rippy/drives/win_ioctl.py im
Docker-Zweig. Nur lesend — kein Auswerfen, kein Verriegeln.
1. GetLogicalDrives + GetDriveTypeW -> optische Laufwerke: [ 'G' ]
2. CreateFileW \\.\G: (Zugriff 0) -> offen
CreateFileW \\.\G: (GENERIC_READ) -> offen
3. IOCTL_STORAGE_QUERY_PROPERTY -> Hersteller: HL-DT-ST | Modell: BD-RE BU40N
| Rev: 1.03 | Serial: 0025114C0149
4. IOCTL_STORAGE_CHECK_VERIFY2 -> Medium eingelegt
5. IOCTL_CDROM_DISK_TYPE -> Win32-Fehler 50
6. IOCTL_DISK_GET_LENGTH_INFO -> 33.759.690.752 Bytes (33,76 GB) => Blu-ray
Punkt 5 ist kein Fehlschlag. Fehler 50 ist ERROR_NOT_SUPPORTED — genau
das, was der Python-Treiber an diesem Laufwerk auch sieht (SAVEPOINT.md,
v4.0-rc11, Abschnitt „Das Laufwerk"). Node verhält sich identisch. Die Lehre
steht im alten Code und gilt weiter: Die Disc-Einordnung darf sich nicht auf
IOCTL_CDROM_DISK_TYPE verlassen — die Größe ist der verlässliche Weg.
Punkt 2 zeigt die Unterscheidung, die in rc11 teuer war: Zugriff 0 fragt das
Gerät, GENERIC_READ fragt das Medium. Bei einer gestörten Disc
scheitert das zweite und das erste geht weiter — wer nur eins probiert, hält
ein antwortendes Laufwerk für tot.
leine.js — die Prozess-Leine (Job Object)
Stellt den Befund aus SAVEPOINT.md v4.0-rc10 nach: Windows räumt
Kindprozesse nicht auf. Ein hart beendeter Rippy hinterlässt ein
makemkvcon, das das Laufwerk festhält, und jeder spätere Rip scheitert.
Das Skript setzt eine Arbeitsgruppe mit JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE,
startet ein langlebiges Kind und lässt sich dann hart abschießen —
taskkill /F ohne /T, also genau das, was bei einem Absturz und beim
Drüber-Installieren passiert.
1. CreateJobObjectW -> Arbeitsgruppe angelegt
2. SetInformationJobObject -> KILL_ON_JOB_CLOSE gesetzt
3. AssignProcessToJobObject -> dieser Prozess hängt in der Gruppe
4. Kindprozess gestartet, PID 16040
vor dem Abschuss: Eltern lebt: True Kind lebt: True
taskkill /F /PID 29488 -> ERFOLGREICH
danach: Eltern lebt: False Kind lebt: False
Nachstellen (PowerShell):
$p = Start-Process node -ArgumentList "leine.js" -PassThru -RedirectStandardOutput out.txt
Start-Sleep 3
$kind = (Select-String -Path out.txt -Pattern 'KIND-PID=(\d+)').Matches[0].Groups[1].Value
taskkill /F /PID $p.Id
Start-Sleep 2
Get-Process -Id $kind -ErrorAction SilentlyContinue # muss LEER sein
sqlite-main.js + sqlite-kern.js — node:sqlite in Electron
Beantwortet die Frage, die in der ersten Fassung des Konzepts als ⚠️ offen
stand: Electron baut sein Node mit eigenen Flags — ist node:sqlite dort
überhaupt vorhanden?
Gemessen am 30.08.2026 mit Electron 44.0.0, und zwar im
utilityProcess — dem Kontext, in dem Rippy v5 seine Datenbank betreiben
wird (kern/speicher/db.ts), nicht bloß im Node-Modus der Binary:
KERN-ANTWORT: {"ok":true,"wert":"geht","node":"24.18.1"}
Kern beendet mit 0
Antwort: ja. Die im Konzept vorgesehene Rückfallebene better-sqlite3
wird nicht gebraucht. (Zur Einordnung: In Node 24.19.0 pur war dieselbe
Messung zuvor ebenfalls grün.)
Nachstellen:
npm install electron@44 --no-save
node node_modules/electron/install.js
./node_modules/electron/dist/electron.exe sqlite-main.js
Die zweite Zeile ist kein Versehen — siehe nächster Abschnitt.
npm 11 blockiert Install-Skripte — und das trifft Electron selbst
npm warn allow-scripts koffi@3.1.6 (install: node ./cnoke.cjs -P . --prebuild --release)
koffi lädt trotzdem — es bringt vorgebaute Binärdateien mit. Electron
trifft die Sperre härter: Sein Install-Skript lädt die eigentliche
Programmdatei herunter; wird es geblockt, liegt nach npm install ein
Paket ohne dist/electron.exe da, und nichts startet. Am 30.08.2026
beim sqlite-Beweis selbst hineingelaufen; node node_modules/electron/install.js
holt die Binary nach. Beides gehört in die Bau-Anleitung, sonst sucht eines
Tages jemand an der falschen Stelle.