341 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
HitonabiandClaude Fable 5	d21332e3c7	docs: SAVEPOINT — Einstellungen-Karten und Version 5.1.0 ... Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> aktuell	2026-08-31 22:10:10 +02:00
HitonabiandClaude Fable 5	b64ddf5f06	feat(v5): Einstellungen als erklärende Karten-Seite — Version 5.1.0 ... Der Einstellungs-Tab im Kino-Mix, statt magerer Feldliste: links eine Sektions-Navigation, rechts Karten mit je einem Satz Einordnung — Ablage (mit Struktur-Vorschau Filme/Musik/ISO/roh), Kompression (Schalter, gemessene Encoder als Badges, Empfehlungs-Erklärung), Metadaten (Key-Quellen im Klartext, hinterlegt/fehlt-Punkte), MakeMKV (eigene Karte: Live-Schlüsselstand, Update- und Prüf-Knopf, Dauerlizenz), Medienserver, Programm (Schalter, Update-Stand, Versionszeile) und Werkzeuge — NEU mit den drei „Eigener Pfad'-Feldern (werkzeug.*, vom Katalog seit je unterstützt, bisher ohne UI). Dazu: #einstellungen/#bibliothek als Startanker (RIPPY_START_BEREICH), RIPPY_SMOKE_WARTE_MS für Bild-Beweise, die auf späte Kern-Antworten warten (Einstellungen+Encoder-Messung kommen nach den 750 ms). Version 5.1.0 — erste Fassung ohne Vorab-Suffix, der Bau erzeugt damit erstmals latest.yml (der Update-Kanal aus § 6.8). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-31 22:06:38 +02:00
HitonabiandClaude Fable 5	c12b1be448	docs: SAVEPOINT — Kino-Mix-Design durchgängig eingebaut ... Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-31 21:56:39 +02:00
HitonabiandClaude Fable 5	b9de2ba729	feat(v5): Kino-Mix-Design durchs ganze Fenster (Commander-Entscheid) ... Der auf dem Design-Canvas gewählte Mix aus Kinosaal und Schaltpult, durchgängig über Übersicht, Einstellungen, Bibliothek, Erst-Einrichtung und Dialoge: warmes Bühnen-Schwarz mit Saallicht und Filmkorn, Gold als Akzent, Poster mit Goldkante, Plakat-Titel (Bricolage Grotesque) — dazu die Schaltpult-Präzision: REC-Glühen bei laufendem Rip, Info-Kacheln (Medium/Größe/Erkennung/Preset inkl. der echten Preset-Kette), 20-Segment-Aussteuerungsanzeige mit großer Mono-Prozentzahl, Mono-Protokoll, LED-Systemleiste statt Status-Kacheln (Systemfehler werden zur roten Karte, R4). Schriften gebündelt via fontsource (OFL, bau/lizenzen) — zur Laufzeit lädt Rippy nichts aus dem Netz. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-31 21:54:23 +02:00
HitonabiandClaude Fable 5	98ca2855e9	docs: SAVEPOINT — MakeMKV-Selbst-Update und Kino-Look ... Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-31 20:20:13 +02:00
HitonabiandClaude Fable 5	d5ea48cd1e	feat(v5): MakeMKV-Selbst-Update (§ 9) und Kino-Look fürs Fenster ... Update-Strecke: Quellenkette (Hersteller 525 → Forum → Archiv, höchste gewinnt, 31.08. nachgemessen), MZ- + Versions-Ressourcen-Prüfung (GuinpinSoft inc, gemessen), Download in .neu, Start übers Haupt (shell/UAC — Installer hängt bewusst NICHT an der Leine), Warte-Poll bis die EXE-Version wechselt, dann Schlüssel neu prüfen. Ehrlicher Zweig: installierte == neueste Fassung → kein sinnloser Download. Fenster: Laufwerks-Kachel als Bühne (TMDb-Backdrop, Poster, Beschreibung, Phasen-Label, Restzeit, aufklappbares Protokoll), Bibliothek als Poster-Regal (DB-Schema 3: poster_pfad, Migration), Schlüssel-Karte mit Update-Knopf und Beschaffungs-Balken, MakeMKV-Version als Badge. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-31 20:18:08 +02:00
HitonabiandClaude Fable 5	5622d8e47d	docs: SAVEPOINT — erster Commander-Test, drei Funde behoben ... Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-30 20:23:55 +02:00
HitonabiandClaude Fable 5	c5dd90cc18	fix(v5): Die drei Funde aus dem ersten Commander-Test ... FUND 1 — 'Key korrekt, aber als ungueltig angezeigt': Stimmt beides. Live gemessen: Der aktuelle Forum-Key ist in Ordnung, aber MakeMKV 1.18.4 ist ZU ALT fuer ihn — makemkvcon meldet 5020 UND 5021 zusammen, und die alte Pruefung brach beim ersten Code ab und beschuldigte den Schluessel. urteilAusAusgabe sammelt jetzt ALLE Codes (5021 schlaegt 5020, MakeMKV-Version aus MSG 1005 wird mitgelesen) und die Kachel sagt den wahren Satz: 'Der Key ist in Ordnung — MakeMKV 1.18.4 ist zu alt. Rippy hat ihn entfernt, damit der Beta-Modus weiterlaeuft (Rips klappen trotzdem). Abhilfe: MakeMKV aktualisieren.' Neues Feld weiterBetrieb: Beta-Modus ist GELB (Warnung), nicht rot. Test mit der echten Ausgabe als Fixture. FUND 2 — 'Komprimieren auf CPU statt GPU': Der Default 'H.265 MKV 1080p30' ist ein CPU-Preset. Neue GEMESSENE Empfehlung (gemeinsam/preset-empfehlung.ts): aus den echten Backends und der echten Preset-Liste des eigenen HandBrake — VCN vor NVENC vor QSV vor CPU, nur Namen die WIRKLICH in der Liste stehen, HandBrake-Presets deckeln die Aufloesung nur (DVD bleibt SD). Kette: eigene Wahl > allgemeines Preset > Empfehlung > CPU-Default. Auf dem Commander-PC: bluray/dvd -> 'H.265 VCN 1080p', uhd -> 'H.265 VCN 2160p 4K'. Die Preset-Auswahl zeigt 'automatisch: <Empfehlung>' als Leer-Option. FUND 3 — 'keine Alternative waehlbar': 'Aendern …'-Dialog an der Laufwerks-Kachel (§ 5 Schritt 4): TMDb-Suche (Film + Serie, mit Postern), Klick uebernimmt — Nutzer-Wahl gilt als 100 % und steuert Ablage-Ordner, NFO und Poster. Neue Nachrichten metadaten-suchen / zuordnung-setzen / metadaten-vorschlaege. Dazu: Poster in der Laufwerks-Kachel (CSP um image.tmdb.org erweitert), Restzeit-Schaetzung am Fortschritt. 192 Tests gruen, Smoke gruen. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-30 20:20:10 +02:00
HitonabiandClaude Fable 5	0e1c927e7b	docs: SAVEPOINT — Rippy v5 komplett (W-0 bis W-7), Beweise und offene Hand-am-Geraet-Punkte ... Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-30 19:20:40 +02:00
HitonabiandClaude Fable 5	9fa3df500d	feat(v5): Etappe W-6 — Setup, Selbst-Update, Erst-Einrichtung, Lizenzen ... electron-builder → NSIS: EIN RippySetup-<version>.exe, pro Benutzer, ohne Adminrechte, eigenes Icon (PNG-basiertes ICO selbst gebaut). extraResources: die MITGELIEFERTEN Werkzeuge (HandBrakeCLI GPL-2, flac.exe MIT libFLAC.dll — die Ohne-DLL-Falle aus § 9) samt Lizenztexten und Quellverweisen (bau/lizenzen, Entscheid 9); vendor/ liegt nicht im Git (74 MB), Befuellung steht in BAUEN.md. Der Kern findet die mitgelieferten Werkzeuge ueber RIPPY_VENDOR (resourcesvendor) VOR allen anderen Suchwegen. haupt/update.ts (§ 6.8): electron-updater gegen das oeffentliche Gitea (festes Tag 'aktuell' als Rueckfallebene, Entscheid 6) — NUR https (http wird ABGELEHNT; Regel-Tests), NIE waehrend eines Rips (der Haupt kennt die aktiven Vorgaenge), Fehlschlaege still aber ablesbar (letzte erfolgreiche Pruefung im Status), installiert beim naechsten Start. haupt/autostart.ts: HKCU-Run ueber app.setLoginItemSettings, Toggle in den Einstellungen. Erst-Einrichtung (§ 6.9) im Programm: 5 Schritte, NUR ein Fehler blockiert (kein Laufwerk = Warnung, MakeMKV-Pflicht mit Klartext-Weg). GEBAUT UND GEMESSEN (30.08.2026): - dist-setup/RippySetup-5.0.0-w0.exe — 130,8 MB, SHA-256 07D39D6BAB74A47C21AA53D847FB5A5DB6990AE9FA1CBC7BE814B51050883115, plus .blockmap. - MESSUNG: Die Update-Auskunft heisst bei Vorab-Versionen nach dem KANAL (w0.yml) — erst ein Release ohne Suffix erzeugt latest.yml (steht jetzt in BAUEN.md). - Das GEPACKTE Programm (win-unpacked, asar + resources) besteht den Smoke: SMOKE OK, und der Screenshot zeigt die Erst-Einrichtung — das Bild eines frischen Rechners. Bewusst offen (SAVEPOINT): die automatische MakeMKV-Beschaffung (beschaffen.ts — Download+Installer-Start braucht einen Live-Test); das Setup NENNT den Weg klar. 185 Tests gruen. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-30 19:03:40 +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	c78ff22ab7	feat(v5): Etappe W-5 — Oberflaeche: Tray, Toasts, Taskleiste, Einstellungen, Bibliothek ... haupt/: tray.ts (Symbol mit Zustand, Kontextmenue, Fenster zu = weiter- laufen, Beenden nur noch gewollt), Windows-Toasts bei Disc erkannt / fertig / Fehler (Klick holt das Fenster), Taskleisten-Fortschritt (setProgressBar, Fehlermodus), echter Windows-Ordnerdialog per IPC. Eigenes Icon (bau/icon.png + tray.png, Disc-Optik). Kern: Einstellungen lesen/schreiben NUR ueber die eine Quelle (§ 6.7, Whitelist der Schluessel), Werkzeug-Auskunft (Katalog + gemessene HandBrake-Presets/Backends), Bibliothek in db.ts (Schema v2 — fingerprint, Titel, Groesse, Ort, Dauer), Duplikat-Erkennung beim Einlegen (§ 6.6: 'schon einmal gerippt am …' als disc-info + Toast), Pipeline traegt fertige Vorgaenge ein. Fenster: drei Bereiche (Uebersicht / Einstellungen / Bibliothek). Einstellungen: Ablage mit Durchsuchen-Dialog, Kompression je Disc-Typ (Preset-Liste VOM eigenen HandBrake gemessen, 'NICHT komprimieren' waehlbar), Sprachlisten, TMDb/OMDb-Keys, Medienserver, Werkzeug-Stand mit Klartext (gefunden/fehlt + Folgen). Bibliothek als Tabelle. Der Smoke-Screenshot zeigt nebenbei den Ernstfall in schoen: Das Laufwerk ist nach dem rc11-Vorfall inzwischen auch am Storage-Stack in 'unknown' gekippt — und die Kachel zeigt den ZUGRIFFS_GRUENDE-Klartext samt Abhilfe statt eines stummen Zustands. 165 Tests gruen, Smoke gruen. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-30 18:47:39 +02:00
HitonabiandClaude Fable 5	a9fa8fa2d8	fix(v5): discmerkmale auf Plattform-Pfade — dritte Lehre desselben Musters ... titelAusBdmt lief auf der Laufzeit-Wurzel (G:\ im Betrieb, tmp-Ordner im Linux-CI-Test) mit win32-join — der BDMV-Pfad wurde auf POSIX zu EINEM Namen mit Backslashes und der Test brach. Dieselbe Regel wie struktur/pipeline: Laufzeit-Wurzeln nehmen plattform-path. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-30 18:41:45 +02:00
HitonabiandClaude Fable 5	5f386e5406	feat(v5): Etappe W-4 — Metadaten-Automatik mit Sicherheitsgrad ... metadaten/: discmerkmale.ts (BDMT-Studio-Titel, ISO-9660- und UDF-Volume-Label direkt vom Medium — OHNE koffi, ueber fs auf \.\G: —, Label-Normalisierung, Fingerabdruck, progressive Titel-Kandidaten), tmdb.ts (v3-Key UND v4-Token, de-DE, /find fuer deutsche Texte zu OMDb-Treffern), omdb.ts, zuordnung.ts (die Confidence-Kaskade 0,95/0,90/0,80/0,60/0,30 aus prescan.py). ablage/poster.ts. Kern meldet 'disc-info' beim Einlegen; die Pipeline benennt den fertigen Ordner '<Titel> (Jahr)', schreibt movie.nfo/tvshow.nfo mit echten Metadaten und laedt das Poster. Fenster zeigt 'sehr wahrscheinlich: … · 95 %'. ZWEI Kaskaden-Schwaechen LIVE GEFUNDEN und gehaertet (gegen die echten APIs gemessen, Keys aus den Docker-Settings der VM, nicht persistiert): 1. 'Spartacus Gods Of The Arena' wurde zum FILM 'Spartacus' (1960) — der stark gekuerzte Kandidat traf woertlich, bevor die volle Anfrage als spezifische SERIE galt. Kaskade jetzt JE KANDIDAT woertlich→spezifisch (spezifisch nur fuer die volle Anfrage, auch fuer Serien). Nachgemessen: jetzt Serie, 90 %. 2. OMDbs t=-Suche machte aus dem Label 'Bd Evg D2' selbstbewusst 'BD Scream 5' — jetzt Wort-Jaccard-Gate >= 0,5. Nachgemessen: der Fall ist jetzt ein ehrlicher 60-%-Vorschlag, den das UI nachfragt. Messwerte: Akira→95% · Evangelion 2.22→80% (der dokumentierte Fund) · Spartacus GotA→Serie 90% · Bd Evg D2→Vorschlag 60%. Dazu ein neuer Quelltext-Hygiene-Waechter (keine rohen Steuerbytes — zweimal beim Schreiben passiert, einmal haette ein Test dadurch anders gemessen als gelesen). 165 Tests gruen, Smoke gruen. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-30 18:39:09 +02:00
HitonabiandClaude Fable 5	e840b7f327	fix(v5): Laufzeit-Pfade plattformneutral — pipeline/struktur auf node:path ... Der NFO-Ablage-Test brach in der Linux-CI: pipeline/struktur bauten mit path.win32 auf POSIX-Testordnern (mkdir legte 'x\Filme' als EINEN Namen an, readdir fand nichts). Regel jetzt dokumentiert: Module ueber LAUFZEIT-Wurzeln (Ablage) nutzen plattform-path — zur echten Laufzeit immer Windows, in der CI physisch korrekt auf POSIX; Module mit FESTER Windows-Semantik (katalog, dateiDaneben) bleiben bei path.win32. Testerwartungen entsprechend ueber join() statt Literale. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-30 18:29:46 +02:00
HitonabiandClaude Fable 5	3dc296f071	feat(v5): Etappe W-3 — Komprimieren + Ablegen, mit Vollbeweis ... komprimieren/: handbrake.ts traegt ALLE bezahlten Fallen aus dem Docker-Zweig — --aencoder statt --audio-codec (mit Anti-Regressions- Wächter im Test: der alte Test hatte den Fehler FESTGESCHRIEBEN), --format aus der Endung (Container kommt sonst aus dem Preset), Fortschritt NUR aus der Encoding-Zeile (Scan-99%-Falle), letzte 12 Zeilen fuer den Fehlerfall, unknown-option-Erkennung VOR allem anderen (kommt mit Rueckgabewert 0!), Datei-daneben-Suche, CR-Zeilentrennung mit 0x81-Kodierungsfalle. encoder.ts misst statt behauptet (--help, --preset-list, Familien statt Sammelbegriff). presets.ts: je Disc-Typ, PRESET_KEINE, Sprachlisten. ablage/: struktur.ts (sichere Namen, '<Titel> (Jahr)', Season NN, Episoden-Zuordnung NUR bei Eindeutigkeit), nfo.ts (Kodi-Schema), medienserver.ts (Jellyfin/Emby/Kodi-Refresh, wirft nie). ablauf/pipeline.ts ERSETZT rippen.ts: Rip → Kompression → Ablage als EINE Kette; Kompressions-Fehler laesst den verlustfreien Rip STEHEN und nennt den Ort; Lesefehler ueberleben bis in die Fertig-Meldung. Roh wird in dieser Etappe grundsaetzlich behalten (Loeschen erst mit W-5-UI). GEMESSEN am echten System (30.08.2026): - Encoder: 22 Stueck, Backends cpu-x264/x265/av1 + vce + vce-av1 (RX 9070 XT als VCE-Familie — nicht unter Intel-Namen), 107 Presets. - Probe-Encode 5 s Material: success in 45,5 s. - VOLLBEWEIS: Spartacus-Rohschnitt (17,71 GB — die Datei, die in rc11 am falschen Schalter starb) mit Preset 'H.265 VCN 1080p' in 2,1 min auf 1,17 GB komprimiert und nach Jellyfin-Schema abgelegt: E:\Rippy-v5-Beweis\Filme\Spartacus - Gods of the Arena - Disc 2 (2011)\ mit movie.nfo. - Nebenbefund: Der Evangelion-Roh-Rip vom 29.08. traegt 'This file was not properly finalized' im Kopf — 23,5 GB, die wie fertig aussehen und es nicht sind (der abgebrochene rc11-Rip). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-30 18:26:00 +02:00
HitonabiandClaude Fable 5	ca338ad467	fix(v5): Windows-Pfadregeln ausdruecklich — path.win32 statt join ... Die Ampel (Linux) brach an den Katalog-Tests: das plattformabhaengige path.join mischte dort Schraegstriche in Windows-Pfade. Rippy v5 baut NUR Windows-Pfade — katalog.ts, handbrake.ts und ablauf/rippen.ts rechnen jetzt ausdruecklich mit path.win32 und damit auf jeder Plattform gleich. Im node:24-Container nachgestellt: vorher 2 failed, mit dem Fix lokal 96 gruen. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-30 18:16:17 +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
HitonabiandClaude Fable 5	a45069af5e	feat(v5): Etappe W-1 — Laufwerk: Wache, Typ, Auswerfen mit Nachsehen ... kern/laufwerk in drei Schichten: codes.ts (Steuercodes HERGELEITET wie win_ioctl.py, gegen die Doku-Zahlen getestet), win32.ts (der einzige koffi-Ort im Kern, Muster aus beweise/laufwerk.js), disc.ts (Logik gegen die LaufwerkApi-Schnittstelle — classify mit den cdrom.py-Schwellen, Geraete-Info mit ready/empty/unknown + Klartext-Grund, Auswurf als entriegeln→auswerfen→NACHSEHEN mit injizierbarem Warten). Dazu wache.ts im 3-Sekunden-Takt (§ 5 Plan A): Uebergangslogik pur, gescheiterte Runde behaelt den Stand (R2) und meldet laut (R4). Fenster zeigt Laufwerke live (Modell, Typ, Groesse, Grund) mit Auswerfen-Knopf; Ereigniszeilen fuer Disc rein/raus und Fehler. Bündel-Falle gefunden und behoben: Ein woertliches require überlebt Rollup nicht — win32 wird per dynamischem import() als eigener Chunk gebaut; der Fehler war dank R4 im Fenster sichtbar statt still. Gemessen am echten BU40N (30.08.2026, RIPPY_MESSUNG=1): Laufwerk G: status=ready typ=bluray groesse=33759690752 modell=HL-DT-ST BD-RE BU40N 1.03 serial=0025114C0149 Der Auswurf-Beweis (messung.auswurf) folgt am Ende der Sitzung — der BU40N kann die Schublade nicht selbst einziehen. 52 Tests gruen (Steuercodes, classify, Auswurf-Ablauf, Geraete-Info, Wache, Smoke weiterhin gruen mit Laufwerks-Kachel im Bild). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-30 17:28:46 +02:00
HitonabiandClaude Fable 5	6ed8035dcc	fix(tests): Linux-only-Waechter pruefte die Welt vor d3e86d2 ... Die Ampel war rot, und die Ursache war NICHT Rippy v5: d3e86d2 hat den makemkvcon-Zweig aus dem Prescan bewusst entfernt (einer der 15 Funde), aber test_makemkvcon_wird_ueber_den_katalog_gesucht verlangte weiter den alten Katalog-Aufruf. Der Test laeuft nur in der CI (fcntl, lokal ausgeschlossen) — deshalb fiel es erst beim ersten Push des Branches auf. Der Waechter passt jetzt auf die NEUE Wirklichkeit auf: kein shutil.which UND makemkvcon bleibt draussen. Unter Linux nachgemessen: 16/16 gruen, Gesamtlauf der Nachstellung 995 passed + dieser Fix. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-30 17:19:51 +02:00
HitonabiandClaude Fable 5	a172a3e2c0	fix(ci): setup-node raus — der Runner hat Node 24 nativ ... Lauf 221 brach nach 2:14 min ab; der einzige neue Schritt war actions/setup-node@v4. Nachgemessen am 30.08.2026: Das Runner-Image docker.gitea.com/runner-images:ubuntu-latest bringt Node v24.18.0 und npm 11.16 von Haus aus mit, und die kompletten Node-Schritte der Ampel (npm ci + build + test in rippy-windows) laufen in einem frischen node:24-Container auf der VM gruen durch. Statt Beschaffungs-Magie prueft die Ampel jetzt im Klartext, dass Node >= 22 da ist — zu alt heisst ROT mit Ansage, nicht kryptisch. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-30 17:07:53 +02:00
HitonabiandClaude Fable 5	0464933ada	docs: SAVEPOINT — Rippy v5, Etappe W-0 ... Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-30 16:54:32 +02:00
HitonabiandClaude Fable 5	c539e65cd2	feat(v5): Etappe W-0 — das Geruest steht ... Electron 44 + TypeScript, drei Prozesse (haupt / kern als utilityProcess / fenster mit React), Nachrichten-Schema mit Pruef-Funktionen, node:sqlite als einzige Datenbank-Stelle (kern/speicher/db.ts, § 6.7), Prozess-Leine im Haupt (Job Object aus beweise/leine.js — Begruendung fuer den Ort im Dateikopf), MessagePort direkt Fenster<->Kern, Einzelinstanz-Sperre, Kern-Neustart-Wache, strikte CSP im gebauten Fenster. Wächter-Tests nach § 4.3: koffi nur an zwei benannten Orten (R1), kein leerer catch und kein catch-mit-Leerwert (R2/R4), kein HTTP-Server (§ 4.1), node:sqlite nur in db.ts (§ 6.7). Dazu Datenbank- und Schema-Tests: 18/18 gruen, Typpruefung in drei Kontexten. Der W-0-Beweis (npm run smoke, echtes Programm): SMOKE: OK — fenster=geladen kern=pid:13676,node:24.18.1 datenbank=ok leine=gesetzt pong=ok version=5.0.0-w0 Nachgemessen ausserdem: taskkill /F auf den Haupt-Prozess (ohne /T, der Absturz-Fall aus rc10) — der Kern stirbt mit. Bau-Fallen dokumentiert (BAUEN.md): npm 11 blockt Electrons Install-Skript (§ 3.5), plugin-react 6 verlangt Vite 8 (deshalb 5.2), TypeScript bewusst auf 5.9.3 gepinnt statt tsgo 7. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-30 16:53:30 +02:00
HitonabiandClaude Fable 5	564bd17f84	ci: Ampel auf Node 24 verankert ... Rippy v5 (rippy-windows/) braucht Node 24: Vite 7 und node:sqlite laufen nicht auf dem Zufalls-Node des Runners. docker/ui unter Node 24 lokal nachgemessen (npm ci + build gruen, 30.08.2026). Die Ampel prueft unveraendert — nur das Werkzeug ist jetzt festgelegt. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-30 16:53:16 +02:00
HitonabiandClaude Fable 5	a0cff205ab	docs(konzept): Entscheid 4 — Worktree aufgeloest, Branch normal ausgecheckt ... Der doppelte Checkout (Worktree + Hauptordner) blockierte den Start neuer Sitzungen auf dem Branch. Der Branch selbst und main bleiben unveraendert. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-30 16:25:58 +02:00
HitonabiandClaude Fable 5	c44bfa6daa	docs(konzept): Zweite Fassung — geprueft, nachgemessen, drei Entscheide ... - Faktenfehler korrigiert: Gitea ist oeffentlich per HTTPS erreichbar (gemessen, § 3.6) — Updates kommen direkt daraus, Drei-Wege-Tabelle weg - node:sqlite in Electron 44 im utilityProcess bewiesen (§ 3.4, beweise/sqlite-main.js + sqlite-kern.js) — better-sqlite3 nicht noetig - Disc-Wache umgedreht: 3-Sekunden-Takt ist Plan A, WM_DEVICECHANGE spaetere Verfeinerung (§ 5) - Entscheid 7 verschaerft: main-Aufraeumen sofort, nicht erst nach W-6 - Entscheid 9 neu: Zielgruppe Bekannte mit Link, Lizenztexte liegen bei - MakeMKV-Lage tagesaktuell bestaetigt (Key bis Ende September 2026, Kaufseite defekt = Dauerzustand seit Sommer 2025) - Electron-Pflege-Regel (§ 6.8), npm-11-Sperre trifft auch Electron selbst (§ 3.5), Release = drei Dateien, 4K-Schluesselkette in § 10, Risikotabelle aktualisiert Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-30 16:20:51 +02:00
HitonabiandClaude Opus 5	e514e4070b	docs(konzept): Entscheid 8 — der Remote-Worker bleibt bei Docker ... Commander: „Das soll NICHT Teil des neuen Standalone-Produktes sein, da dieser NUR fuer die Docker-Variante verwendet wird." Damit ist bestaetigt, was in Paragraph 11.1 zuvor nur als Auslegung stand. Der Remote-Encode-Worker wird WEDER abgeraeumt (er ist Docker, und Docker bleibt unangetastet — Entscheid 2) NOCH nach v5 uebernommen (v5 ist Einzelplatz, Entscheid 3 — es gibt dort keinen zweiten Knoten, dem man etwas schicken koennte). Dazu die eigentliche Reparatur an diesem Abschnitt: Er war in Entwickler-Begriffen geschrieben (Modulnamen, PyInstaller, os.name-Zweige) und deshalb fuer den Adressaten nicht lesbar — zweimal nachgefragt, zweimal zu Recht. Paragraph 11.1 fuehrt die drei Teile jetzt erst in Klartext ein: A ist Rippy. B ist ein Handlanger fuer die VM. C sind Notizzettel, die wegen A eingeklebt wurden. Und macht den Unterschied A/C an dem fest, worauf es beim Aufraeumen ankommt — nicht am Inhalt, sondern am Ort: A sind ganze Ordner, die Docker nie aufschlaegt (wegwerfen). C sind einzelne Seiten in Ordnern, die Docker taeglich benutzt (einzeln durchgehen). Erst danach kommt die Tabelle mit den Dateinamen. Das ist kein Beiwerk: Genau diese Verwechslung wuerde beim Aufraeumen die laufende VM treffen. Und manche Windows-Zeile braucht sogar B weiter — etwa die Regel, dass eine Laufwerkswurzel ihren abschliessenden Trenner behaelt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-30 15:59:11 +02:00
HitonabiandClaude Opus 5	fde3a78e97	docs(konzept): Entscheide 5-7 — kein Zertifikat, Gitea-Updates, Altlast weg ... Die drei offenen Punkte aus KONZEPT-WINDOWS sind entschieden (30.08.2026). Entscheid 5 — kein Code-Signing-Zertifikat. Die SmartScreen-Warnung wird hingenommen und in der Anleitung erklaert. Die Folge gehoert dazu und steht jetzt in 6.8: Ohne Signatur kann electron-updater ein Update nicht auf Echtheit pruefen, also ist der Transportweg die einzige Absicherung — Updates nur ueber HTTPS, eine http-Adresse wird abgelehnt. Entscheid 6 — Updates aus Gitea, auch fuer Externe erreichbar. Rippys Seite ist einfach: die Adresse steht in der Konfiguration, electron-updater braucht nur einen statischen HTTPS-Ort. Die Netz-Seite ist es nicht — Gitea liegt auf 192.168.178.153 im Heimnetz und ist von aussen nicht erreichbar. Drei Wege sind aufgeschrieben und bewertet (Gitea veroeffentlichen / oeffentlicher Spiegel / eigene Quelle je Nutzer), Empfehlung ist der Spiegel. Rippy wird fuer alle drei gebaut, die Entscheidung kann spaeter fallen ohne Programmaenderung. Entscheid 7 — der alte Windows-Weg wird entfernt, auch aus main. Dafuer gibt es einen neuen Abschnitt 11 mit der Arbeitsliste, und die zerfaellt in DREI Teile statt einem: A die Standalone-App (PyInstaller, Tray, Fenster, Win32-Treiber, lokale Queue, Werkzeug-Beschaffung) -> weg B der Remote-Encode-Worker fuer die Docker-Installation -> BLEIBT C die verstreuten os.name=="nt"-Zweige im Docker-Code -> einzeln pruefen Dass B bleibt, ist ausdruecklich als Auslegung markiert, nicht als Anweisung: Der Remote-Worker ist eine Funktion der Docker-Installation, und Entscheid 2 haelt die unangetastet. Ihn mit abzuraeumen wuerde der VM eine Faehigkeit nehmen, die niemand gekuendigt hat. Teil C ist der heikle: pfade.py bleibt (der Remote-Worker braucht Laufwerkswurzeln und UNC), nativ_nachsehen() ist zu pruefen, und die Faehigkeiten-Auskunft /betrieb bleibt sinnvoll — nur ihre Windows-Werte fallen weg. Zeitpunkt: erst NACH v5 W-6. Solange v5 nicht installierbar ist, ist die alte Fassung das einzige Windows-Rippy — sie vorher zu loeschen waere eine Luecke ohne Gegenwert. Der Entscheid nennt die Richtung, kein Datum. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-30 15:52:37 +02:00
HitonabiandClaude Opus 5	cb811bec28	docs: KONZEPT-WINDOWS — Rippy v5 als eigenstaendiges Electron-Programm ... Die heutige Windows-Fassung ist der Docker-Code in einer EXE: PyInstaller buendelt docker/api und docker/worker, uvicorn laeuft auf 127.0.0.1:7788, pywebview stellt ein Fenster davor. Elf Release-Kandidaten in drei Tagen, und die Funde sind fast alle derselbe Typ — Linux-Annahmen, die unter Windows etwas anderes bedeuten (timeout ls -d, shutil.which, /app, /dev/{name}, F: ohne Trenner). Das Konzept beschreibt den Neubau als Windows-Programm: Electron 44, TypeScript durchgehend, Einzelplatz, kein Python, kein HTTP-Server. Vier Entscheide des Commanders (30.08.2026) sind eingearbeitet: alles TypeScript/Node · Docker bleibt unangetastet · reiner Einzelplatz · eigener Branch. Vor der ersten Zeile Konzept gemessen (Regel D), Belege in beweise/: * Win32 aus Node an G: (HL-DT-ST BD-RE BU40N) — Laufwerkssuche, CreateFileW, QUERY_PROPERTY (Modell + Serial), CHECK_VERIFY2, GET_LENGTH_INFO (33,76 GB -> Blu-ray). IOCTL_CDROM_DISK_TYPE antwortet mit Fehler 50 — derselbe Befund wie im Python-Treiber. * Prozess-Leine (Job Object): Kind stirbt mit dem per taskkill /F ohne /T abgeschossenen Elternprozess. Die Messung aus rc10, in Node nachgestellt. * node:sqlite ist in Node 24 eingebaut — in Electron noch ungeprueft, ausdruecklich als offener Punkt markiert. Akutestes Risiko im Dokument: MakeMKVs freier Beta-Key laeuft Ende September 2026 ab, die Kaufseite fuer die Dauerlizenz ist seit Mai defekt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-30 15:38:39 +02:00
HitonabiandClaude Opus 5	9050fea3f0	docs: SAVEPOINT v4.0-rc11 ... Der Schalter, den es nicht gibt — und vierzehn weitere Funde aus demselben Rundgang. Jeder mit der Messung, an der er haengt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-30 15:11:08 +02:00
HitonabiandClaude Opus 5	d3e86d2641	fix(windows): Der Schalter, den es nicht gibt, und vierzehn weitere Funde ... Commander: „Kompression fehlgeschlagen bei Spartacus … _t01.mkv: HandBrake endete mit Code 0" — 16,5 GB fertiger Rohschnitt, und die Kompression war in derselben Sekunde vorbei, in der sie begann. Nachgestellt mit genau der Befehlszeile, die Rippy baute: unknown option (--audio-codec) HandBrake has exited. $? = 0 Den Schalter `--audio-codec` gibt es bei HandBrakeCLI nicht; er heisst `-E` / `--aencoder`. Ein unbekannter Schalter ist fuer HandBrake kein Fehler, der Rueckgabewert ist 0. Der Test dazu forderte den falschen Namen sogar ein. Daraus wurde ein Rundgang durch den Windows-Pfad. Alles unten ist gemessen, nichts vermutet (Regel D). ## Die Kompression 1. `--aencoder` statt `--audio-codec`. Am mitgelieferten HandBrakeCLI 1.11.2 gemessen, mit einem 5-Sekunden-Encode auf der echten Roh-Datei bestaetigt. 2. HandBrakes letzte Zeilen werden aufgehoben (12 gepuffert, 4 in der Meldung) und `unknown option (...)` wird als eigener Fall erkannt, VOR allen anderen. Vorher wurde jede Zeile weggeworfen, die kein Fortschritt war — bei Rueckgabewert 0 blieb damit keine Auskunft uebrig. Die geratene Zeile „Meist ist der Zielordner nicht beschreibbar" ist raus; sie war falsch und hat die Suche in die falsche Richtung geschickt. 3. Ein `ue`-Umlaut im Pfad toetete die Kompression. HandBrake schreibt zwei Kodierungen in denselben Strom (derselbe Pfad einmal UTF-8, einmal CP850). In CP850 ist das Byte 0x81, und das ist in cp1252 — was `text=True` auf deutschem Windows waehlt — undefiniert: UnicodeDecodeError: charmap codec can't decode byte 0x81 Neu: `rip/handbrake_aufruf.py` mit `HB_LESEN`, benutzt von ripping.py und caps.py. Bewusst nicht binaer wie bei makemkvcon: HandBrake trennt Fortschrittszeilen mit CR, im Binaermodus waere der Balken weg. ## Die Rohdaten 4. `rohdaten.kandidaten` machte aus dem Arbeitsordner `F:\` ein `F:` und verband damit weiter. Das ist unter Windows der aktuelle Ordner auf Laufwerk F, nicht dessen Wurzel — 16,5 GB waren unsichtbar, und der Wiederholen-Dialog bot nur „Neu rippen" an. Die Falle steht woertlich im Kopf von `pfade.verbinden`. 5. Gesucht wurde unter der heutigen Einstellung statt unter der Wahl DIESES Rips (`meta["work_dir"]`). Genau dafuer wurde rohdaten.py am 26.07. gebaut; repariert wurde damals die Kandidatenliste, nicht der Aufrufer. Neu: `_arbeitsverzeichnis_des_jobs`, benutzt an vier Stellen. 6. Zwei Speicher fuer dieselben Ordner: Die Oberflaeche schreibt `outputDir`/`workDir` in die Datenbank, `betrieb` liest `storage.*` aus der Konfigurationsdatei, und die schreibt niemand. Gemessen: eingestellt `E:\Rippy`, angezeigt `C:\Users\...\Videos\Rippy`. Neu: `betrieb.mit_einstellungen`. ## Das Laufwerk 7. `device_info` fing den OSError ab und lieferte „unknown" ohne den Grund. Nach einem Rip mit Lesefehlern beantwortete das Laufwerk keine Medien-Abfragen mehr (Win32-Fehler 1), die Geraete-Auskunft aber schon — im UI stand eine volle Laufwerkskarte, kein Rip startbar, und im Protokoll das laengst veraltete „Disc erkannt". Neu: `ZUGRIFFS_GRUENDE`, ein Feld `grund` im Laufwerks-Eintrag und eine Protokollzeile je Wechsel. Eine fehlgeschlagene Disc-Erkennung wird ebenfalls protokolliert. 8. Der Linux-Treiber nannte ein unzugaengliches Laufwerk „empty", waehrend Windows richtig „unknown" sagt. Angeglichen, samt Feld-Paritaet. 9. `CreateFileW`, `DeviceIoControl` und `CloseHandle` hatten weder `restype` noch `argtypes` — 32-Bit-`c_int` fuer einen 64-Bit-HANDLE, in beide Richtungen. Mit `restype` aendert sich der Fehlerwert von -1 auf 0xFFFFFFFFFFFFFFFF; die Pruefung deckt jetzt beides ab. Am echten Laufwerk gegengeprueft, Fehlerpfad eingeschlossen. 10. Der Vor-Scan lief bei JEDER eingelegten Disc ein `makemkvcon info` mit 120 s Zeitgrenze — 20 bis 120 Sekunden „Disc wird gelesen". Frueher war das schnell, weil der Zweig unter Windows nie lief (`shutil.which`, repariert am 28.08.). Das Ergebnis landete allein in `toc["tracks"]`, das niemand liest: Der Rip-Dialog holt seine Liste ueber `/devices/{id}/scan-tracks`, wenn sie gebraucht wird. Entfernt. ## Notbremsen 11. `_frei_bytes` suchte den naechsten vorhandenen Ordner selbst. `os.path.dirname("Q:\\")` gibt sich selbst zurueck — ein Arbeitsverzeichnis auf einer abgezogenen Platte haette den Job vor dem Rip stumm haengen lassen. Benutzt jetzt `pfade.naechster_vorhandener`, das den Abbruch seit V2-1 hat. 12. `naechster_vorhandener` haelt Laufwerks- und UNC-Wurzeln jetzt absolut. 13. `aufraeum_skript` baut sein `rmdir /s /q` aus `InstallLocation` in der Registry. Waere das eine Laufwerks-Wurzel, loeschte die Deinstallation das Laufwerk. Nicht beobachtet, aber nicht wiedergutzumachen — der Loeschbefehl bleibt in dem Fall weg. ## Lesefehler MakeMKV sicherte 1 von 2 Titeln, endete mit 0, und Rippy schrieb „Rip fertig". Jetzt gibt es eine Warnung, auch wenn der Rip als Erfolg endet, und die MSG-Nummer steht im Protokoll: MakeMKVs Texte sind uebersetzt, die Nummern nicht. ## Aus der Gegenprobe am laufenden Rippy Die erste Fassung dieses Standes war installiert, als der Commander meldete: „nun oeffnen sich diverse fenster im hintergrund, gehen ganz kurz auf und dann wieder zu. Das laufwerk hoert auch einfach auf zu lesen." Beides Altlasten, die erst durch die neue Protokollzeile sichtbar wurden. 14. Prozesserzeugung mitgeschnitten: 14:54:40 timeout.exe timeout 4 ls -d C:\Users\...\d7ee6c06-... 14:54:40 WindowsTerminal.exe `rohdaten.pruefen` fragt mit `timeout N ls -d`, ob es ein Verzeichnis gibt. Unter Linux ist das richtig (os.path.isdir kann an einem toten CIFS-Mount im Kernel haengen, ein Kindprozess laesst sich abbrechen). Unter Windows ist es dreifach falsch: timeout.exe gibt es dort, kennt aber weder `ls` noch `-d`; sie braucht eine Konsole, und die reisst Windows auf; und ihr Rueckgabewert ist nie 0, die Antwort lautete also „weg" fuer JEDES Verzeichnis. Rohdaten waren unter Windows grundsaetzlich unsichtbar. Neu: `nativ_nachsehen()`. Die zwei gleichartigen Aufrufe in mounts.py bekommen dieselbe Absicherung. 15. Der Waechter fragte das Laufwerk alle drei Sekunden ab — auch mitten im Rip, also drei CreateFileW plus IOCTLs auf ein Geraet, das makemkvcon gerade liest: 12:49:52 bluray-Rip gestartet 12:50:09 [watcher] Laufwerk G: beantwortet keine Medien-Abfragen 12:50:12 MSG 2003 SCSI-Fehler ILLEGAL REQUEST:INVALID FIELD IN CDB 12:50:12 makemkvcon endete mit Code 11 `_auto_prescan` haelt sich seit dem 29.08.2026 an die Regel „waehrend eines Rips wird nicht gescannt"; die Laufwerksabfrage tat es nicht. Jetzt gilt in der Zeit der letzte bekannte Stand. ## Zwei Tests, die gelogen haben * `assert "--audio-codec" in cmd` schrieb den Fehler fest. * `lambda: {}` als Doppelgaenger fuer `get_settings(key, bei_fehler_leer)` brach, sobald ein Aufrufer einen Parameter benutzte — und zeigte dann auf den Code statt auf sich selbst. 977 Tests gruen, ruff sauber. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-30 15:11:00 +02:00
HitonabiandClaude Opus 5	b6a93aa726	docs: SAVEPOINT v4.0-rc10 ... Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-29 20:55:44 +02:00
HitonabiandClaude Opus 5	fed24237c9	fix(windows): makemkvcon ueberlebte Rippy und hielt das Laufwerk fest ... Commander: „jetzt hast du den makemkvcon kram dir nicht angeguckt". Stimmt — es stand als Frage im Notizbuch statt als Riegel im Code. ## Gemessen, nicht vermutet Ein Elternprozess startete makemkvcon, dann wurde er hart beendet (`taskkill /F` OHNE `/T` — genau das, was beim Dienst-Stopp und beim Drueber-Installieren passiert): ohne Leine makemkvcon PID 15368 vor dem Kill: True danach: True mit Leine makemkvcon PID 43608 vor dem Kill: True danach: False Windows raeumt Kindprozesse nicht auf. Eine solche Waise HAELT DAS LAUFWERK — jeder spaetere Rip scheitert dann mit „Das Öffnen der Disk schlug fehl". Zwei davon standen waehrend der Messungen auf diesem Rechner. ## Zwei Riegel * **Die Leine** (`winlauf.kinder_an_die_leine`) — eine Arbeitsgruppe (Job Object) mit KILL_ON_JOB_CLOSE. Stirbt Rippy, sterben makemkvcon, HandBrake und flac mit. Auch beim Absturz, auch per Taskmanager. Einmal beim Dienststart gesetzt, deckt sie JEDEN Werkzeugaufruf ab. * **Der Aufraeumer** (`winlauf.waisen_beenden`) — beendet beim Start Werkzeug-Prozesse, deren Elternprozess es nicht mehr gibt. Fuer das, was eine aeltere Fassung oder ein Absturz hinterlassen hat. Nur ELTERNLOSE: Ein makemkvcon eines laufenden Rippy bleibt unangetastet, `makemkv.exe` (die Oberflaeche) steht gar nicht erst auf der Liste. Am echten Fall nachgestellt: Waise erzeugt, Rippy gestartet, Waise weg. ## Drei Prozesse duerfen NICHT mitsterben Dienst, Fensterprogramm und das Aufraeum-Skript der Deinstallation loesen sich ueber `eigenstaendig_starten` heraus (CREATE_BREAKAWAY_FROM_JOB). Mit Rueckfall ohne die Fahne: Steckt Rippy in einer fremden Arbeitsgruppe ohne Herausloese-Erlaubnis, verweigert Windows den Start rundweg — ein Fenster, das gar nicht mehr aufgeht, waere schlimmer als eines, das mitstirbt. ## Die Falle beim Bauen Der erste Anlauf meldete nur „ging nicht". Ursache: Ohne `argtypes` reicht ctypes einen Griff als 32-Bit-int weiter. `GetCurrentProcess()` liefert aber (HANDLE)-1 = 0xFFFFFFFFFFFFFFFF, ctypes wirft `ArgumentError: int too long to convert`, und das breite `except` verschluckte es. `kernel32()` meldet jetzt jede Signatur an; ein Test wacht darueber. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-29 20:54:44 +02:00
HitonabiandClaude Opus 5	21c626eb4e	docs: SAVEPOINT v4.0-rc9 ... Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-29 20:40:25 +02:00
HitonabiandClaude Opus 5	f0f719ca12	fix(windows): Zweiter Rip startete waehrend der Kompression ins leere Laufwerk ... Der Commander meldete einen Rip-Fehlschlag „bei der Komprimierung", obwohl der Rip laengst durch war: makemkvcon endete mit Code 11 — letzte Meldung: Das Öffnen der Disk schlug fehl — keine MKV-Datei entstanden Auffaellig war, was FEHLTE: kein „Ursache:". Waere der Geraetepfad schuld gewesen, stuende dort MSG 2024. Bleibt: kein Datentraeger im Laufwerk. Der Ablauf dahinter: 1. Rip fertig → Rippy wirft die Disc aus (Standardeinstellung) 2. Status wird auf `transcoding` gesetzt — ab hier sagte `has_active_job` NEIN, das Laufwerk sei frei; es kennt nur pending/running 3. Die Disc-Wache sieht beim Auswurf einen Statuswechsel → „eingelegt" 4. Die Vollautomatik startet einen ZWEITEN Rip — auf ein Laufwerk, dessen Schublade gerade herausfaehrt Der zweite Rip lief in ein leeres Laufwerk. Auf dem Bildschirm sah das aus, als sei die Kompression gescheitert — sie lief ungestoert weiter. Drei Aenderungen: * `store.job_offen` — der weitere Riegel (pending/running/transcoding/ canceling) fuer die Vollautomatik. `has_active_job` bleibt unveraendert: Das fragt „haelt gerade jemand das Laufwerk?", und waehrend der Kompression tut das niemand — ein Auswurf von Hand bleibt erlaubt. * `ripping.disc_fehlt` — vor dem makemkvcon-Start nachsehen, ob ueberhaupt eine Disc drin liegt. Statt zwei Minuten Warten und Code 11 gibt es einen Satz, den man versteht. Ein FEHLGESCHLAGENER Blick verweigert nichts: „ich weiss es nicht" darf nie zu „es geht nicht" werden. * MSG 5010 in KRITISCHE_CODES — MakeMKVs Sammelmeldung sagt fuer sich nichts. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-29 20:36:59 +02:00
HitonabiandClaude Opus 5	f6f0a4ccb6	feat(windows): MusicBrainz-Tags fuer Audio-CDs ... Commander: „go" Die Dateien hiessen `Track 01.flac`. Eine Musiksammlung ohne Titel ist eine Sammlung von Nummern. ## Wie MusicBrainz eine CD wiedererkennt Nicht am Namen (den kennt die CD nicht) und nicht an einer Kennung auf der Disc (die gibt es nicht), sondern an der LAGE ihrer Spuren. Daraus wird ein Fingerabdruck gerechnet — SHA-1 ueber die Versaetze, base64 mit eigenem Alphabet (musicbrainz.org/doc/Disc_ID_Calculation). ## Belegt OHNE Audio-CD MusicBrainz gibt zu jeder bekannten Kennung die Spurlage heraus, aus der sie gerechnet wurde. Wer die Lage zurueckbekommt und daraus dieselbe Kennung rechnet, hat die Rechnung belegt: Spurlage „Back in Black" (abgefragt) -> 3KVSIWn_ewv9z0cCizmOJzDWtsQ- MusicBrainz sagt dazu -> 3KVSIWn_ewv9z0cCizmOJzDWtsQ- Und die ganze Kette am Stueck, mit echtem Encoder: Ordner ACDC - Back in Black Dateien 01 - Hells Bells.flac, 02 - Shoot to Thrill.flac, … Tags TITLE/ARTIST/ALBUM/ALBUMARTIST/DATE/TRACKNUMBER — mit metaflac aus der FERTIGEN Datei zurueckgelesen ## Zwei Fallen **Der Vorlauf.** Die Kennung rechnet MIT den 150 Frames, das Lesen OHNE. Wer das verwechselt, bekommt eine Kennung, die niemand kennt — und zwar ohne Fehlermeldung, denn die Antwort ist dann schlicht „unbekannte Disc". **`AC/DC`.** Als Ordnername haette der Schraegstrich unter Windows einen Unterordner aufgemacht. Aufgefallen NUR, weil der Beweis den Namen ausgegeben hat. Jetzt saeubert `sauberer_name` beides — Datei und Ordner. ## ⚠️ Mein Fehler dabei Die Spurlage im Test hatte ich zuerst ERFUNDEN: Beim Beweis hatte ich nur Spurzahl und Lead-Out ausgegeben und den Rest „passend" ergaenzt. Der Test wurde prompt rot — zu Recht. Die Zahlen stehen jetzt so drin, wie MusicBrainz sie herausgibt (erste Spur bei 182, nicht bei 150: diese Pressung hat einen laengeren Vorlauf). Ohne Treffer bleibt es bei `Track 01.flac`. Eine unbekannte Disc ist kein Fehler, und ein Netzausfall darf keinen Rip umwerfen. 932 Tests gruen, ruff sauber. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-29 16:33:46 +02:00
HitonabiandClaude Opus 5	986fcf19b1	feat(windows): Audio-CDs rippen — die letzte Luecke ist zu ... Commander: „mach es" Gemeint war die Lücke, die seit Wochen so im SAVEPOINT stand: **Audio-CDs laufen unter Windows nicht.** `cdparanoia` und `abcde` sind Linux-Werkzeuge. ## Nicht abcde nachbauen — den Windows-Weg gehen Eine Audio-CD hat kein Dateisystem. Die `Track01.cda`, die Windows zeigt, sind 44 Byte grosse Platzhalter; die Musik liegt roh in 2352-Byte-Sektoren. Windows bietet dafuer zwei Steuercodes an: IOCTL_CDROM_READ_TOC Inhaltsverzeichnis (MSF je Spur, Audio/Daten) IOCTL_CDROM_RAW_READ die Sektoren selbst Gegengeprueft, dass die berechneten Codes den dokumentierten entsprechen: 0x24000 und 0x2403e. Kodiert wird mit dem FLAC-Encoder vom offiziellen Xiph-Spiegel (1.5.0), den Rippy beim Einrichten holt — wie MakeMKV. KEIN Pflichtwerkzeug: Ohne ihn laeuft alles ausser Audio-CDs, und ein Fehlschlag darf das Einrichten nicht truebe machen. ## Zwei Fallen, beide gemessen **Die Leseadresse zaehlt in 2048er-Einheiten**, obwohl ein Audio-Sektor 2352 Bytes hat. Das ist dokumentiert und sieht falsch aus; mit 2352 liest man an der falschen Stelle. **`flac.exe` braucht `libFLAC.dll` daneben.** Mit nur der exe endete jeder Aufruf mit 0xC0000135 — „DLL nicht gefunden" — und zwar ohne eine einzige Zeile Ausgabe. Jetzt wird der ganze Win64-Ordner ausgepackt. ## Was geprueft ist Ein Laufwerk und eine Audio-CD lassen sich in der Ampel nicht herstellen. Deshalb steht alles Rechenbare in reinen Funktionen — MSF↔LBA, das Zerlegen der TOC-Bytes, WAV-Kopf, Blockaufteilung, Dateinamen — und der Ablauf bekommt Laufwerk und Encoder eingespritzt. 28 Tests dafuer. Zusaetzlich mit dem ECHTEN Encoder gemessen: zwei Spuren erzeugten Tons gerippt, und **FLAC bestaetigt seine eigenen Dateien** (`flac -t`, Code 0). Am echten Laufwerk gegengeprueft, dass das Inhaltsverzeichnis gelesen wird — die eingelegte Blu-ray meldet sich korrekt als DATEN-Track und wird nicht als Musik behandelt. Was noch fehlt: MusicBrainz-Tags. Die Dateien heissen `Track 01.flac`. Der Weg dafuer steht (`tags_je_spur`), die Disc-Kennung fuer die Abfrage nicht. 915 Tests gruen, ruff sauber. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-29 16:26:23 +02:00
HitonabiandClaude Opus 5	1b84ec2a45	fix(windows): Vollstaendiger Rundgang durch die Docker-Reste ... Commander: „Bro, du musst alles was rippy jetzt im code hat für Windows Bauen! Jeden pfad, alles wo die tools drauf zugreifen. Diese Rippy version MUSS 100% Windows Kompatibel sein. Prüfe bitte den kompletten Quellcode nach Docker Resten." Systematisch gesucht statt Fundstelle fuer Fundstelle: feste POSIX-Pfade, Linux-Programme, POSIX-eigene Aufrufe, `shutil.which`, `posixpath` auf echten Pfaden, Container-Texte. Sechs echte Fehler dabei. ## 1. `/dev/{name}` in drei Endpunkten — der schwerste Das UI ruft `/devices/{id}/eject`, `/scan-tracks` und `/tracks` mit der Kennung aus der Geraeteliste auf, unter Windows also `G`. Gebaut wurde daraus `/dev/G` — steht in keiner Laufwerksliste. **Auswerfen und „Disc scannen" antworteten unter Windows IMMER mit 404**, ohne dass irgendwo stand, warum. Hin- und Rueckweg gehoeren zusammen: Beide Treiber haben jetzt `kennung()` und `pfad_zu_kennung()`. Wer die Kennung vergibt, loest sie auch auf. ## 2. `os.path.isdir("/app")` — zum zweiten Mal Nach `caps.py` (heute frueh) auch in `ablauf.py`: Der eigenstaendige Windows-Rippy hielt sich fuer einen FREMDEN Worker und haette sich selbst vorgeworfen, Container-Pfade nicht zu erreichen — auf einer Maschine ohne Container. Die Entscheidung ist jetzt einspritzbar; vorher hing der Test daran, ob es einen Ordner `/app` gibt. ## 3. `shutil.which` in `schluessel.py` Ausgerechnet im Modul, das es NUR unter Windows gibt: Es suchte makemkvcon im PATH, wo unter Windows nie ein Programm aus „Programme" steht. Die Schluessel-Automatik fuer 4K-UHD lief damit nie an. ## 4. `posixpath.join` auf echten Pfaden `rohdaten.py` baute `C:\Roh/datei.mkv` — gemischte Trenner, die im UI falsch aussehen und jeden Vergleich brechen. ## 5. Container-Pfad in einer Nutzermeldung „Roh-Datei bleibt in /app/temp erhalten" nennt jetzt den echten Ordner. Wer die Datei retten will, sucht sonst am falschen Ort. ## 6. Container-Pfade als UI-Vorbelegung Rip-Dialog und `useBetrieb` starteten mit `/app/media`, bis die Antwort da war. Leer ist ehrlicher: Es behauptet nichts. ## Und HandBrakes „Code 0" Code 0 heisst ERFOLG. Rippy meldete trotzdem „fehlgeschlagen", weil die Datei nicht am erwarteten Ort lag: **HandBrake bestimmt den Container aus dem PRESET, nicht aus der Endung** — ein MP4-Preset schreibt `.mp4` neben das verlangte `.mkv`. Jetzt erzwingt `--format` den Container passend zur Endung (an HandBrake 1.11.2 gegengeprueft), und falls doch etwas daneben liegt, wird es gefunden statt weggeworfen. ## Der Waechter `test_keine_container_reste.py` prueft mechanisch, dass im Windows-Weg kein Container-Pfad ohne Begruendung steht. Die Ausnahmen stehen namentlich mit Grund da (Linux-Zweige, benannte Rueckfaelle) — und ein zweiter Test wirft jede Ausnahme raus, die niemand mehr braucht. Ueber den Tokenizer, nicht ueber „faengt mit Anfuehrungszeichen an": Der erste Anlauf blieb prompt an seinem eigenen `r\"\"\"`-Docstring haengen. 887 Tests gruen, ruff sauber. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-29 16:14:10 +02:00
HitonabiandClaude Opus 5	1a529f4e75	fix(windows): „Disc wird gelesen" blieb waehrend des ganzen Rips stehen ... Commander: „der ‚Disk wird gelesen' panel braucht eeeeewig. Der Rip ist bereits bei 30% und er liest immernoch." Genau so war es — und die Erkennung kam auch nie zum Ende. ## Warum `_auto_prescan` hatte GENAU EINE Absicherung: nicht zweimal gleichzeitig (`_laeuft`). Ob auf dem Laufwerk gerade ein Rip laeuft, hat es nie gefragt. Waehrend eines Rips haelt `makemkvcon` das Laufwerk. Ein zweites `makemkvcon info` daneben wartet, bis es seine Zeitgrenze erreicht (gemessen: eine Laufwerks-Abfrage braucht dann 14 s statt 5, der `info`-Aufruf laeuft in seine 120 s). Solange steht die Marke `_laeuft` — und damit das Panel, das ich heute frueh genau dafuer gebaut habe. Es gibt keinen Grund, waehrend eines Rips zu scannen: Das Laufwerk ist belegt, und **welche Disc drin ist, wissen wir bereits** — der Job laeuft ja auf ihr. ## Zwei Stellen, weil es zwei Wege hinein gibt 1. `_auto_prescan` bricht ab, wenn auf dem Geraet ein Job laeuft. Das verhindert jeden Scan, der NACH dem Rip-Start angestossen wird. 2. Der Job-Start raeumt eine haengende Marke weg. Ein Scan, der KURZ VORHER begann, haelt sie sonst bis zu seinem Ende fest. Verloren geht dabei nichts: Unter `_laeuft` steht nur der Platzhalter, und der laufende Scan traegt sein Ergebnis spaeter selbst nach. 880 Tests gruen, ruff sauber. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-29 15:54:48 +02:00
HitonabiandClaude Opus 5	548742e771	fix(windows): Restzeit blieb ewig „wird gemessen" — zwei Docker-Annahmen ... Commander: „Über den kompletten vorgang steht dort ‚Restzeit wird gemessen' aber messung wird nicht abgeschlossen. Das heißt man hat kein ETA" Zwei Ursachen, beide unabhaengig, beide toedlich fuer sich allein. ## 1. Die Messreihe lag nur in Redis `eta.py` schrieb sie ausschliesslich in den Cache — mit der Begruendung im Modul-Kopf: „Der Cache (Redis) ist schon da". Im Container stimmt das. Auf einem Windows-PC gibt es kein Redis: `cache_get` gab bei JEDEM Aufruf None zurueck, `beobachtung_hinzufuegen` legte also jedes Mal eine frische Reihe mit EINEM Punkt an — und `restzeit_sekunden` braucht `MINDEST_PUNKTE = 2`. Jetzt wird in beide Ablagen geschrieben: in den Cache, wo es einen gibt (er ueberlebt einen API-Neustart), und in ein Woerterbuch im Prozess. Das ist ein paar Zahlen gross, gilt nur fuer die Dauer eines Jobs, und im eigenstaendigen Betrieb gibt es ohnehin nur diesen einen Prozess. Alte Reihen werden nach einem Tag weggeraeumt. ## 2. Der Ereignisstrom rechnete die Restzeit gar nicht Die Rechnung stand nur in `/jobs`. Der SSE-Schnappschuss baute seine Jobs mit dem nackten `_job_row_to_model` — also ohne Restzeit. **Seit der Umstellung auf den Ereignisstrom (V2-3) liest die Oberflaeche aber genau diesen Schnappschuss und nicht mehr `/jobs`.** Die Restzeit wurde also brav berechnet und niemandem gezeigt. Beides jetzt in `jobs_fuer_ui()` — dieselbe Lehre wie bei `laufwerke_mit_disc` heute frueh: Eine Auskunft in zwei Fassungen ist eine Fassung zu viel. Nebenbei: Unlesbare Einstellungen duerfen die Jobliste nicht umwerfen. Seit sie auch den Schnappschuss baut, haengt daran die ganze Oberflaeche — zwei Snapshot-Tests wurden davon prompt rot. ## Beweis Job in der Datenbank, Fortschritt 10 % -> 25 % ueber 130 s: nach 1. Messpunkt : eta_text='' (richtig, eine Messung reicht nicht) nach 2. Messpunkt : 674 s, „noch ca. 11 min" 877 Tests gruen, ruff sauber. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-29 15:49:59 +02:00
HitonabiandClaude Opus 5	aeb3128a85	fix(windows): Dauerscan der Disc, aufblitzende Fenster, Docker-Einstellung uebernommen ... Commander: „liest er die disc NOCHMAL ein das macht aber keinen sinn, wenn er sie bereits erkannt hat. Außerdem öffnen sich nun immer irgendwelche fenster ganz kurz im hintergrund." ## Beides war dieselbe Schleife In der Disc-Wache stand: except OSError: continue Damit blieb `bekannt[pfad]` ungesetzt, und im naechsten Durchlauf war `vorher is None` — also wieder „Erststart, liegt schon eine Disc drin". **Ein einziger fehlgeschlagener Lesevorgang loeste einen neuen Vor-Scan aus.** Und der scheitert regelmaessig: Waehrend der Vor-Scan laeuft, haelt makemkvcon das Laufwerk (gemessen: /devices braucht dann 14 s statt 5). Also Scan haelt das Laufwerk -> Statusabfrage scheitert -> naechster Durchlauf haelt es fuer den ersten -> neuer Scan. Eine Schleife, die sich selbst am Leben haelt. Und weil derselbe makemkvcon-Aufruf in `prescan.py` als EINZIGER kein `creationflags=OHNE_FENSTER` hatte, blitzte bei jeder Runde eine Konsole auf. Das war meine Zeile von heute Vormittag. Die Entscheidung steckt jetzt in `disc_entscheidung()` — pure Funktion, also ohne Laufwerk pruefbar. Zwei getrennte Fragen statt einer: Haben wir dieses Laufwerk je gelesen, und was war zuletzt drin? Ein Fehlschlag beantwortet die zweite nicht und darf die erste nicht zuruecksetzen. Nachgemessen: Ein Tabwechsel loest KEINEN neuen Scan aus (8 Erkennungen vorher, 8 nachher). Meine erste Zaehlung von „7 vs 8" war ein Messfehler — zwei verschieden grosse Abfragefenster. ## Aus dem Docker-Betrieb uebernommen `docker/worker/entrypoint.sh` setzt vor jedem Worker-Start zwei Dinge: `app_Key` und `app_UpdateEnable`. Der Key war schon uebernommen, die zweite nicht — auf dem Rechner des Commanders nachgesehen: NICHT gesetzt. Das ist MakeMKVs Web-Kontakt; darueber holt es die Disc-Schluessel fuer 4K-UHD nach (Meldung 3338, auf Windows gemessen). „Fuer Windows umschreiben" heisst hier: Registry statt settings.conf, DWORD statt Text — die Nachbarwerte (`app_BackupDecrypted`) zeigen die Form. Gesetzt wird NUR, was fehlt: Wer den Web-Kontakt bewusst abgeschaltet hat, behaelt ihn abgeschaltet. Ein Waechter-Test vergleicht kuenftig die `app_*`-Namen aus der entrypoint.sh gegen die Windows-Seite — sonst driften die beiden Betriebe auseinander. 871 Tests gruen, ruff sauber. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-29 15:30:29 +02:00
HitonabiandClaude Opus 5	f0d39b4d04	docs(savepoint): laufende Disc-Erkennung sichtbar, verwaiste makemkvcon notiert ... Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-29 15:13:43 +02:00
HitonabiandClaude Opus 5	e67138e9ca	feat(ui): Laufende Disc-Erkennung ist jetzt sichtbar ... Commander: „das die disc erkennung noch läuft muss sichtbar sein" Er hat recht, und die Wartezeit ist gemessen: `makemkvcon info` laeuft an einer Blu-ray in seine 120-Sekunden-Grenze (Disc nach 119 s erkannt). Zwei Minuten, in denen NICHTS zu sehen war — weder die Disc noch ein Hinweis. Das sah aus wie ein leeres Laufwerk, also wie ein Fehler. ## Der Zustand war da, er wurde nur weggeworfen `_auto_prescan` legt beim Start `{"_laeuft": True}` in den Vorrat. `laufwerke_mit_disc` liess so einen Eintrag KOMPLETT weg — damit keine halbfertige Disc-Karte mit „Wird erkannt…" als Titel und einem „Rippen starten"-Knopf erscheint. Richtig gedacht, falsch geloest. Jetzt gibt es ein eigenes Feld `disc_wird_erkannt`. Die Oberflaeche kann „wird gelesen" zeigen, ohne einen Titel zu behaupten, den es noch nicht gibt: eine Karte mit Spinner ueber der Laufwerksliste und eine eigene Zeile im Server-Status. ## Und der Haken dahinter Genau waehrend der Erkennung ist die Laufwerks-Auskunft am teuersten: makemkvcon haelt das Laufwerk, und `device_info` wartet mit. Gemessen: /devices waehrend des Scans 14,0 s Zeitgrenze des Schnappschusses 5,0 s -> devices = None `None` heisst „konnte nicht nachsehen", und die Oberflaeche behaelt dann ihren Stand — nach einem frischen Laden also GAR NICHTS. Die Anzeige waere ausgerechnet in ihrer eigenen Phase leer geblieben. `laufwerke_notdurft()` antwortet deshalb ohne ioctl: letzter bekannter Stand plus die aktuelle Erkennungs-Marke aus dem Vorrat. Beim Kaltstart wenigstens der Laufwerksname — die LISTE der Laufwerke ist billig, teuer ist erst das Anfassen. Nichts wird erfunden: kein Typ, kein Modell. Und wer noch nie erfolgreich gelesen hat, schweigt weiter mit `None`. Im Browser gegengeprueft: „Disc wird gelesen — Laufwerk G:" mit Spinner, Server-Status „Disc wird gelesen — das dauert bis zu zwei Minuten", danach der richtige Titel. 859 Tests gruen, ruff sauber. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-29 15:12:35 +02:00
HitonabiandClaude Opus 5	dbb934d146	docs(savepoint): v4.0-rc7 — Drueberinstallieren, Linux-Reste, Ordner-Waehler, Jobzeile ... Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-29 15:01:34 +02:00
HitonabiandClaude Opus 5	7b0c41ddfe	fix(ui): Datum 1.1.1970, Disc nicht erkannt, kein Abbrechen — eine Ursache je Fall ... Vier Befunde aus einem Bildschirmfoto vom 29.08.2026. ## 1. „das Datum ist falsch" — und der Typ auch TYP „DISC" STARTZEIT „1.1.1970, 01:00:00" STATUS „running" ⚠️ Das war MEIN Fehler von heute Vormittag. Ich hatte `type`, `device` und `startTime` in das Job-Ereignis aufgenommen — mit Feldnamen, **die es in der Datenbankzeile nicht gibt**. Dort heissen sie `disc_type` und `created_at`; die Uebersetzung macht `_job_row_to_model`, und sie bildet auch `running` auf `processing` ab. Die Folge war schlimmer als das Problem davor: Statt eines FEHLENDEN Feldes kam ein LEERES. `new Date(null)` ist der 1.1.1970, und „DISC" war der Rueckfall, den ich zwei Stunden vorher fuer genau diesen Fall eingebaut hatte. Aus „offensichtlich kaputt" war „sieht plausibel aus" geworden. Und mein Test hat es nicht gefunden, weil ich seine Beispielzeile selbst erfunden habe — mit meinen falschen Feldnamen. Ein Test, der dieselbe Annahme macht wie der Code, prueft nichts. Der neue geht von der ECHTEN Zeile aus. Der Waechter bekommt jetzt dieselbe Uebersetzung eingespritzt, die auch `/jobs` benutzt. ## 2. „Es ist eine Disk im laufwerk, aber er erkennt sie dort nicht" Die Laufwerksliste wurde an DREI Stellen gebaut: `/devices` haengte die erkannte Disc an, der Ereignis-Waechter und der SSE-Schnappschuss nicht. Das Dashboard liest den Schnappschuss — und schloss aus der fehlenden Disc auf ein leeres Laufwerk, waehrend ihr Titel eine Zeile weiter oben stand. Jetzt gibt es `laufwerke_mit_disc()`, und ein Test zaehlt die Aufrufe von `device_info` — bei zwei ist er rot. ## 3. „man kann einen rip garnicht abbrechen" Dieselbe Ursache wie 1: Es gab genau EINEN Abbrechen-Knopf, in der Kachel „laufender Job". Die erscheint nur bei Status `processing`; der Strom lieferte `running`. Keine Kachel, kein Knopf, kein Weg zurueck — und aus demselben Grund stand „Aktiv (0)", waehrend der Rip lief. Zusaetzlich gibt es den Knopf jetzt in der Job-Zeile selbst, wo man ihn sucht. ## 4. „bei ‚Platz für rippy' sollte eher das arbeitsverzeichnis und der ## Ablagepfad sein" Dort stand eine nackte Zahl fuer den ERSTEN Ort. Welcher Ordner das war, sah man nicht — und die zweite Zeile fiel ganz weg, wenn beide auf derselben Platte lagen. Das stimmt fuer die ZAHL und war der falsche Schluss fuer den ORT. Jetzt stehen beide da, mit Pfad, plus der Hinweis, dass der Platz geteilt wird. Im Browser gegengeprueft: „Disc erkannt — wartet auf ‚Rippen starten'", BLU-RAY mit richtigem Datum, beide Pfade, keine Konsolenfehler. 852 Tests gruen, ruff sauber. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-29 15:00:11 +02:00
HitonabiandClaude Opus 5	b2acddbdfa	fix(windows): Drueberinstallieren, Linux-Reste im Windows-Betrieb, Ordner-Waehler ... Vier Fragen des Commanders vom 29.08.2026, drei davon mit Codefolge. ## 1. „Was passiert wenn man die Setup.exe einfach drueber installiert?" Bis hierher: nicht zuverlaessig. Rippy startet mit Windows, laeuft also fast immer — dann ist `Rippy.exe` gesperrt, `shutil.copy2` warf PermissionError, und die neue Fassung landete als `Rippy.exe.neu` daneben. Dazu die Meldung „wird beim naechsten Start uebernommen". **Diese Zusage hat niemand eingeloest.** `.neu` kam im ganzen Projekt genau einmal vor: an der Stelle, die es schrieb. Wer drueberinstallierte, behielt still die alte Fassung, und das Setup meldete Erfolg. Jetzt wird der laufende Rippy vorher beendet (`dienst_beenden` gibt es seit der Deinstallation und wartet auch die zwei Sekunden ab, die Windows fuer die Dateihandles braucht). Eine von einer aelteren Setup-Fassung liegengelassene `.neu` wird dabei uebernommen. Bleibt die Datei DANN noch gesperrt, gibt es einen klaren Fehler statt einer Zusage — Rippy im Infobereich beenden und das Setup erneut starten. Der Tausch laeuft bewusst im SETUP und nicht beim Dienststart: Windows sperrt eine laufende .exe, und `Rippy.exe` waere genau die zu ersetzende Datei. ## 3. Linux-Reste im Windows-Betrieb (Docker/Headless unveraendert) **`caps.py`: `os.path.isdir("/app")`.** Damit hielt sich der eigenstaendige Windows-Rippy fuer einen FREMDEN Worker — und das UI warnte vor fehlender Pfad-Uebersetzung auf einer Maschine ohne Container und ohne Freigabe. „Extern" heisst jetzt, was es meint: Rippy laeuft woanders als dieser Worker. **`caps.py`: `shutil.which("makemkvcon")` + `os.path.ismount(daten_dir)`.** Beide unter Windows immer falsch (Programme liegen nicht im PATH, ein normaler Ordner ist kein Mount). Die Schluessel-Auskunft blieb dauerhaft „unbekannt", obwohl MakeMKV samt Datenverzeichnis da war. Der Mount-Test bleibt fuer den Container, wo er einen Zweck hat. **`rohdaten.py`: `/app/temp/raw` und `/app/media` fest.** Dieses Modul findet die Rohdaten eines Jobs wieder — fuer den Wiederholen-Dialog und fuer „Rohdaten mitloeschen". Unter Windows fand es NIE etwas: Der Dialog meldete „keine Rohdaten", das Aufraeumen loeschte nichts, und die Bruchstuecke eines abgebrochenen Rips blieben liegen (bei 4K-UHD bis 100 GB). Sieben Tests wurden dabei rot, und zwar zu Recht: Sie pruefen Container-Regeln, liefen aber unter Windows. Die Wurzeln sind jetzt einspritzbar — beide Betriebsfaelle auf jedem Rechner pruefbar statt vom laufenden abhaengig. ## 4. „Der Durchsuchen button fehlt. Wie es der Installer auch macht" Neu: `OrdnerWaehler` — Pfadfeld plus „Durchsuchen …", benutzt fuer Ablage und Arbeitsverzeichnis. Es waere der DRITTE fest eingebaute Ordner-Browser geworden (RipTargetModal, StorageMounts); dieser hier ist wiederverwendbar. `/browse` weiss seit dem 28.08. selbst, in welchem Betrieb es laeuft. ⚠️ Beim Einbau fiel der Import unter den Tisch. `vite` pruefte das NICHT — das Buendel blieb byte-gleich gross, und zur Laufzeit waere es der naechste leere Bildschirm gewesen. Aufgefallen nur, weil die erwartete Anzahl Ersetzungen nicht stimmte. Im Browser gegengeprueft: alle sieben Laufwerke, Navigation in D:\, keine Konsolenfehler. 843 Tests gruen, ruff sauber. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-29 14:28:01 +02:00
HitonabiandClaude Opus 5	21b1757aa4	docs(savepoint): v4.0-rc6 — leerer Bildschirm und zwei weitere Container-Wurzeln ... Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-29 14:15:58 +02:00
HitonabiandClaude Opus 5	423374e65a	fix(windows): Roh- und Zielordner landeten in einem Ordner namens „app" ... Beim Nachstellen des leeren Bildschirms lief ein echter Test-Rip durch. Die Rohdaten landeten in: F:\app\temp\raw\<job>\Evangelion 2.22_t00.mkv (436 MB) Also in einem Ordner namens `app` auf dem Laufwerk, von dem Rippy gerade lief. ## Zwei Container-Wurzeln im Worker RAW_DIR = /app/temp/raw MEDIA_ROOT = /app/media Unter Windows sind das keine Pfade, sondern Unfaelle. Schlimmer: Die Pruefung `unter_wurzel(wahl, MEDIA_ROOT)` verwarf auch eine AUSDRUECKLICHE Wahl — ein Arbeitsordner wie `D:\Roh` liegt nicht unter `/app/media`, also fiel er still auf den Container-Standard zurueck. **Damit kam der Arbeitsordner, den der Commander am 28.08.2026 ausdruecklich bestellt hat, unter Windows nie an.** Der Dialog zeigte ihn, das Setzen ging, und der Worker ignorierte ihn — ohne ein Wort. Dasselbe galt fuer das Ziel: Eine UNC-Freigabe liegt unter gar keiner lokalen Wurzel, also waere die fertige Datei in `X:\app\media\bluray` gelandet. ## Die Wurzeln kommen jetzt aus dem Betrieb Im Container aendert sich NICHTS: dort ist `/app/media` die Wurzel und `frei` falsch. Nativ zaehlt die Wahl des Nutzers — dort IST sein Laufwerk die Grenze. Die drei bestehenden Tests wurden rot, und zwar zu Recht: Sie pruefen die Container-Regel, liefen aber unter Windows, wo `frei` gilt. Die Wurzeln sind deshalb einspritzbar — beide Betriebsfaelle sind jetzt auf jedem Rechner pruefbar, statt vom laufenden abzuhaengen. 837 Tests gruen, ruff sauber. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-29 14:15:17 +02:00
HitonabiandClaude Opus 5	27c9d9a4bb	fix(ui): Leerer Bildschirm nach „Rippen starten" — ein halber Job riss alles mit ... Commander: „wenn man auf rippen starten klickt passiert irgendwas, was das Programm nicht mag. Der Hintergrund ist einfach leer und er startet nix. Es gibt auch keine fehlermeldung." Nachgestellt: Dienst lokal gestartet, Disc-Karte geoeffnet, „Rippen starten" geklickt. Browser-Konsole: TypeError: Cannot read properties of undefined (reading 'toUpperCase') ## Er startet sehr wohl — man sieht es nur nie Waehrend die Seite leer war, lief der Job (per API gemessen: status `processing`, progress 12). Das „er startet nix" ist also der zweite Teil desselben Fehlers: Die Oberflaeche war weg, bevor sie ihn zeigen konnte. ## Die Ursache `_job_kurz` in `bus/waechter.py` trug nur `status`, `progress`, `title` und `error` — **keinen `type`**. Das UI fuegt aus `job.created` einen halben Job in seine Liste ein, `LiveLogSection` liest `job.type.toUpperCase()`, und React baut bei einem Fehler im Zeichnen den GESAMTEN Baum ab. Es gab in diesem Projekt keine einzige Fehlergrenze — also blieb ein leerer Bildschirm ohne jede Meldung. ## Drei Reparaturen, weil es drei Fehler waren 1. **Das Ereignis traegt den Job.** `type`, `device` und `startTime` fahren mit. Sie aendern sich ueber die Lebenszeit eines Jobs nie, kosten also kein zusaetzliches Ereignis — und ohne `startTime` stand in der Jobliste sekundenlang „Invalid Date". 2. **Das UI vertraegt sein Fehlen.** `LiveLogSection` und `TypeBadge` nahmen einen vollstaendigen Job an. Zeile 108 derselben Datei hatte das Fragezeichen laengst, Zeile 48 nicht. 3. **Eine Fehlergrenze.** Ein Fehler in einer Karte darf nicht den ganzen Bildschirm mitnehmen — und schon gar nicht schweigend. Jetzt steht da, was los ist, die Navigation bleibt bedienbar, und der Hinweis sagt das Wichtigste: laufende Rips gehen weiter. ## Warum es niemand gefunden hat `unterschiede()` bekommt die Kurzform schon fertig, und alle Tests reichen ihre eigenen Woerterbuecher herein. **`_job_kurz` selbst war nie geprueft.** Jetzt bewacht `UI_PFLICHTFELDER` den Vertrag mechanisch — es gibt kein gemeinsames Typsystem zwischen Python und dem UI. Gegengeprueft im Browser: derselbe Klick, keine Konsolenfehler, Job erscheint als „Alle (1)". 833 Tests gruen, ruff sauber. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-29 14:10:12 +02:00
HitonabiandClaude Opus 5	d9780a4951	docs(savepoint): v4.0-rc5 — Rippy rippt, drei Fehler im Rip-Pfad behoben ... Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-29 13:52:52 +02:00