9 Commits

Include renames

Author	SHA1	Message	Date
HitonabiandClaude Fable 5.1	c46a280b1f	chore(v5): Version 5.4.0 — Aenderungsnotizen fuer latest.yml ... Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>	2026-09-01 22:24:19 +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 Opus 5	663127f854	feat(v5): Windows-Rand weg, Hardware-Empfehlung sichtbar, Wizard geradegezogen ... Vier Punkte des Commanders (01.09.2026): 1. "Ich hab noch den rand ich glaube der kommt aber von windows selbst" Stimmt. Ein rahmenloses Fenster behaelt unter Windows 11 den DWM-Rand — eine feine Linie, die der Fenstermanager zeichnet, nicht die Seite; mit CSS ist da nichts zu holen. Neu fensterrand.ts: DwmSetWindowAttribute mit DWMWA_BORDER_COLOR = DWMWA_COLOR_NONE. Gemessen: HRESULT 0, Windows nimmt es an. Runde Ecken bleiben (sie sind unter Windows 11 das Uebliche); ein Schalter fuer kantig ist da. Aeltere Windows antworten mit Fehler — der wird als Wert zurueckgegeben und protokolliert, nicht verschluckt (R4); dort gibt es den Rand schlicht nicht. Das ist der DRITTE erlaubte koffi-Ort. Waechter R1 kennt jetzt drei statt zwei Dateien; die Regel selbst ("Win32 nur an benannten Orten") bleibt und haelt alles andere weiter dicht. 2. "Die alte Version konnte automatisch anhand der gescannten hardware encoder das beste preset waehlen." Das KANN diese auch — presetEmpfehlung() waehlt nach den gemessenen Backends (VCN -> NVENC -> QSV -> CPU) und laeuft seit dem Kino-Mix. Man sah es nur nirgends ausser als Wort "automatisch:" in einem Auswahlfeld. Die Erst-Einrichtung zeigt jetzt die gemessenen Encoder als Badges und was daraus fuer DVD, Blu-ray und 4K wird — plus eine ehrliche Warnung, wenn nur CPU-Encoder da sind. 3. Feld "Update-Adresse" ist raus. Der Schluessel updateUrl gilt weiterhin (Datenbank), Paragraph 6.8 prueft ihn wie zuvor. 4. Erst-Einrichtung geprueft. Gefunden und behoben: * "Dieses Setup stellt vier Dinge ein" — es stellte ZWEI ein. * Der Ablage-Schritt zeigte eine LEERE Zeile, wenn nichts gewaehlt war. Es gibt aber eine Vorgabe (Videos\Rippy im Benutzerprofil) — die steht jetzt da. * Kein Wort zum TMDb-Schluessel, obwohl Schritt 1 "Rippy erkennt, was drauf ist" verspricht. Ohne Schluessel heissen Filme wie das Disc-Label. Jetzt ein eigener Schritt mit Eingabefeld. * Rohe HTML-Checkbox statt des Schalters aus dem Kino-Mix. * Kein Hinweis, dass Rippy im Infobereich weiterlebt. Neu sechs Schritte, drei Fragen — und die Zahl im Text stimmt. Dazu: #einrichtung als Beweis-Anker (RIPPY_START_BEREICH), sonst ist der Wizard nach dem ersten Start nicht mehr zu fotografieren und damit nicht mehr pruefbar. Beweis: beweise/ui-515-wizard.png 237 Tests gruen, Typpruefung sauber. Version 5.1.5. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-01 18:43:58 +02:00
HitonabiandClaude Opus 5	051cab3afa	fix(v5): Das Update installierte nie — die eigene Leine erschlug den Installer ... Commander: "Rippy wird zwar sauber beendet aber startet NICHT neu in der neuen version." Ursache, auf drei Beinen belegt: 1. Bibliothek: electron-updater startet den Installer per spawn(..., { detached: true }) (BaseUpdater.js, an der installierten Fassung nachgelesen). `detached` setzt unter Windows KEIN Breakaway. 2. Leine: leine.ts setzt KILL_ON_JOB_CLOSE, und Kinder erben die Mitgliedschaft. Der Installer war damit Mitglied der Arbeitsgruppe. 3. Platte: pending\RippySetup-5.1.3.exe lag geladen da (18:11:47), installiert war weiter 5.1.2. Der Download klappte, nur die Installation nicht. Der Installer starb also in genau der Sekunde, in der Rippy sich beendete, um ihm Platz zu machen. Fix — die Leine bleibt, der Installer klinkt sich aus: * leine.ts setzt zusaetzlich JOB_OBJECT_LIMIT_BREAKAWAY_OK. Das aendert fuer sich genommen NICHTS: Kinder erben weiter, ausser sie verlangen das Ausklinken selbst. Kern, makemkvcon und HandBrakeCLI bleiben angeleint, die rc10-Waisen-Falle (Paragraph 3.3) ist unveraendert zu. * Neu: ausserhalbDerLeineStarten() startet EIN Programm per CreateProcessW mit CREATE_BREAKAWAY_FROM_JOB. Liegt in leine.ts, weil dort die Arbeitsgruppe verwaltet wird — und weil Waechter R1 koffi nur dort und in kern/laufwerk/win32.ts erlaubt. * update.ts installiert jetzt SELBST: autoInstallOnAppQuit ist aus, der Installerpfad kommt aus downloadUpdate() (laut AppUpdater.d.ts "Paths to downloaded files"), die Argumente sind die von electron-updater gemessenen (--updated /S --force-run). Gestartet wird beim Beenden (will-quit) und ueber den Knopf. * Neu kommandozeile.ts (pur, ohne koffi/Electron): CreateProcessW nimmt EINE Zeichenkette. Ohne die Regeln von CommandLineToArgvW zerfiele ein Pfad wie "C:\Users\Tobi Neu\..." in zwei Argumente. BEWIESEN, nicht behauptet — neu: beweise/leine-breakaway.js OHNE Ausklinken (so macht es electron-updater) lebt nach dem Tod des Elternprozesses: NEIN -> WIE ERWARTET MIT Ausklinken (so macht es Rippy ab 5.1.4) lebt nach dem Tod des Elternprozesses: JA -> WIE ERWARTET Der erste Messlauf zeigte ein falsches Negativ: Der Enkel starb an der sterbenden KONSOLE des Elternprozesses, nicht an der Arbeitsgruppe. Erst mit CREATE_NO_WINDOW (eigene Konsole) misst der Versuch, was er messen soll. Diese Lehre steht als Kommentar im Code und der Flag ist auch im echten Aufruf gesetzt. 237 Tests gruen (vorher 230), Typpruefung sauber. Version 5.1.4. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-01 18:27:36 +02:00
HitonabiandClaude Opus 5	827910fd63	feat(v5): eigenes Fenster ohne Windows-Rahmen + Layout skaliert mit ... Zwei Befunde des Commanders (01.09.2026): 1. "Momentan ist alles nach links gerueckt, nichts skaliert mit der fenstergroesse und es ist alles gequetscht." Ursache gefunden: <main> hatte WEDER Zentrierung NOCH Maximalbreite, die Karten darin aber einen harten Deckel von max-w-2xl (672 px). In einem 1280er Fenster klebte damit alles am linken Rand und rechts stand nichts. Behoben: * <main> und Kopfzeile teilen sich mx-auto max-w-[1600px] mit mitwachsendem Innenabstand — der Inhalt ist mittig und nutzt die Breite. * Der 672-px-Deckel der Einstellungs-Spalte ist weg. Drei Encoder-Felder stehen jetzt nebeneinander statt untereinander. * Die Sektionswahl der Einstellungen wird im schmalen Fenster zur Zeile ueber den Karten (lg:flex-row), statt eine 176-px-Spalte vom ohnehin knappen Platz abzuziehen. * Info-Kacheln der Laufwerks-Karte: zwei Spalten schmal, vier breit. * Startgroesse 1000x700 -> 1280x820, Mindestmass 720x480 -> 860x560. 2. "waere sogar richtig cool wenn du den rahmen wegbekommst" frame:false, und die Kopfzeile IST jetzt die Titelleiste: Minimieren / Maximieren / Schliessen sitzen oben rechts in Windows-Massen (46x32), gezogen wird an der Kopfzeile, Doppelklick maximiert. Groesse aendern bleibt moeglich — Electron setzt fuer rahmenlose Fenster unter Windows weiter WS_THICKFRAME (thickFrame, Standard true), die Kanten ziehen also wie gewohnt. Schliessen nimmt GENAU den Weg des alten Fensterkreuzes (fenster.close() -> der bestehende close-Horcher versteckt nur): Rippy lebt im Tray weiter, ein laufender Rip merkt davon nichts (Paragraph 4.1 Punkt 3). Die Ziehflaeche ist .ziehbar in stil.css; alles Bedienbare darin traegt .nicht-ziehbar, sonst verschluckt der Griff den Klick. fensterMaximiert im HauptStatus entscheidet ueber das Knopf-Symbol und wird auch bei Doppelklick/Tastenkuerzel nachgefuehrt (maximize- und unmaximize-Horcher). Nachgemessen mit dem Smoke-Beweis: beweise/ui-513-uebersicht.png (kein Rahmen, eigene Knoepfe, Inhalt ueber die volle Breite) und beweise/ui-513-einstellungen.png (drei Encoder nebeneinander). 230 Tests gruen, Typpruefung sauber. Version 5.1.3. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-01 18:07:45 +02:00
HitonabiandClaude Opus 5	c0a7618e33	feat(v5): Update sichtbar machen — Meldung, Knopf und Changelog ... Der Commander: "irgendwie fehlt in rippy selbst der Button 'Auf updates pruefen' oder auch direkt beim start ne meldung 'ey jo update verfuegbar' - waere noch cool wenn das kommt inkl. changelog". Zu Recht. Der Kanal arbeitete korrekt, war aber UNSICHTBAR: Der Update-Stand lag im Haupt und wurde nur beim Laden des Fensters EINMAL mitgeschickt. Fand die Pruefung etwas, aenderte sich am Bildschirm nichts; der einzige Hinweis war ein Satz unter "Update-Adresse", den man kennen musste, um ihn zu finden. Was jetzt da ist: * Eine goldene Karte OBEN in der Uebersicht, sobald etwas gefunden wird — mit neuer Versionsnummer, der laufenden Version, Ladefortschritt und den Aenderungsnotizen. Dazu ein Windows-Toast beim Fund. * Knopf "Jetzt auf Updates pruefen" in den Einstellungen. Waehrend eines Rips ist er AUS, mit Begruendung im Tooltip — Rippy sucht dann bewusst nicht (Paragraph 6.8). * Knopf "Jetzt neu starten und installieren" auf der Karte, sobald das Paket geladen ist. Sagt NEIN mit Grund statt still nichts zu tun (R4). * Der Stand meldet JEDE Aenderung sofort ans Fenster (setzen() ruft immer beiAenderung) — kein Zustand mehr, den niemand erfaehrt. Der Changelog kommt aus bau/release-notes.md. An der installierten Bibliothek geprueft statt aus dem Kopf (Regel D): app-builder-lib out/publish/updateInfoBuilder.js getReleaseInfo() liest genau diesen Dateinamen und legt den Inhalt als releaseNotes in latest.yml; builder-util-runtime deklariert UpdateInfo.releaseNotes als "string | Array<ReleaseNoteInfo> | null". neuerungenText() vertraegt beide Formen, wirft HTML-Marken raus und deckelt die Laenge. UpdateStand ist jetzt EINE Definition in gemeinsam/nachrichten.ts, die sich Haupt und Fenster teilen. 230 Tests gruen (vorher 225), Typpruefung sauber. Version 5.1.2. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-01 17:51:38 +02:00