8 Commits

Include renames

Author	SHA1	Message	Date
HitonabiandClaude Fable 5.1	6dd1b0bc7a	feat(v5): Ein Smoke-Beweis, der KLICKT — Playwright durch das echte Programm ... WAS: `npm run klick` startet das ECHTE Rippy (Electron, Haupt, Kern, Fenster, Datenbank) mit eigenem Profil (--profil, --klick-smoke: ohne Tray, Updater, Toasts), einem nachgebauten Laufwerk (RIPPY_FAKE_LAUFWERK) und nachgebauten Werkzeugen (bau/klick/fake-*.cjs) — und klickt sich durch: Rippen → Dialog → Sprachen je Titel (jpn statt deu) → Rollen auf Folge → Staffel 1, ab Folge 3 → Vorschau → Rip → Warteschlange → Kompression → Ablage als S01E03/S01E04 unter Serien\…\Season 01 → Einstellungen/Roh-Dateien → Roh loeschen → Ereignisse. Bilder liegen in beweise/klick/. Die Naht dafuer (kern/werkzeuge/aufruf.ts): Zeigt ein Werkzeug-Pfad auf ein Node-Skript, laeuft es ueber die eigene Laufzeit (ELECTRON_RUN_AS_NODE) — fuer EXE-Pfade aendert sich nichts. WARUM: Beide Fehler vom 01.09.2026 waren Verkabelung; 261 Unit-Tests sahen keinen. Der Klick-Beweis haette beide gefunden. NEBENBEFUND: Die CSP blockte eingebettete Schrift-Teile (data:-Fonts der fontsource-Pakete) — Konsolenfehler im gebauten Fenster, jetzt font-src. Dazu test/messung.spuren.test.ts: HandBrake-Scan einer echten Roh-Datei auf Verlangen (RIPPY_MESSUNG_MKV). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>	2026-09-01 22:22:04 +02:00
HitonabiandClaude Fable 5.1	3f7f962dff	feat(v5): Kern 5.4.0 — Vorgaenge, Kompressions-Warteschlange, Roh-Aufraeumen, Sprachen je Titel, Erkennung v2 ... WAS: Der Rip endet, sobald die Roh-Dateien liegen; die Kompression laeuft danach in einer Warteschlange (eine zur Zeit), das Laufwerk ist frei fuer die naechste Disc. Jeder Rip ist jetzt ein Datensatz (Tabelle vorgaenge, Schema 4): Roh-Ordner, Zielordner, Phase, Auftrag als JSON. Darauf bauen: Roh-Aufraeumen nach Regel (Vorgabe 7 Tage, nur bei gelungener Kompression und nur wenn jede fertige Datei da und nicht leer ist), Wiederholen ab Kompression, Aufraeumen halber Dateien nach Abbruch/Fehler, Wiederaufnahme nach Neustart. Unkomprimierte Rips (4K, kein HandBrake) werden in den Zielordner VERSCHOBEN statt unter roh\ liegen zu bleiben. Sprachen je Titel reisen vom Info-Lauf (SINFO) bis in HandBrake; fremder Ton schaltet den deutschen Untertitel vor (--subtitle-default=1). Vor der Kompression prueft ein HandBrake-Scan die Roh-Datei. MakeMKVs Auswahlregel wird gesetzt, wenn keine steht, damit alle Sprachen in die Roh-Datei kommen. Staffel und erste Folge von Hand schlagen die Laufzeit-Raterei. Durchgehender Fortschritt, nach Groesse gewichtet. Erkennung v2: leere TMDb-Eintraege (Stubs) zaehlen nicht, Laufzeit wird nach dem Info-Lauf gegen TMDb gehalten, Titel-Struktur als Fingerabdruck, bdmt_deu als zweite Titel-Variante. TMDb liefert Logo, Tagline, Bewertung, FSK und Besetzung in derselben Anfrage. Laufwerks-Gesundheit aus dem Windows-Ereignisprotokoll (wevtutil): Disc oder Hardware. WARUM: Uebergabe-Punkte 1-5, 8-12 des SAVEPOINT vom 01.09.2026 — vom Commander gutgeheissen (7 Tage / Untertitel vorgewaehlt / entkoppelte Kompression waren seine Wahl). GEMESSEN (Regel D): HandBrake 1.11 Sprach-Schalter an einer ffmpeg- Testdatei (jpn/deu/deu/eng + deu/eng), HandBrake --scan --json Format, TMDb movie/149 + tv/46296 mit append_to_response, wevtutil /f:xml an diesem PC (338x cdrom 7, 8x cdrom 11 in 30 Tagen), makemkvcon --minlength, MakeMKV-Auswahlregel laut forum.makemkv.com t=4386. 348 Tests gruen (vorher 261), Typpruefung und Bau gruen. Oberflaeche folgt im naechsten Schritt. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>	2026-09-01 22:02:03 +02:00
HitonabiandClaude Opus 5	6d149212c9	fix(v5): Nur der NEUESTE Titel-Lauf antwortet — ein alter legte sich darueber ... Commander: "Er liest es korrekt ein, ich bekomme auch die auswahl aber kurz danach kommt dieser fehler" — "makemkvcon info: keine Antwort nach 300 s", MINUTEN nach der fertigen Titelliste. Mit nur einem Lauf ist das unmoeglich: Der Timeout wird bei 'close' geloescht. Es waren also zwei Laeufe unterwegs, und der aeltere meldete verspaetet seinen Abbruch — auf die laengst gelieferte Liste drauf. Behoben, je Laufwerk: * Ein neuer Lauf LOEST den alten AB: AbortController im Kern, titelInfoLesen nimmt jetzt ein AbortSignal, killt das Kind und lehnt mit der Marke ABGELOEST ab. Das Laufwerk ist sofort frei, und es laufen nie zwei makemkvcon auf derselben Disc. * Nur die NEUESTE Laufnummer darf antworten (titelLaufNummern) — eine verspaetete Antwort wird verworfen, nicht angezeigt. * Ein abgeloester Lauf SCHWEIGT: abgeloest ist Absicht, kein Fehlschlag. * Laeuft es wirklich in den Timeout, steht jetzt ein Satz statt einer Fehlermeldung: Bei einer beschaedigten Disc kann das Lesen ueber fuenf Minuten brauchen; Rippy beendet den Versuch und gibt das Laufwerk frei. Am lebenden Objekt bestaetigt (SPARTACUS_GOTA_D1, Commander-Screenshot): "Serie: 2 Folgen erwartet, 2 gefunden - passt." | Titel 0 52:47 min 16,28 GB 7 Kap. | Titel 1 54:09 min 16,67 GB 7 Kap. | beide Rolle Folge | 2 von 2 gewaehlt, zusammen 32,95 GB — und KEIN Timeout hinterher. Die Laengen liegen 2,5 Prozent auseinander, also weit innerhalb von AEHNLICH (15 Prozent) — deshalb "passt" ohne Unsicherheits-Warnung. 261 Tests gruen, Typpruefung sauber. Version 5.3.2. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-01 20:29:25 +02:00
HitonabiandClaude Opus 5	9622f4e6ef	fix(v5): Der Kern verwarf 'titel-lesen' STILL — Auswahl-Dialog hing ewig ... Commander: "das funktioniert nicht, du kannst gerne am lebenen objekt pruefen". Der Dialog blieb bei "Rippy liest die Titel der Disc ..." stehen, ohne Fehler, ohne Ende. Ursache, am lebenden Objekt gemessen: NICHT der Info-Lauf. makemkvcon -r --noscan info dev:G: -> 0,8 s, TCOUNT:0 MSG:5042 "konnte keine verwendbaren optischen Laufwerke finden" Der Lauf antwortet also sofort. Der Fehler lag in MEINEM Code von 5.2.0: istFensterNachricht() kannte 'titel-lesen' und 'rip-ueberspringen' nicht — beide standen in der FensterNachricht-Union, aber nicht im Pruefer. Der Kern verwarf sie mit `if (!istFensterNachricht(frage)) return`. STILL. Genau die R4-Wunde, vor der die Hausordnung warnt. Auf drei Ebenen behoben: 1. Der Pruefer kennt beide Nachrichten. 2. Eine verworfene Nachricht ist jetzt LAUT: console.error plus kern-fehler ins Fenster mit der Art, die verworfen wurde. 3. Neuer Waechter-Test (waechter.test.ts): Er liest das Schema und vergleicht JEDE `art: '...'` der Unions mit dem jeweiligen Pruefer; dazu prueft er, dass der Kern nicht mehr still verwirft. GEGENPROBE gemacht: Mit zurueckgenommener Reparatur schlaegt er fehl ("expected [ 'titel-lesen' ] to deeply equal []"), mit Reparatur ist er gruen. Kein Deko-Test. Dazu: Der Info-Lauf reicht die URSACHE durch (DiscInfo.ursachen aus den kritischen MSG-Nummern). Kam nichts heraus und MakeMKV hat einen Grund genannt, steht im Dialog der Grund statt "keine Titel gefunden" — beim 5042-Zustand also die Abhilfe (Disc neu einlegen, Laufwerk ab- und anstecken, notfalls neu starten) statt eines Fingerzeigs auf die Disc. Neu test/messung.titelwahl.test.ts — faehrt am echten Laufwerk genau den Weg des Kerns nach (Info-Lauf, Vorauswahl, Dialog-Fehlertext). Zweimal in dieselbe Heredoc-Falle getappt (AGENTS.md warnt davor): Escape-Sequenzen wurden halbiert, ein rohes CR landete in makemkv.ts. Beides korrigiert; der Hygiene-Waechter haette das CR auch gefangen. 260 Tests gruen (vorher 257), Typpruefung sauber. Version 5.3.1. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-01 20:12:44 +02:00
HitonabiandClaude Opus 5	7ce06889f8	feat(v5): Serien-Staffelablage und Film-Extras — die Rolle bestimmt das Ziel ... Commander (01.09.2026): "Mach das gerne noch mit den Serien." und "Fuer FILME sollte so eine auswahl auch gelten z.B. Nur hauptfeature oder hauptfeature + extras usw. Rippy muss das auch selbst zusammenbasteln." Wieder lagen die Teile fertig herum und waren nur nicht verbunden: serienOrdner(), matcheEpisoden(), episodenUmbenennen() (struktur.ts) und tvStaffel() (tmdb.ts) sind gebaut UND getestet — aufgerufen hat sie niemand. Folgen landeten deshalb unter Filme/, und Jellyfin sah lauter Einzelfilme statt einer Staffel. Neu: jeder Titel im Auftrag traegt eine ROLLE (gemeinsam/nachrichten.ts, EINE Definition fuer Kern und Fenster): hauptfilm -> Filme/<Titel> (Jahr)/<Titel> (Jahr).mkv extra -> Filme/<Titel> (Jahr)/extras/... folge -> Serien/<Titel>/Season NN/... S01E02.mkv * Rippy schlaegt die Rolle vor (Serie -> Folge, Film -> Hauptfilm, Rest -> Extra), im Dialog ist sie je Titel aenderbar. * Die Zuordnung Datei->Rolle ist EXAKT, nicht aus Dateinamen geraten: Je makemkvcon-Lauf kommt genau ein Titel dazu, und genau der bekommt die Rolle des Auftragseintrags. * Extras liegen im Unterordner "extras" neben dem Film — die Konvention, die Jellyfin, Emby und Kodi als Zugaben lesen. Der Ordner entsteht nur, wenn es wirklich Extras gibt. * Neuer Schnellwahl-Knopf "Hauptinhalt + Extras": alles Sehenswerte, aber weder Sammeltitel noch Logos/Alterskennzeichen. Episoden-Nummern: Die Laufzeit jedes gewaehlten Titels reist im Auftrag mit (RipAuftragTitel.dauerS), die Staffel-Laufzeiten kommen ueber einen injizierten Rueckruf von TMDb (tvStaffel). matcheEpisoden() benennt NUR bei EINDEUTIGER Zuordnung um. Sonst behalten die Dateien ihre Namen, und Rippy SAGT warum — entweder "keine Staffel-Laufzeiten von TMDb" oder "nicht eindeutig zuzuordnen". Lieber gar nicht als falsch; das war ARMs offene Wunde #395. Die Staffel-Nummer kommt aus dem Disc-Titel (discZusatzAbtrennen, seit 5.1.1) — sonst 1. 257 Tests gruen (vorher 254), Typpruefung sauber. Version 5.3.0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-01 19:37:10 +02:00
HitonabiandClaude Opus 5	a8e8b2bef3	feat(v5): Titel auswaehlen statt immer alles — und ein Defekt kostet nicht mehr alles ... Commander (01.09.2026): "es fehlt generell noch komplett die auswahl WAS man rippen moechte. Bei Serien eben genau das die folgen, bei filmen z.B. nur das hauptfeature oder auch die extras." Bis hierher uebergab die Pipeline fest `titel: 'all'` — Rippy rippte IMMER alles, samt Trailer, Werbung und Alterskennzeichen. Beide Wuensche brauchen denselben Umbau, deshalb in einem Zug: TITEL FUER TITEL statt einem 'all'-Aufruf. Nur so laesst sich auswaehlen, und nur so ueberlebt der Rest, wenn EIN Titel an einem Disc-Defekt haengt. Was schon da war und nur nicht verbunden: titelInfoLesen() (Titel mit Dauer/Groesse/Kapiteln) rief niemand auf, und buildRipArgs() konnte laengst einen einzelnen Titel. Dazu kennt Rippy seit heute das Inhaltsverzeichnis der Disc (EP 1, EP 2, DUB GER 1, 104 GER FSK). Neu kern/rip/titelwahl.ts (pur, ohne Laufwerk): * Serie (von der Disc BEZEUGT): so viele Titel wie das Inhaltsverzeichnis Folgen nennt; passen sie nicht zusammen, sagt Rippy das. * Film: der laengste Titel. * Zwei Fallen mit Tests abgesichert: - SAMMELTITEL: Ein Titel, der so lang ist wie die anderen zusammen ("alle Folgen am Stueck"), waere der laengste und wuerde die Film-Auswahl gewinnen — Rippy wuerde alles doppelt sichern. - ANGEL/Seamless Branching: Mehrere fast gleich lange Fassungen. Rippy nimmt die mit den meisten Kapiteln UND sagt, dass es unsicher ist. * Unklar heisst: nichts vorausgewaehlt. Lieber fragen als raten. Der Defekt-Waechter: * offsetAusMeldung() liest die Stelle aus MakeMKVs Meldung — als LETZTE gequotete Zahl, damit es unabhaengig von MakeMKVs Sprache bleibt (deutsch "bei Offset", englisch "at offset"). * RipAuswertung zaehlt Wiederholungen derselben Stelle; ab HAENGT_AB gilt der Lauf als haengend. Fortschritt raeumt den Verdacht wieder ab. * Das Fenster zeigt dann Klartext plus "Titel ueberspringen" — der laufende makemkvcon wird beendet, der naechste Titel laeuft weiter. Gemessen am lebenden Objekt (Spartacus Disc 2, 01.09.2026): MakeMKV meldete eine halbe Stunde denselben Offset 56881152, makemkvcon verbrauchte dabei 1,7 s CPU (es wartete), und Windows protokollierte 41 fehlerhafte Bloecke in 10 Minuten. Der Defekt lag in Folge 1 — Folge 2 lag heil daneben und ging trotzdem verloren. 17 neue Tests in test/titelwahl.test.ts, alle beim ersten Lauf gruen. 254 Tests gesamt (vorher 237), Typpruefung sauber. Version 5.2.0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-01 19:22:55 +02:00
HitonabiandClaude Fable 5	2d9cef22b3	feat(v5): Etappe W-7 — Audio-CD, ISO-Backup, MakeMKV-Schluesselkette ... rip/audiocd.ts: die Rechnungen PUR (MSF→LBA mit den 150 Vorlauf-Frames, TOC-Zerlegung mit Lead-Out-Pflicht und Daten-Track-Bit, 27-Sektoren- Bloecke unter der 64-KB-Treibergrenze, RAW_READ_INFO mit DiskOffset in 2048ern OBWOHL der Sektor 2352 hat, WAV-Kopf, AC/DC-sichere Namen). metadaten/musicbrainz.ts: DiscID nach musicbrainz.org-Rechnung — gegen die ECHTE AC/DC-Kennung getestet (3KVSIWn_…), Vorlauf wird beim Melden wieder HINZUgerechnet; Tags je Spur mit Bindewort-Kuenstlern. laufwerk/disc.ts: audioToc + audioSpurLesen ueber die LaufwerkApi. rip/iso.ts (§ 6.4): 1:1-Abbild fuer unbekannte Discs — async (ein 33-GB-Abbild darf den Kern nicht blockieren), sektor-ausgerichtet, unvollstaendig heisst FEHLER mit Byte-Zahlen, nie Schoenfaerberei. werkzeuge/schluessel.ts (§ 9.1): Dauerlizenz schlaegt Forum-Beta-Key (t=1053, T-Muster aus makemkv_key.py), Ablage in HKCU ueber reg.exe (kein zweiter koffi-Ort), GEFRAGT statt gerechnet (makemkvcon info disc:9999, MSG 5020/5021/5051), abgelehnter Key wird ZURUECKGENOMMEN (schlimmer als keiner: 0 Titel, kein Laufwerk), app_UpdateEnable nur- wenn-fehlt (der 4K-Schluesselkanal). Kern prueft beim Start und taeglich; Dashboard-Kachel zeigt Stand + letzten Pruefzeitpunkt; Dauerlizenz-Feld in den Einstellungen. Pipeline verzweigt nach Disc-Typ: cd → Sektoren→WAV→FLAC mit MusicBrainz-Tags (Ordner 'Kuenstler - Album', ohne Treffer ehrlich 'Track NN'), unknown → ISO. Bibliothek-Eintraege fuer beide. 181 Tests gruen, Smoke gruen. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-30 18:56:07 +02:00
HitonabiandClaude Fable 5	844bca37ff	feat(v5): Etappe W-2 — Rippen: Parser, makemkvcon-Lauf, Werkzeug-Katalog ... rip/parser.ts: die reine Textverarbeitung mit allen bezahlten Fallen aus dem Docker-Zweig — quelle() (dev:G: statt dev:\.\G:, der 404-Verwandte), textVon() (UTF-8 streng, sonst cp1252 — nie wieder 'Öffnen'), parseMsg (Regex statt split — Meldungen mit Komma), PRGV (-1 vs. echtes 0 %), TINFO/SINFO (Sprache aus Attr 3/4, NICHT 28/29), laengsterTitel mit Play-All-Schutz, episodenTitel, KRITISCHE_CODES (sprachfeste NUMMERN). rip/makemkv.ts: Kommandobau + Lauf — ZeilenLeser (binaer, halbe Zeilen, je Zeile dekodiert), RipAuswertung (pur), rippen() mit AbortSignal, Lesefehler-Flag AUCH bei Rueckgabewert 0. werkzeuge/katalog.ts: die Suchreihenfolge samt %VAR%-Gross/Klein-Falle und Registry-Rueckfall. ablauf/rippen.ts: ein Rip je Laufwerk, Status-Push, 'erst nachsehen, dann rippen' (unbekannt heisst trotzdem rippen). Fenster: Rippen-Knopf, Fortschrittsbalken, Abbrechen; Auswurf waehrend des Rips abgelehnt. Gemessen am echten System (30.08.2026): Katalog findet makemkvcon64 (Program Files x86), HandBrakeCLI und flac (beide im rc11-Werkzeugordner LOCALAPPDATA\Rippy\tools). NEUER BEFUND: Nach dem abgebrochenen rc11-Rip vom Mittag sieht MakeMKV GAR KEIN Laufwerk mehr (MSG 5042, leere DRV-Liste, mit und ohne --noscan), waehrend die Storage-IOCTLs sauber antworten — MakeMKV spricht SCSI direkt. 5042 ist jetzt ein KRITISCHER_CODE mit Klartext-Abhilfe. Der volle Rip-Beweis (messung.rip.test.ts liegt bereit) braucht deshalb erst eine Hand am Geraet: Disc neu einlegen oder USB ab-/anstecken. 96 Tests gruen, Smoke gruen. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-30 18:12:44 +02:00