348 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
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
HitonabiandClaude Opus 5	954f293871	fix(windows): Rippen ging nicht — drei Container-Annahmen im Rip-Pfad ... Commander: „Das Rippen der disk funktioniert nicht. makemkvcon endete mit Code 11 — letzte Meldung: Das Öffnen der Disk schlug fehl — keine MKV-Datei entstanden" In diesem einen Satz steckten drei Fehler. Alle drei an seinem Laufwerk gemessen, nicht hergeleitet. ## 1. Die Quellenangabe — das war der Abbruch dev:\.\G: MSG:2024 „Unknown device" -> MSG:5010 Öffnen schlug fehl dev:G: 68 TINFO-Zeilen, „Die Aufgabe wurde erfolgreich abgeschlossen" `f"dev:{device_path}"` stand an VIER Stellen. Unter Linux richtig (/dev/sr0), unter Windows nicht: `rippy.drives.windows` meldet den Geraete-Namensraum `\.\G:`, den `CreateFileW` fuer die IOCTLs braucht — MakeMKV kennt ihn nicht. ## 2. „Ö" statt „Ö" `Ö` als UTF-8 (C3 96), gelesen als cp1252. `subprocess` stand auf `text=True` ohne `encoding=`, nahm also die Gebietsschema-Kodierung; Rippy stellt seine Konsole beim Start aber auf UTF-8 (sonst stirbt der Start an einer Umlaut-Logzeile). Direkt gemessen kommen die Bytes je nach Umgebung als UTF-8 ODER cp1252 — deshalb wird jetzt bestimmt statt behauptet. ## 3. Die Ursache fehlte im Fehlertext Gesucht wurde nach ENGLISCHEN Textbausteinen („evaluation period has expired"). Auf einem deutschen Windows trifft keiner. Jetzt zaehlen die Meldungs-NUMMERN, die sprachunabhaengig sind. ⚠️ Beim ersten Anlauf hatte ich 5021 aus dem Kopf mit „Volume-Key unbekannt" beschriftet — falsch. Meine eigene Ausgabe zeigte nur meine Beschriftung statt MakeMKVs Text, sodass es fast durchgegangen waere. Der echte Wortlaut steht jetzt im Code. ## Nebenbefund: der Beta-Key lag zweimal am falschen Ort `makemkv_daten.DATEN_DIR` war fest `/root/.MakeMKV`. Nach der Reparatur des Ordners blieb MSG:5051 trotzdem stehen — weil MakeMKV unter Windows seine Einstellungen in der REGISTRY haelt (HKCU\Software\MakeMKV), nicht in einer settings.conf. Nachgesehen statt vermutet. Und der wichtigste Teil davon: **Ein abgelehnter Schluessel ist schlimmer als gar keiner.** Ohne Key las MakeMKV die Disc noch (68 TINFO), mit dem abgelehnten verweigerte es alles (0 Titel). Deshalb wird jetzt geprueft und bei Ablehnung zurueckgenommen. ## Beweis Echter Rip ueber `ripping.run_makemkv`, kuerzester Titel: Status success, Code 0, „Evangelion 2.22_t03.mkv" 217,9 MB 5036 „Das Kopieren wurde abgeschlossen. 1 Titel wurden gesichert." 828 Tests gruen, ruff sauber. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-29 13:52:06 +02:00
HitonabiandClaude Opus 5	73ed104bbc	docs(savepoint): Arbeitsordner im Setup, Beta-Key auf Knopfdruck ... Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-29 11:54:18 +02:00
HitonabiandClaude Opus 5	678fe276f9	feat(windows): Arbeitsordner im Setup, Beta-Key auf Knopfdruck ... Zwei Wuensche des Commanders vom 28.08.2026. ## 1. „kannst du noch einbauen das man den arbeitsordner usw. in den ## Einstellungen setzen kann und direkt im setup?" In den Einstellungen ging es seit 35370fd (freies Pfadfeld plus die Laufwerke als Ein-Klick-Wahl). Im SETUP wurde bisher nur nach Programmordner und Ablage gefragt — der Arbeitsordner tauchte erst auf, wenn schon installiert war. Das ist die falsche Reihenfolge: Der Roh-Rip einer 4K-UHD ist bis zu 100 GB gross. Wer erst NACH der ersten vollen Platte erfaehrt, wo die liegen, hat es zu spaet erfahren — genau so lief am 25.07.2026 die VM-Platte voll. Neu ist auch ein Waechter, der alle drei Arten von halb angeschlossenem Feld faengt (kein Eingabefeld, keine Vorbelegung, wird beim Installieren nicht mitgeschickt). Der dritte Fall ist der gemeinste: Man waehlt etwas, es passiert nichts, und niemand sagt warum. ## 2. „der könnte theoretisch auch automatisch ausgelesen werden, ich glaube ## das web rippy kann das" Er hatte recht. `makemkv_key.refresh_loop()` laeuft seit jeher taeglich mit (main.py, Startereignis). GEMESSEN am 28.08.2026: Forum antwortet in 3,3 s, gueltiger Key mit 62 Zeichen, und in seinen Einstellungen lag bereits einer. Es war nur nichts davon zu sehen. Kein Knopf, keine Meldung, keine Zeitangabe — im Feld stand ein Key, und ob der von Hand kam oder von selbst, wusste niemand. Eine Automatik, die man nicht sehen kann, ist fuer den Benutzer keine. Dazu kam eine echte Luecke: Die Schleife startet 60 Sekunden nach dem Server. Wer gleich nach dem Einrichten eine Blu-ray einlegt, rippt ohne Key — MakeMKV faellt in den 30-Tage-Testmodus. Das Setup holt ihn jetzt selbst. Der geholte Key wandert NICHT ueber die Leitung zurueck: Er steht in den Einstellungen, und ein zweiter Weg zu demselben Wert ist ein zweiter Weg, ihn zu verlieren. Rechtlich unveraendert: oeffentliche Beta-LIZENZ der Software, KEIN Disc-Schluessel. Rippy liefert und verteilt keine Disc-Schluessel. 803 Tests gruen, ruff sauber. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-29 11:53:12 +02:00
HitonabiandClaude Opus 5	d0281f7a1b	style: Zeilenenden zurueck auf LF (kein Inhalt geaendert) ... In 35370fd habe ich fuenf Dateien versehentlich von LF auf CRLF umgestellt. Der Inhalt stimmte, aber der Diff war unlesbar: 1363 geaenderte Zeilen fuer 30 echte in RipTargetModal.tsx, 1184 fuer 29 in setup_fenster.py. Nachgewiesen mit `git diff --ignore-cr-at-eol` — damit blieben 56/9 uebrig. Ursache: Ein Rueckschreiben im Textmodus stellt die ganze Datei um. Die Regel stand als Warnung schon in meinem Gedaechtnis, dort aber nur in der anderen Richtung (CRLF -> LF). Sie gilt in beide. Dieser Commit aendert AUSSCHLIESSLICH Zeilenenden. Nachgewiesen: `git diff --ignore-cr-at-eol` listet keine dieser fuenf Dateien. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-29 11:52:08 +02:00
HitonabiandClaude Opus 5	6881a63fb7	docs(savepoint): v4.0-rc4 — Cover, Arbeitsverzeichnis, aufgeraeumte Temp-Ordner ... Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 16:45:52 +02:00
HitonabiandClaude Opus 5	35370fd552	fix(windows): Cover, Arbeitsverzeichnis und die zurueckgelassenen _MEI-Ordner ... Drei Befunde des Commanders vom 28.08.2026, alle drei gemessen. ## 1. „Was ist mit dem Cover auf Windows Rippy?" Es gab keins, weil es keinen Treffer gab. `_scan_video` verlangte woertliche Gleichheit: if movie.get("title", "").lower() == kandidat.lower(): An seiner Disc gemessen: 'Evangelion 2.22' 1 Treffer Evangelion: 2.0 You Can (Not) Advance 'Evangelion' 20 Treffer irgendein Evangelion Der EINZIGE Treffer auf den vollen Disc-Titel war der richtige Film, mit Poster — und wurde verworfen. Jetzt zaehlt die SPEZIFITAET der Anfrage: Wer auf den vollen Disc-Titel hoechstens drei Treffer bekommt, hat gefragt wie jemand, der weiss was er sucht. Ergebnis an derselben Disc: Evangelion: 2.0 You Can (Not) Advance / 2009 / 80 % / Poster + dt. Text ## 2. „Warum heisst das hier noch container platte? … Waere es moeglich das ## Arbeitsverzeichnis zu aendern? momentan geht das nicht." Beide Haelften gehen auf EINE Zeile zurueck: `MEDIA_ROOT = "/app/media"` war zugleich Vorgabe UND Pfadgrenze. Auf Windows gibt es den Ordner nicht: * `/storage-targets` fing den OSError und gab still [] zurueck — die Auswahl hatte genau einen Eintrag. Das ist „momentan geht das nicht". * Dessen Text war fest verdrahtet „(Container-Platte)". * `/browse` antwortete auf jeden Pfad mit 422. Die Grenze faellt nicht weg, sie wird betriebsabhaengig: Container und Kopflos-Betrieb bedienen ein Netz, die native App den Menschen davor. Gemessen auf seinem PC: 7 Laufwerke zur Auswahl, X/Y/Z mit je 2,2 TB frei. ## 3. „Failed to remove temporary directory: …_MEI0000b0882" GEMESSEN: 20 zurueckgelassene _MEI-Ordner mit 1,1 GB. Ursache: `Popen` ohne `env=` reicht PyInstallers Auspack-Zeiger an die Kinder weiter (--dienst und --oeffnen). Beide laufen dann im Ordner des Elternprozesses, der sich zuerst beendet und ihn loeschen will. Waere das TEILWEISE geglueckt, haetten Dienst und Fenster mitten im Betrieb ihre Dateien verloren. Nebenbefund: test_setup_fenster scheiterte in jeder Umgebung ohne pywebview. 794 Tests gruen, ruff sauber. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 16:43:41 +02:00
HitonabiandClaude Opus 5	11001a443e	docs: SAVEPOINT v4.0-rc3 — Windows testbereit ... Stand vor dem Test des Commanders. Zwei Dinge stehen bewusst gross drin: die seit V2-1 tote Metadaten-Suche (betrifft die VM genauso) und die bekannte Luecke bei Audio-CDs unter Windows. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 16:09:24 +02:00
HitonabiandClaude Opus 5	be3fac53af	fix(prescan): makemkvcon ueber den Katalog suchen, nicht ueber shutil.which ... Auf die Frage des Commanders: "du hast jetzt nur mein laufwerk analysiert oder? wenn ich rippy weitergebe wie laeuft es dort?" Berechtigt -- und beim Nachsehen fiel derselbe Fehler auf wie heute Vormittag im Werkzeug-Katalog: shutil.which("makemkvcon") -> None, auch bei installiertem MakeMKV `which` sucht nur im PATH. Windows-Programme liegen in "Programme". Der Zweig, der die Titelliste von makemkvcon holt, lief unter Windows also NIE -- unabhaengig vom Laufwerk, auf jedem Rechner. Jetzt ueber `katalog.finden("makemkv")`, das genau dafuer da ist. Dazu vier Tests fuer Disc-Arten, die ICH NICHT HABE, damit die Zusage nicht an einer einzigen Disc haengt: Blu-ray ohne BDMV/META -> None (sehr haeufig; Rueckfall aufs Label) DVD (nur VIDEO_TS) -> None bdmt_deu.xml vorhanden -> Titel wird gelesen deu + eng vorhanden -> eng gewinnt (APIs suchen damit besser) Und ein Waechter gegen shutil.which in prescan.py. Der erste Anlauf davon fiel ueber den eigenen Erklaertext, in dem der alte Aufruf zitiert wird -- er prueft jetzt nur Code, keine Kommentare. Ampel lokal: 774 gruen, ruff sauber. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 16:05:25 +02:00
HitonabiandClaude Opus 5	878b24c43b	fix: die Metadaten-Suche war seit V2-1 tot — auf Windows UND auf der VM ... Der Commander: "TMDB und OMDB Key sind hinterlegt, das laufwerk wird aber auch nicht korrekt ausgelesen. Eigentlich sollte er direkt bei TMDB oder OMDB oder JIKAN anfragen nach metadaten." Er hat das Symptom gemeldet. Darunter lagen VIER Fehler. ## 1. Ein Phantom-Modul (der schwerste) clients/tmdb.py:27 from db import get_settings clients/omdb.py:36 from db import get_settings clients/thetvdb.py:16 from db import get_settings `docker/api/db.py` gibt es seit der Zusammenlegung in V2-1 (dd1d0b7) nicht mehr; main.py schreibt seitdem `from rippy import store as db`. Diese drei Module haben es nie mitbekommen. Damit starb JEDE Metadaten-Abfrage schon beim Erzeugen des Clients mit ModuleNotFoundError -- und `_auto_prescan` verschluckte das in seinem `except Exception`. Die Disc blieb namenlos, und niemand sah warum. **Das betrifft die VM genauso.** Sie steht auf 05ab655, also NACH dd1d0b7 -- dort laeuft seit V2-1 dieselbe tote Metadaten-Suche. ## 2. Redis war Pflicht statt Beschleunigung `cache/cache.py` sprach `redis:6379` an -- den Dienstnamen aus docker-compose.yml. Auf einem Windows-PC gibt es kein Redis: redis.exceptions.ConnectionError: Error 11001 connecting to redis:6379 Das riss den Pre-Scan mit. Ein Zwischenspeicher ist eine Beschleunigung, keine Voraussetzung: Jetzt faengt jeder Zugriff den Verbindungsfehler ab und meldet "nicht vorhanden" -- was der Wahrheit entspricht. Gemeldet wird der Ausfall EINMAL, nicht bei jeder Anfrage. ## 3. Der Klartext-Titel war unter Windows nicht erreichbar `read_disc_title_via_mount` machte fest `mount -t udf` -- also Linux. Unter Windows haengt Windows die Disc selbst ein. An der echten Disc gemessen: Volume-Label (UDF) BD_EVG_D2 <- damit findet keine API etwas BDMV/META/DL/bdmt_deu.xml Evangelion 2.22 `disc_wurzel()` liefert jetzt je Plattform einen lesbaren Einstieg, und `titel_aus_bdmt()` ist davon getrennt (und damit ohne Disc pruefbar). ## 4. Modell und Seriennummer fehlten Im UI stand "Modell: unbekannt, Seriennummer: -". Der Linux-Treiber liest beides aus /sys; der Windows-Treiber lieferte leere Felder. Die Entsprechung ist IOCTL_STORAGE_QUERY_PROPERTY. An echter Hardware gemessen: hersteller 'HL-DT-ST' modell 'BD-RE BU40N' fassung '1.03' seriennummer '0025114C0149' Gemerkt statt jedes Mal abgefragt: Die Disc-Wache ruft device_info alle drei Sekunden, und die Angaben eines Laufwerks aendern sich nicht. ## Ergebnis, an der eingelegten Disc gemessen title 'Neon Genesis Evangelion' year 1995 disc_type 'Blu-ray' confidence 0.8 fingerprint 'BD_EVG_D2|48149364736' (Jikan antwortete waehrend der Messung mit 504 -- deren Ausfall, nicht unserer. Der Treffer kam von TMDB.) Zwei Waechter, beide beim Zurueckdrehen rot gesehen: Die Clients muessen sich OHNE Datenbank und OHNE Redis bauen lassen, und ein `from db import` in clients/ faellt mechanisch auf. Ampel lokal: 769 gruen, ruff sauber. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 15:59:47 +02:00
HitonabiandClaude Opus 5	ea8a043643	feat(setup): Fortschrittsbalken, MakeMKV-Installer mit Rechteabfrage, Updates ... Drei Punkte des Commanders vom 28.08.2026. ## 1. "bei der installation eine progress bar waere gut" Die Daten dafuer waren schon da -- der Fortschritts-Rueckruf traegt seit jeher einen Anteil, die Bruecke warf ihn nur weg. Jetzt rechnet `Fortschritt` Abschnitt + Teil-Anteil in einen Gesamtstand um. Die Gewichte sind gemessen: Dateien ablegen 0-8 % (rund drei Sekunden), Ablage 8-10 %, Werkzeuge 10-97 % (sechs Sekunden bis mehrere Minuten). Ein Balken, der bei 90 % minutenlang steht, ist schlimmer als gar keiner. Zwei Regeln, beide mit Test: * Er laeuft NIE zurueck. Der Werkzeug-Abschnitt kann mehrere Downloads enthalten, jeder mit eigenem 0-bis-1 -- ohne die Regel spraenge der Balken bei jedem neuen Werkzeug an den Abschnittsanfang. Zusaetzlich rechnet `sicherstellen` den Anteil eines Werkzeugs auf die ganze Strecke um. * Eine Textmeldung ohne Zahl bewegt ihn nicht. Sie ist keine Aussage ueber den Fortschritt. Am laufenden Fenster nachgewiesen: "Werkzeuge werden geprueft -- 36 %", Balken bernsteinfarben, am Ende gruen bei 100 %. ## 2. "make MKV laesst sich nicht installieren weil der vorgang erhoehte ## rechte benoetigt" Der Kern, und der Fehler lag bei uns: `subprocess.Popen` benutzt `CreateProcess`, und das ZEIGT KEINE UAC-Abfrage -- es bricht mit ERROR_ELEVATION_REQUIRED (740) ab. MakeMKV installiert nach Program Files und fordert im Manifest Administratorrechte an. `ShellExecuteW` ist der dokumentierte Weg, der die Abfrage ausloest. Damit braucht NUR dieser eine Aufruf die Erhoehung. Und deshalb laeuft das Setup NICHT dauerhaft erhoeht (dazu die Antwort im Chat): Ein erhoehter Prozess sieht die eingebundenen Netzlaufwerke nicht -- auf diesem Rechner gemessen, X:, Y:, Z: ohne Erhoehung sichtbar, EnableLinkedConnections nicht gesetzt. Genau das hatte der Commander vorher selbst als Fehler gemeldet. Wer trotzdem erhoeht starten will, bekommt einen Knopf -- aber nur, wenn das Schreibrecht am gewaehlten Ziel wirklich fehlt. ## 3. "wenn MakeMKV oder Handbrake schon installiert sind ein update ## verfuegbar ist. Das kann ja direkt im setup abgehandelt werden." `veraltete()` vergleicht nach ZAHLEN (ein Zeichenvergleich hielte 1.9.2 fuer neuer als 1.11.2 -- und HandBrake ist genau dort). `sicherstellen` holt sie auf Wunsch mit, aber IMMER nach den fehlenden: Ein Update ist Komfort, ein fehlendes Pflichtwerkzeug ist ein Hindernis. Der Assistent zeigt es als eigenen Schalter mit Klartext ("MakeMKV 1.18.2 -> 1.18.4"). Der Update-Check laeuft als GETRENNTER Aufruf nach der Voraussetzungs-Pruefung: Er kostet Netz, und makemkv.com braucht dafuer im schlimmsten Fall gut zwanzig Sekunden -- in der Pruefung bliebe das Fenster so lange leer. Sind die Quellen nicht erreichbar, schaltet sich der Haken ab und sagt warum; ein Haken, der nichts tun kann, ist eine Falle. Ampel lokal: 758 gruen, ruff sauber. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 15:38:51 +02:00
HitonabiandClaude Opus 5	95beb91364	feat(tools): Ausweichquellen fuer MakeMKV — recherchiert und gemessen ... Commander: "bitte baue fuer MakeMKV fallback seiten ein." Anlass war ein echter Ausfall. Am 28.08.2026 gemessen: https://www.makemkv.com/download/ HTTP 525 (dauerhaft) https://makemkv.com/download/ HTTP 525 http://www.makemkv.com/download/ HTTP 403 https://forum.makemkv.com/ 200 / 522 / Zeitablauf (wechselnd) web.archive.org/web/2025id_/...exe 200, 16.432.607 Bytes 525/522 heissen: Cloudflare erreicht den Ursprungsserver nicht. Eine Stoerung beim Hersteller -- dieselbe, die im Projekt schon einmal jeden Worker-Build lahmgelegt hat. ## Die Kette Version: Hersteller-Seite (massgeblich) -> Forum-Ankuendigungen -> Archiv Datei: eigene Quelle -> Hersteller -> Internet Archive Der Hersteller zuerst, immer. Das Archiv ist Rueckfallebene, und Rippy nennt hinterher die Quelle, aus der die Datei kam. Zwei Feinheiten, beide aus Messungen statt aus dem Kopf: * Die HOECHSTE Nummer gewinnt, nicht die erste. Antwortet das Forum nicht, meldet das Archiv einen aelteren Stand (1.18.2 statt 1.18.4) -- "neueste Fassung" waere dann eine falsche Aussage. * Ein zweiter Anlauf, mit knapper Zeitgrenze. Drei Abrufe am Forum: TimeoutError, HTTP 522, dann Erfolg. Ohne Wiederholung fiel die Quelle in zwei von drei Faellen aus; mit 20-Sekunden-Grenzen dauerte der schlimmste Fall 46 Sekunden, in denen das Setup eingefroren aussah. Jetzt acht Sekunden je Versuch, schlimmstenfalls gut zwanzig. ## Warum eine fremde Quelle trotzdem sicher ist Der naheliegende Schutz geht NICHT: MakeMKV signiert seinen Installer nicht (Get-AuthenticodeSignature -> NotSigned, an der echten Datei gemessen). Eine Signaturpruefung waere eine, die immer fehlschlaegt -- schlimmer als keine, weil sie Sicherheit vortaeuscht. Geprueft wird die Versions-Ressource, ebenfalls gemessen: CompanyName GuinpinSoft inc FileDescription MakeMKV installer FileVersion v1.18.4 Das ersetzt keine Signatur, faengt aber ab, was hier wirklich droht: eine Fehlerseite mit .exe-Namen, ein abgebrochener Download, eine falsche Fassung. Ende zu Ende nachgewiesen, ohne etwas zu installieren: Version laut Kette: 1.18.4 Hersteller: HTTP 525 -> uebersprungen Internet Archive: 15,7 MB in 6,1s Pruefung: BESTANDEN (MakeMKV v1.18.4) Die Grenze aus KONZEPT.md 6 bleibt: Rippy liefert MakeMKV weiterhin NICHT mit. Es holt die Datei des Herstellers -- im Rueckfall aus einem Archiv, das genau diese Datei aufbewahrt. Ampel lokal: 733 gruen, ruff sauber. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 15:19:46 +02:00
HitonabiandClaude Opus 5	480b658294	fix: die Laufwerks-Pruefung muss selbst einspritzbar sein ... Ampel-Lauf zu 16df61e rot, und diesmal am Gegenteil: assert 'Administratorrechte' in 'Statt des Laufwerksbuchstabens den UNC-Pfad eintragen (\Server\Freigabe).' `pfade.laufwerk_von` zerlegte den Windows-Pfad jetzt richtig -- aber `os.path.isdir("C:\")` ist auf Linux immer False, also galt JEDES Laufwerk als fehlend und der falsche Zweig griff. Die Frage "existiert Laufwerk Q:" laesst sich auf dem Linux-Runner ueberhaupt nicht beantworten, dort gibt es keine Laufwerksbuchstaben. Also gehoert sie in eine eigene, einspritzbare Funktion (`laufwerk_fehlt`) -- ohne die waere der Zweig nur auf einem Windows-Rechner mit genau diesem fehlenden Laufwerk pruefbar, also nirgends. Dieselbe Lehre wie bei pruefe_windows heute Vormittag: **Ein Plattform-Vergleich mitten in einer Funktion macht jeden Einspritzpunkt davor wertlos.** Vor dem Push den Linux-Fall lokal nachgestellt (os.name auf "posix" gesetzt): Program Files, Programme und ein fehlendes Q: landen jetzt alle im richtigen Zweig. Ampel lokal: 715 gruen, ruff sauber. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 14:56:10 +02:00
HitonabiandClaude Opus 5	16df61ea3a	fix: pruefe_schreibrecht nahm os.path statt pfade — zum vierten Mal dieselbe Falle ... Ampel-Lauf zu 3d5f82b rot: assert 'nicht vorhanden' in 'Q:\Rippy (Pfad nicht gefunden)' `os.path.splitdrive` kennt auf Linux kein "Q:" und gab einen leeren String zurueck, also fiel die Pruefung in den allgemeinen Zweig. Genau dafuer gibt es seit einer Stunde `rippy/pfade.py` -- und ich habe es hier nicht benutzt. Das ist das vierte Vorkommen desselben Musters an einem Tag (katalog, verknuepfungen, betrieb, jetzt einrichtung). Die Regel steht im Kopf von pfade.py und gilt ohne Ausnahme: **Der Pfad entscheidet, nicht der Rechner.** Gegengeprueft, dass es keine fuenfte Stelle gibt: kein os.path.splitdrive und kein direkter ntpath-Aufruf mehr ausserhalb von pfade.py. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 14:53:26 +02:00
HitonabiandClaude Opus 5	3d5f82b786	fix(windows): der Deinstallierer beendet jetzt auch den laufenden Dienst ... Beim Deinstallieren im laufenden Betrieb blieben liegen: rippy.db, rippy.db-shm, rippy.db-wal (Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird) Der Dienst lief weiter und hielt die Datenbank offen. Damit waere der Fehler von vorhin durch eine andere Tuer zurueckgekommen: Die naechste Installation haette wieder den alten Zustand samt setup.done geerbt, und der Ersteinrichtungs-Assistent waere wieder verschwunden. Aufgefallen ist es nur, weil der Deinstallierer seit heute NENNT, was er nicht wegbekommen hat. Vorher stand dort ein `except OSError: pass` und die Meldung "Rippy wurde entfernt". Gefiltert wird ueber den Installationsordner, nicht ueber den Namen: `Rippy.exe` heisst auch die Datei, die den Auftrag gerade ausfuehrt. Die eigene Prozesskennung und die des PyInstaller-Starters sind ausgenommen. Nachgewiesen am laufenden Prozess: beendet, Datenbankdateien danach loeschbar. In der Entwicklungsumgebung schlaegt der Pfadvergleich uebrigens immer fehl -- die Werkzeuge laufen in einem App-Container, der %LOCALAPPDATA% umleitet, waehrend die Registry den echten Pfad meldet. Das steht jetzt als Hinweis im Docstring, damit es niemand ein zweites Mal sucht. Ampel lokal: 713 gruen, ruff sauber. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 14:50:50 +02:00
HitonabiandClaude Opus 5	8e65411189	fix(windows): die Datenbank lag AUSSERHALB der Installation — daher fehlte ... der Ersteinrichtungs-Assistent Der Befund des Commanders: "Ausserdem fehlt der 1st run wizzard wenn man es installiert." Meine erste Reparatur (App.tsx las einen gescheiterten Abruf als "erledigt") war richtig, aber nicht die Ursache. Nachgemessen: Installation %LOCALAPPDATA%\Rippy wird deinstalliert Datenbank %ProgramData%\Rippy BLEIBT LIEGEN Eine "frische" Installation erbte damit die alte Datenbank samt `setup.done = true` -- der Assistent erschien nie wieder. Gegengeprueft: nach dem Aufraeumen meldet /api/setup wieder {"done": false}, und das Fenster zeigt "Willkommen bei Rippy". Der Grund fuer den alten Ort stand im Docstring: "Ein Programmordner ist unter Windows fuer einen DIENST nicht zuverlaessig beschreibbar." Das stimmte -- fuer den Windows-Dienst, den es nie gab. Rippy laeuft als der angemeldete Benutzer (Autostart unter HKCU). Jetzt liegt alles, was Rippy gehoert, in EINEM Ordner: Programm, UI, Werkzeuge, Protokoll, WebView2-Zwischenspeicher und die Datenbank. Dazu: * `datenbank_umziehen()` holt eine vorhandene Datenbank vom alten Ort ab -- wer Rippy schon benutzt hat, behaelt Jobs und Einstellungen. Gibt es am neuen Ort schon eine, bleibt sie unangetastet: Die BENUTZTE gewinnt. * `deinstallieren()` raeumt den alten Ort mit weg, und `alte_orte()` fasst nur einen Ordner an, der wirklich "Rippy" heisst. * Der Ersteinrichtungs-Assistent spricht nicht mehr von "Encoding-Worker", wenn es keine gibt -- dort steht jetzt "Kompression". Gegengeprueft: kein "docker", kein "Container", kein "Worker" mehr im Text. Ampel lokal: 709 gruen, ruff sauber. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 14:46:02 +02:00
HitonabiandClaude Opus 5	082e8b8b55	fix(windows): der Knopf "Rippy oeffnen" oeffnete Rippy nicht ... Nach einer erfolgreichen Einrichtung schloss er nur das Fenster, und danach passierte nichts mehr: Der Dienst lief nicht, kein Fenster ging auf. Der Commander hat Rippy anschliessend selbst gestartet ("das tool selbst laesst sich starten") -- was den Fehler verdeckt hat. Ein Knopf, der etwas anderes tut als seine Beschriftung sagt, ist schlimmer als keiner. Jetzt startet main() nach einem geglueckten Assistenten das installierte Programm. Dazu der zweite Teil des Netzlaufwerk-Befunds: Auch Netz-ANMELDUNGEN haengen am Token der Sitzung, nicht nur die Laufwerksbuchstaben. Ein erhoehter Prozess kennt die Zugangsdaten zur Freigabe nicht und bekommt "Zugriff verweigert" -- also dieselbe Meldung wie bei einem echten Rechteproblem. Ein UNC-Pfad mit Administratorrechten wird jetzt als solcher erkannt und erklaert. Ampel lokal: 705 gruen, ruff sauber. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 14:38:17 +02:00
HitonabiandClaude Opus 5	6dfff5c99d	fix(windows): vier Befunde aus dem ersten echten Installationslauf ... Alle vom Commander gemeldet, alle nachgestellt. ## 1. Der Installer brach ab: No module named 'db' Fehlgeschlagen: ModuleNotFoundError: No module named 'db' Zu Recht: **docker/api/db.py gibt es nicht.** Seit der Zusammenlegung in V2-1 ist der Store `rippy.store`; main.py schreibt seitdem `from rippy import store as db`. Ich habe mir aus einem ALIAS ein Modul zusammengereimt und importiert -- genau die erfundene Schnittstelle, vor der AGENTS.md Regel D warnt, nur diesmal im eigenen Code. Der Store wird jetzt direkt benutzt; der Umweg ueber den API-Suchpfad war ohnehin ueberfluessig. ## 2. Der Ersteinrichtungs-Assistent fehlte nach der Installation In App.tsx stand: .catch(() => setSetupDone(true)) // API/Setup nicht erreichbar -> nicht blockieren Das Fenster geht unmittelbar nach dem Setup auf, der Dienst braucht ein bis zwei Sekunden bis zur ersten Antwort -- der erste Abruf scheitert also fast immer. Aus "ich konnte nicht nachsehen" wurde "ist schon erledigt", und der Assistent war fuer immer weg. Dasselbe Prinzip steht nebenan in useEventStream.tsx: Ein Verbindungsabriss ist KEINE Aussage ueber die Welt. Jetzt wird nachgefragt, bis der Server ANTWORTET (zwei Minuten lang alle zwei Sekunden), und solange steht "Rippy startet ..." im Fenster statt einer leeren Flaeche. ## 3. + 4. Als Administrator keine Netzlaufwerke, Netzlaufwerk = "keine Rechte" Beides Windows-Verhalten, kein Rippy-Fehler -- aber Rippy hat ihn hineinlaufen lassen. Auf dem Rechner nachgemessen: X:, Y:, Z: Netzlaufwerke EnableLinkedConnections nicht gesetzt (Standard) C:\Program Files (x86) ohne Administrator nicht beschreibbar Ein erhoehter Prozess bekommt ein anderes Zugriffstoken; eingebundene Netzlaufwerke haengen am Token der Sitzung und existieren dort schlicht nicht. Daraus wird ein Teufelskreis: Program Files verlangt Administrator Administrator versteckt die Netzlaufwerke Netzlaufwerk wirkt dann wie "keine Schreibrechte" Rippy braucht ueberhaupt keine Administratorrechte (Vorgabeordner unter %LOCALAPPDATA%, Autostart unter HKCU). Der Assistent sagt das jetzt: * eine eigene Pruefung "Rechte", die bei erhoehtem Start warnt und die unsichtbaren Laufwerke beim Namen nennt * ein fehlender Laufwerksbuchstabe wird als solcher gemeldet, nicht als fehlendes Schreibrecht ("Laufwerk Q: ist hier nicht vorhanden") * ein Ziel unter "Programme" erklaert den Kreis und verweist auf den Vorgabeordner ## Dazu: zwei Schreibfallen in AGENTS.md Deutsche Anfuehrungszeichen in doppelt gequoteten Zeichenketten (vier Mal an einem Tag) und Bash-Heredocs, die Backslashes halbieren (fuenf Mal, zuletzt beim Schreiben genau dieses Absatzes). Ein Test dafuer waere Rauschen gewesen -- Python faengt beides bereits beim Import, nur mit verwirrender Meldung. Die Regel gehoert in die Konventionen, nicht in eine Pruefung. Ampel lokal: 703 gruen, ruff sauber. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 14:36:56 +02:00
HitonabiandClaude Opus 5	8eca982e68	docs: SAVEPOINT v4.0-rc2 — Windows ist ein eigenes Produkt ... Die drei Befunde des Commanders und was dahinter steckte, plus der teuerste Fund des Tages: %ProgramFiles(x86)% wurde auf einer echten Maschine NIE aufgeloest, weil der Test genau die Schreibweise einspritzte, die im Muster stand. Er war gruener als die Wirklichkeit. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 14:03:04 +02:00
HitonabiandClaude Opus 5	151376aee3	fix: Pfad-Regeln an EINE Stelle — dreimal dieselbe Falle war zweimal zu viel ... Ampel-Lauf zu b47d215 rot, drei Fehlschlaege, alle mein eigener Code: platz_orte os.path.splitdrive kannte auf Linux kein "D:" -> zwei Laufwerke galten als eines naechster_vorhandener os.path.dirname zerlegte C:\Users\Test\... nicht pruefe_windows die Plattform-Pruefung stand VOR der eingespritzten Version -> pruefe_windows(22631) gab auf Linux FEHLER `os.path` richtet sich nach der Maschine, auf der es laeuft. Das ist fast immer richtig -- und an jeder Stelle falsch, an der ueber Pfade einer ANDEREN Maschine gerechnet wird. Genau das war heute schon zweimal da: tools/katalog.py C:\Program Files (x86)\MakeMKV/makemkvcon64.exe platform/verknuepfungen dirname() einer .lnk gab einen leeren String Zweimal einzeln repariert, beim dritten Mal gehoert es an EINE Stelle: `rippy/pfade.py` mit `ist_windows_pfad`, `verbinden`, `ordner_von`, `laufwerk_von`, `gleiches_laufwerk`, `naechster_vorhandener`. Die Regel steht dort im Kopf: **Der Pfad entscheidet, nicht der Rechner.** katalog, verknuepfungen, betrieb und einrichtung benutzen jetzt alle dasselbe. Und `pruefe_windows` beachtet einen eingespritzten Wert wieder. Ein Einspritzpunkt, der ignoriert wird, ist keiner -- dann sind die Tests daneben, die ihn benutzen. Sieben neue Tests in test_pfade.py, die BEIDE Zweige pruefen und deshalb ueberall laufen. Das war der eigentliche Mangel: Jede dieser drei Fallen war nur auf der jeweils anderen Plattform sichtbar. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 14:00:34 +02:00
HitonabiandClaude Opus 5	b47d21510d	docs: Entscheid 6 — Faehigkeiten statt Modus-Name, und ein Setup das fragt ... Beide Befunde des Commanders vom 28.08.2026 festgehalten, mitsamt der Begruendung, warum ein 'if (windows)' an dreissig Stellen die falsche Reparatur gewesen waere: Die Oberflaeche haette weiterhin nichts ueber ihren Betrieb gewusst, nur eine zweite Sorte Vermutung gehabt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 13:56:41 +02:00
HitonabiandClaude Opus 5	a4a045f303	feat(windows): ein echtes Setup — Voraussetzungs-Pruefung, Zielordner, Ablage ... Commander: "Dann haette ich beim 'Setup' auch erwartet das nen echtes setup passiert - wo will ich das hinspeichern, nen pre requirement check usw. Da kommt garnichts Rippy geht einfach auf." Er hatte recht. Ein Doppelklick installierte stillschweigend nach %LOCALAPPDATA%\Rippy und oeffnete das Fenster. Der Nutzer wurde nichts gefragt und erfuhr nichts -- auch nicht, ob sein Rechner ueberhaupt kann, was Rippy braucht. Jetzt: ein Assistent mit acht Pruefungen, zwei Ordner-Wahlen und drei Schaltern. Auf diesem Rechner nachgemessen: OK Betriebssystem Windows 11 (Build 26200) OK Fenster (WebView2) 151.0.4129.107 OK Optisches Laufwerk \.\G: OK HandBrakeCLI 1.11.2 ! MakeMKV nicht gefunden -> wird von makemkv.com geholt OK Speicherplatz 59.1 GB frei OK Schreibrecht C:\Users\...\AppData\Local\Rippy OK Netzwerk-Port 7788 ist frei Drei Entwurfsentscheidungen, die dazugehoeren: * Nur ein FEHLER blockiert, eine Warnung nicht. Eine Warnung, die den Knopf sperrt, ist eine Bevormundung; ein Fehler, der nur warnt, ist eine Falle. Kein Laufwerk = Warnung (reine Komprimier-Maschine ist ein vorgesehener Betriebsfall). Kein Schreibrecht = Fehler. * Jeder Befund sagt, was zu tun ist. Ein Befund ohne Abhilfe laesst den Nutzer ratlos zurueck -- ein Test haelt das fuer jede Pruefung fest. * Die Pruefungen stehen in einrichtung.py, komplett ohne Fenster pruefbar. Im Fenstermodul steht nur Aufbau und Bruecke. WebView2 statt Win32-Dialog: Es ist ohnehin da (Entscheid 4), der Assistent kostet damit NULL zusaetzliche Bytes. Die Seite laedt nichts aus dem Netz -- sie muss auf einem Rechner ohne Internet aufgehen, dort wird sie am dringendsten gebraucht. Ein Test haelt das fest. --still und --ohne-assistent gehen weiterhin den stummen Weg. Geht das Fenster nicht auf, wird mit den Vorgaben installiert und gesagt warum -- ein Setup, das gar nichts tut, weil sein Fenster nicht aufging, waere schlimmer als eines, das nicht fragt. fix(tools): %ProgramFiles(x86)% wurde auf echten Rechnern NIE aufgeloest Beim Bauen der Pruefung aufgefallen, und es ist ein Lehrstueck: Testumgebung {"ProgramFiles(x86)": ...} -> C:\Program Files (x86)\... echtes Windows {"PROGRAMFILES(X86)": ...} -> '' Windows behandelt Umgebungsvariablen ohne Ruecksicht auf die Schreibweise und legt sie in os.environ GROSS ab. Der Vergleich in _entfalten war exakt, fand nie eine Uebereinstimmung, und die bekannten Installationsorte fielen aus der Kandidatenliste. MakeMKV wurde also NUR ueber die Registry-Rueckfallebene gefunden -- wo die fehlt oder anders aussieht, fand Rippy nichts. Aufgefallen ist es nur, weil hier zum ersten Mal eine ECHTE Umgebung benutzt wurde. Der Test spritzte genau die Schreibweise ein, die im Muster stand: Er war gruener als die Wirklichkeit. Beide Tests nehmen jetzt die echte Schreibweise, und einer prueft direkt gegen os.environ. Beim Zurueckdrehen des Fehlers rot gesehen (5 Fehlschlaege). Ampel lokal: 691 gruen, ruff sauber. Assistent im Bildschirmfoto belegt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 13:54:59 +02:00
HitonabiandClaude Opus 5	66642b8d93	feat(ui): die Oberflaeche weiss jetzt, worauf sie laeuft ... Commander-Befund 28.08.2026, zum Windows-Fenster: Worker erreichbar: 0 von 1 Kein Worker antwortet — Pruefen: docker compose ps Container-Platte: unbekannt Freigaben: keine eingehaengt Kein Satz davon ergibt auf einem Windows-PC einen Sinn. Sein Urteil: "Du hast ja quasi nur rippy genommen und die docker installation fuer Windows gebaut. Das gilt fuer die ganze standalone version fuer Windows, auch fuer die settings und die Anleitung usw." ## Die Ursache war nicht die Anzeige Die naheliegende Reparatur waere ein `if (windows)` an dreissig Stellen gewesen -- dieselbe Falle noch einmal, nur mit einer zweiten Sorte Vermutung. Es fehlte etwas anderes: Das UI hat nie erfahren, worauf es laeuft. config.py kennt das Profil seit V2-2, weitergegeben wurde es nie. Also hat das UI angenommen. Neu: GET /betrieb meldet FAEHIGKEITEN, keinen Modus-Namen. externe_worker Gibt es andere Maschinen, die Jobs uebernehmen? freigaben_einhaengen Kann Rippy Netzwerk-Freigaben selbst einhaengen? container_pfade Sind Pfade wie /app/media ueberhaupt gemeint? werkzeuge_verwalten Kann Rippy MakeMKV/HandBrake selbst beschaffen? Ein Modus-Name wuerde das UI zwingen, aus einem Namen auf Verhalten zu schliessen -- und das bricht beim naechsten Betriebsfall: Ein Docker-All-in-One hat Container-Pfade, aber keinen zweiten Worker. ## Was sich sichtbar aendert (auf Windows nachgemessen) Server-Status "Rippy arbeitet: auf diesem Rechner" statt Worker-Zaehler "Platz fuer Rippy: 59.2 von 232 GB frei" statt "unbekannt" Freigaben-Block faellt weg Einstellungen kein Reiter "Worker"; Speicherziele BLEIBT (dort steht die Ablage -- "wo will ich das hinspeichern" war die Frage), aber mit Pfadfeld statt Container-Auswahl und ohne die Maske zum Einhaengen Anleitung kein docker, kein Encoding-Worker-Abschnitt, stattdessen der echte Ordner (C:\Users\...\Videos\Rippy) ## Zwei Fehler, die dabei aufgefallen sind * MEDIA_ROOT = "/app/media" war in main.py fest verdrahtet. shutil.disk_usage warf unter Windows, die Liste blieb leer -- daher "unbekannt", obwohl auf dem Laufwerk 59 GB frei waren. Eine Nichtauskunft, die wie eine Auskunft aussieht. platz_orte() liefert die Orte jetzt je Betrieb, und ein noch nicht angelegter Ordner faellt auf das naechste vorhandene Elternteil zurueck. * Der SSE-Schnappschuss enthielt den Server-Zustand NICHT, und der Waechter schickt ihn nur alle 15 Sekunden. Nach jedem Neuladen stand deshalb bis zu eine Viertelminute "unbekannt" da. Jetzt ist er im Schnappschuss, und das UI uebernimmt ihn auch von dort. Dazu: der Windows-Skip in test_api_smoke.py ist weg. Er stammte aus der Zeit vor V2-4, als main.py fcntl brauchte; seit der Treiberwahl ueber den Port laedt es auf beiden Plattformen (57 Routen, gemessen). Damit laufen 20 Tests mehr auch lokal statt nur auf der Ampel. Ampel lokal: 654 gruen, ruff sauber. Docker-Zweig durch Unit-Tests gedeckt, am echten Container noch nicht gegengeprueft -- das kommt beim Deploy. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 13:45:00 +02:00
HitonabiandClaude Opus 5	a5e64f8e56	fix(windows): der Deinstallierer liess 148 Dateien liegen und meldete Erfolg ... Beim ersten echten Deinstallieren auf dem Rechner des Commanders gemessen: Uninstall-Eintrag weg Autostart weg Verknuepfungen weg Dateien 149 NOCH DA (davon 148 in fenster\EBWebView\) Gemeldet wurde: "Rippy wurde entfernt." Zwei Ursachen, beide behoben: ## 1. WebView2 ueberlebt Rippy WebView2 startet eigene Prozesse (msedgewebview2.exe: Renderer, GPU, Netz, Crashpad). Stirbt Rippy, laufen sie als Waisen weiter und halten den Zwischenspeicher offen -- acht davon liefen noch, als ich nachsah. shutil.rmtree scheiterte an jeder gesperrten Datei. fenster.helfer_beenden() beendet sie jetzt VOR dem Loeschen. Gefiltert wird ueber den --user-data-dir in der Befehlszeile: msedgewebview2.exe benutzen auch andere Programme, und die alle zu beenden waere ein Uebergriff -- der Nutzer verloere die Fenster fremder Anwendungen. Ein Test haelt fest, dass erst gefiltert und dann beendet wird. ## 2. Der Fehler wurde verschluckt `except OSError: pass` in der Loeschschleife. Ein "Rippy wurde entfernt" ueber einem halb geleerten Ordner ist eine Falschaussage -- genau die Sorte stiller Fehlschlag, vor der AGENTS.md warnt. Jetzt wird gesammelt, was nicht ging, und mit dem Grund genannt. Dazu im Aufraeum-Skript: `rmdir /s /q` statt `rmdir`. Ein blosses rmdir scheitert an JEDER verbliebenen Datei und laesst den ganzen Ordner stehen -- selbst wenn spaeter nur noch eine Sperrdatei uebrig ist. Ampel lokal: 612 gruen, ruff sauber. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 13:15:58 +02:00
HitonabiandClaude Opus 5	ce4e7e6b8a	feat(windows): das Setup richtet MakeMKV und HandBrake wirklich ein ... Commander: "handbrake und makemkv MUESSEN mitgeliefert werden oder waehrend des Setups separat installiert werden! Ohne das ist das tool NICHT einsatzfaehig." Er hat recht, und die Luecke war real: katalog.py konnte die Werkzeuge finden, beschaffen.py konnte sie holen -- das Setup rief beides nie auf. Wer Rippy auf einem frischen Rechner installierte, bekam eine Oberflaeche, die ihm sagte was fehlt, und keinen Weg, es zu aendern. Die beiden gehen unterschiedliche Wege, und der Grund ist die LIZENZ: * HandBrakeCLI ist GPL-2 -> mitgeliefert. Weitergabe ausdruecklich erlaubt, solange Lizenztext und Quellverweis dabei sind (LIZENZ-HandBrake.txt liegt daneben). Damit komprimiert Rippy auch ohne Internet. * MakeMKV ist proprietaer -> beim Einrichten vom Hersteller geholt und mit DESSEN Installer installiert. Weitergabe durch Dritte ist nicht erlaubt. Das ist dieselbe Black-Box-Trennung wie in KONZEPT.md 6 und deckt sich mit KONZEPT-V2.md 4.1 ("MakeMKV wird NICHT mitgeliefert"). Drei Regeln, die dazugehoeren: 1. Ein Setup meldet NIE Erfolg, waehrend ein Pflichtwerkzeug fehlt. sicherstellen() liest den Bestand VOR und NACH dem Versuch und gibt zurueck, was danach wirklich da ist -- nicht, dass es versucht wurde. 2. Ein nicht erreichbarer Download bricht die Installation nicht ab. Am 28.08.2026 antwortete makemkv.com mit HTTP 525. Rippy ist dann trotzdem installiert und sagt im Klartext, was fehlt und wie man es beschafft. 3. Ohne HandBrake ist Rippy einsatzbereit (Rip laeuft, nur ohne Kompression), ohne MakeMKV nicht. Nur Pflichtwerkzeuge entscheiden ueber "bereit". Nachgemessen am fertigen Setup: HandBrake geloescht, installiert, nach DREI Sekunden wieder da (74 MB, also aus dem Paket und nicht geladen), Meldung "Rippy ist einsatzbereit. HandBrakeCLI 1.11.2 / MakeMKV 1.18.4". RippySetup.exe waechst von 32,0 auf 56,4 MB. fix(tools): der Fortschritts-Rueckruf bekommt immer einen Text _datei_laden schickte `None` als Text, wenn sich nur der Fortschritt geaendert hatte. Der erste echte Aufrufer starb daran: can only concatenate str (not "NoneType") to str Ein Rueckruf, den man nur mit einer nirgends dokumentierten Sonderbehandlung benutzen kann, ist eine Falle. Jetzt kommt immer ein Satz, gedrosselt auf jedes zehnte Prozent -- 24 MB in 256-KB-Haeppchen waeren sonst hundert Zeilen im Protokoll. Zwei Tests halten beides fest. Nicht im Repo: Die 70,9 MB HandBrakeCLI holt der BAU nach dist/windows/vendor/ (nicht versioniert) -- dasselbe Muster wie der vendor/-Ordner fuer MakeMKV auf der VM. Ampel lokal: 607 gruen, ruff sauber. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 13:09:01 +02:00
HitonabiandClaude Opus 5	60c0f93237	fix(windows): leere Symbole und der verschwundene Eintrag in "Installierte Apps" ... Beides vom Commander gemeldet, beides gemessen statt vermutet. ## 1. Weisses leeres Blatt statt Symbol In deploy/worker-windows/rippy.ico steckte GENAU EIN Bild: Bilder = 1 256x256 32 bit 5657 Bytes PNG Windows holt sich fuer jede Stelle die passende Groesse -- 16x16 fuer die Taskleiste, 32/48 fuer Desktop und Startmenue. Fehlt sie, skaliert die Shell nicht zuverlaessig selbst, sondern zeigt das leere Blatt. Bei einer Datei mit nur einem PNG-komprimierten 256er passiert das regelmaessig. packaging/windows/icon.py baut die Datei jetzt mit neun Groessen (16/20/24/32/40/48/64/128/256, LANCZOS beim Verkleinern). Nachgemessen an der neuen EXE: 16x16 mit 138 Farben, 32x32 mit 264 -- kein leeres Blatt mehr. build.py laesst ein unvollstaendiges Symbol gar nicht mehr durch, und test_icon.py haelt die Pflichtgroessen fest (mit dem alten Stand rot gesehen). ## 2. Rippy stand nicht in "Installierte Apps" Die Ursache war MEINE Testsuite. Gemessen: Rippy.exe --nicht-starten -> Eintrag: DA (Rippy 2.0.0) pytest -q -> Eintrag: WEG test_installation_legt_die_dateien_an_... schrieb in den ECHTEN Uninstall-Schluessel und loeschte ihn im finally wieder -- also auch den des Commanders. Der Autostart-Eintrag ging denselben Weg. Der Schluesselname stand als VORGABEWERT in jeder Signatur, und Vorgabewerte wertet Python zur Definitionszeit aus: Ein Test konnte ihn gar nicht umbiegen. Jetzt steht dort None, aufgeloest zur Laufzeit -- damit wirkt ein monkeypatch.setattr(reg, "SCHLUESSEL", ...) ueberall. Dazu ein Waechter (test_die_testsuite_ruehrt_den_ECHTEN_eintrag_nicht_an): Er merkt sich den echten Zustand vorher, laesst eine vollstaendige Test-Installation samt Autostart laufen und prueft danach, dass sich am echten Eintrag nichts geaendert hat. Das ist derselbe Fehler wie vorhin bei den Verknuepfungen, nur an anderer Stelle. Die Regel gehoert in den Code, nicht in meinen Kopf: **Ein Test raeumt nur weg, was er selbst angelegt hat.** Ampel lokal: 590 gruen, ruff sauber. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 12:57:50 +02:00
HitonabiandClaude Opus 5	e1984dc543	docs: SAVEPOINT — Ampel wieder gruen, und warum sie fuenf Laeufe rot war ... Nachgetragen: die 28 Linux-Fehler, der schwerste davon (der API-Container waere auf der VM gar nicht hochgekommen), und die Lehre daraus — ein Test, der nur auf einer Plattform greift, ist eine halbe Zusage. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 12:46:22 +02:00
HitonabiandClaude Opus 5	ca212ff835	fix(test): die detection-Attrappe muss auch das PAKET-Attribut ersetzen ... Ampel-Lauf 186: Die 28 echten Linux-Fehler waren weg, uebrig blieben fuenf — alle in meinem neuen Test: TypeError: drive_status() missing 1 required positional argument `from rippy.drives import detection` sieht zuerst im PAKET nach (`_handle_fromlist` prueft `hasattr`) und greift erst dann auf sys.modules zurueck. Auf Linux ist das echte Modul dort laengst gesetzt, weil es importierbar ist — die Attrappe blieb wirkungslos, und der Test lief in die echten Funktionen. Unter Windows fiel das nicht auf: Dort gibt es das Attribut mangels fcntl gar nicht, also griff sys.modules. Derselbe Test, zwei Plattformen, zwei Ergebnisse — genau die Sorte Luecke, die dieser Test eigentlich schliessen soll. Jetzt werden beide ersetzt. Gegengeprueft: mit kaputter Durchreiche fuenf Fehlschlaege, danach wieder gruen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 12:44:05 +02:00
HitonabiandClaude Opus 5	bfc0cada62	fix(windows): kein CMD-Fenster mehr — die EXE ist ein Fenster-Programm ... Commander: "Unterbinde das CMD Fenster was sich beim oeffnen mitoeffnet." Mein erster Anlauf wollte die Konsole VERSTECKEN und war falsch, aus zwei Gruenden: * Eine Onefile-EXE ist ZWEI Prozesse (gemessen: PID 33172 mit 8 MB, PID 33580 mit 103 MB, beide Rippy.exe). Die Pruefung "haengt genau EIN Prozess an der Konsole" war damit nie wahr, das Fenster blieb einfach stehen. * Selbst wenn sie ginge, waere das Fenster erst nach ein bis zwei Sekunden weg. Ein Aufblitzen ist kein "unterbunden". Jetzt wird die Konsole gar nicht erst erzeugt: --windowed statt --console. Nachgemessen am fertigen Bau -- PE-Subsystem 2 (GUI) statt 3 (Konsole), und beim Klick auf die Desktop-Verknuepfung ist genau EIN sichtbares Fenster da: die WinForms-Oberflaeche. Kein ConsoleWindowClass-Fenster von Rippy, weder sichtbar noch unsichtbar. Was dazugehoert, damit daraus kein stiller Fehlschlag wird: * Ohne Konsole ist sys.stdout None. uvicorn schreibt auf stderr und waere mitten im Start gestorben, ohne dass irgendwo etwas stuende. einstieg.py haengt sich deshalb an die Konsole des Aufrufers (--status in PowerShell schreibt weiter dorthin) oder leitet nach %LOCALAPPDATA%\Rippy\rippy.log um. * Der Installer meldet sein Ergebnis in einem Fenster, wenn keine Konsole da ist -- sonst saehe ein gescheiterter Doppelklick aus wie einer, der nichts tut. Bei --still und mit Konsole bleibt es bei der Textzeile. Gegengeprueft am laufenden Programm: /api/health, / und /api/capabilities antworten mit 200, und rippy.log faengt auf, was vorher ins Leere ging. fix(drives): linux.py reicht die detection-Funktionen wieder durch Die Ampel war seit Lauf 181 rot -- vier Commits lang, und ich hatte es uebersehen. Ursache: docker/api/main.py:54 AttributeError: module 'rippy.drives.linux' has no attribute 'drive_status' main.py holt sich beim Import device_discovery.drive_status. Der Windows-Treiber hat die Funktion; linux.py hatte sie nicht mehr, seit detection (und damit fcntl) bewusst nicht mehr oben importiert wird -- sonst waere main.py unter Windows nicht ladbar. Unter Windows lief also alles, auf Linux waere der API-Container gar nicht hochgekommen. Behoben mit PEP 562 (__getattr__), demselben Kniff wie in store/__init__.py: Der Import bleibt ohne fcntl moeglich, wer die Funktionen BENUTZT bekommt sie. Dazu drei weitere Fehler, die nur auf Linux auftraten: * katalog.py baute Windows-Pfade mit os.path.join. Auf dem Linux-Runner wurde daraus C:\Program Files (x86)\MakeMKV/makemkvcon64.exe. Jetzt entscheidet der Pfad selbst ueber den Trenner, nicht die rechnende Maschine. * verknuepfungen.py nahm os.path.dirname fuer den Arbeitsordner einer .lnk. Eine .lnk zeigt IMMER auf einen Windows-Pfad -- also ntpath. * waechter.py las 0.0 als Zeitpunkt statt als "noch nie geprueft". Auf einer frisch gestarteten Maschine ist time.monotonic() klein, also fiel die erste Laufwerks-Abfrage aus. None statt 0.0. Alle vier haben jetzt Tests, die auf JEDER Plattform laufen -- der Treiber-Test schiebt eine detection-Attrappe unter, der Waechter-Test stellt eine Uhr bei 0,5 s nach, die Pfad-Tests pruefen beide Zweige. Beim Wegnehmen der Durchreiche rot gesehen (5 Fehlschlaege), danach wieder gruen. Damit faengt die Ampel so etwas kuenftig, ohne dass es eine Linux-Umgebung auf dem Entwicklungsrechner braucht. Ampel lokal: 582 gruen, ruff sauber. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 12:41:10 +02:00
HitonabiandClaude Opus 5	e1577a4f47	docs: SAVEPOINT v4.0-rc — Windows ist ein echtes Programm ... Der SAVEPOINT stand seit V2-3 still, waehrend elf Commits dazukamen. Nachgetragen mit den gemessenen Zahlen: 562 gruen, RippySetup.exe 31,7 MB, WebView2 151.0.4129.107, 5 Encoder auf diesem PC. Zwei Dinge stehen bewusst gross drin, weil sie sonst verloren gehen: * Der Dienst, der /api/health mit 200 beantwortete und / mit 404 -- und warum ein %TEMP%-Verzeichnis kein Ort fuer eine Oberflaeche ist. * Der Test, der den PC des Commanders getroffen hat. Ein Test, der Spuren ausserhalb von tmp_path hinterlaesst, ist kein Test, sondern ein Eingriff. Und was NICHT bewiesen ist, steht als solches da: Ein echter Rip unter Windows ist nie gelaufen, die VM haengt elf Commits zurueck. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 12:15:29 +02:00
HitonabiandClaude Opus 5	c01ef1081c	feat(windows): echtes Fenster statt Browser-Tab (WebView2 statt Electron) ... Auf die Frage des Commanders: "Warum nutzen wir fuer Windows weiterhin einen Browser? Warum nutzen wir kein Electron oder sowas und machen daraus einen echten Client." Die erste Haelfte trifft zu und ist umgesetzt. Die zweite ist abgelehnt -- gemessen, nicht geschaetzt: pywebview + WebView2 8,0 MB in der Bau-Umgebung, 2,7 MB in der EXE Electron 150-210 MB, dazu eine zweite Laufzeitumgebung Windows 11 bringt die WebView2-Laufzeit mit (hier 151.0.4129.107). Nachgemessen statt angenommen, was sie rendert: navigator.userAgent ...Chrome/151.0.0.0 Safari/537.36 Edg/151.0.0.0 fetch ja EventSource ja CSS Grid ja Pfeilfunktionen ja Dasselbe Chromium, das auch in Electron steckt -- nur ohne es ein zweites Mal mitzuschleppen. RippySetup.exe waechst von 29,0 auf 31,7 MB. Drei Dinge gehoeren dazu, nicht als Beiwerk: * Kein stiller Rueckfall auf MSHTML. Der alte IE-Renderer stellt die React-Oberflaeche nicht dar. Fehlt WebView2, oeffnet Rippy den Browser und SAGT warum -- ein leeres Fenster waere schlimmer als ein Tab. * Fenster und Tray sind getrennte Prozesse. pystray belegt unter Windows den Haupt-Thread, das Fenster braucht ihn genauso. * Die eigene Konsole wird versteckt, eine geerbte nie. GetConsoleProcessList unterscheidet beides: genau ein Prozess an der Konsole heisst, sie gehoert uns. Ohne diese Unterscheidung haette "Rippy.exe --status" im Terminal das Terminal des Nutzers verschwinden lassen. fix(windows): Oberflaeche neben das Programm legen statt aus %TEMP% bedienen Beim Nachsehen im laufenden Betrieb gefunden: Ein Dienst lief eine Stunde, /api/health gab HTTP 200, / gab 404. Im Fenster stand {"detail":"Not Found"}. Der Server war in Ordnung. Sein Entpack-Verzeichnis war es nicht: _MEI000074b02 31 Eintraege, 5 Ordner -- kein ui, kein api _MEI000082e82 44 Eintraege, 16 Ordner -- vollstaendig Eine PyInstaller-Onefile-EXE liest bei JEDER Anfrage aus %TEMP%\_MEIxxxxx. Ein Temp-Verzeichnis ist kein Ort fuer etwas, das eine Woche liegen bleibt. Und der Ausfall ist der schlimmstmoegliche: Die API antwortet weiter, der Dienst gilt als gesund, nur die Oberflaeche ist weg. Genau davor warnte ROADMAP.md beim Bau-Verfahren ("one-dir statt one-file"). Die Abweichung bleibt, die Luecke wird geschlossen: Der Installer legt die Oberflaeche neben das Programm, daemon._ui_pfad() nimmt diese Kopie zuerst. Zeigt sich derselbe Ausfall an den API-Modulen, ist one-dir die Antwort. Ampel: 562 gruen, ruff sauber. Fenster mit der echten Oberflaeche im Bildschirmfoto nachgewiesen, nicht nur der Titel geprueft. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 12:14:15 +02:00
HitonabiandClaude Opus 5	069fc46f44	fix(test): der Installations-Test hat die ECHTEN Verknuepfungen ueberschrieben ... WAS: `test_installation_legt_die_dateien_an_...` installiert in ein tmp_path — legt aber seit dem Verknuepfungs-Einbau auch Symbole auf dem ECHTEN Desktop und im ECHTEN Startmenue an. Die kennen kein tmp_path. DIE FOLGE, vom Commander gemeldet: Er klickte auf das Desktop-Symbol und bekam von Windows "Diese App kann auf dem PC nicht ausgefuehrt werden". Nachgemessen zeigte die Verknuepfung auf ...\Temp\pytest-of-TobisPC\pytest-142\test_installation_..._0\installiert\Rippy.exe — und dort liegt die 2-KB-ATTRAPPE aus dem Test, kein Programm. Windows hatte voellig recht. Der `finally`-Block raeumte nur Registry und Autostart auf; die Verknuepfungen nicht, weil es sie beim Schreiben des Tests noch nicht gab. Als sie dazukamen, wuchs der Test stillschweigend ueber sein tmp_path hinaus. Ein Test, der Spuren ausserhalb seines Temp-Ordners hinterlaesst, ist kein Test, sondern ein Eingriff. BEHOBEN mit ZWEI Sicherungen statt einer: 1. verknuepfen=False — die Funktion legt gar keine an. 2. vk.alle_anlegen ist trotzdem ersetzt. Wer den Schalter spaeter umdreht oder die Vorgabe aendert, kann damit trotzdem nichts am echten System anrichten. Dazu ein Waechter: test_installation_ruehrt_die_echten_verknuepfungen_ nicht_an prueft, dass die Anlege-Funktionen bei verknuepfen=False GAR NICHT gerufen werden. Waere er frueher dagewesen, haette der Commander keine kaputte Verknuepfung bekommen. DER RECHNER IST REPARIERT: neu installiert, beide Verknuepfungen zeigen wieder auf C:\Users\...\AppData\Local\Rippy\Rippy.exe (29 MB, existiert), Programme+Features-Eintrag ist zurueck. Start ueber die Verknuepfung: HTTP 200 nach 2 s, Worker TobisNicerPC mit cpu-x264/x265/av1 + vce/vce-av1, MakeMKV 1.18.4 und HandBrake 1.11.2 gefunden. Nebenbei ausgeschlossen, bevor die Ursache klar war: Die EXE selbst ist in Ordnung (gueltiges x64-PE, MZ/PE-Kopf, 29 MB, Hash identisch mit dem Installat), kein Mark-of-the-Web, kein Defender-Fund, Smart App Control aus. Der Fehler lag nicht an der Datei, sondern daran, WORAUF gezeigt wurde. GEMESSEN: ruff sauber, 522 Tests gruen + 15 uebersprungen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 11:47:11 +02:00
HitonabiandClaude Opus 5	99c05865af	feat(windows): Desktop-Symbol und Startmenue-Eintrag — plus --oeffnen ... WAS: Das Setup legt jetzt eine Verknuepfung auf dem Desktop UND im Startmenue an, die Deinstallation nimmt beide zurueck, und `--status` zeigt, ob sie da sind. Abwaehlbar mit --keine-verknuepfungen. WARUM (Commander-Meldung): "es gibt kein icon aufm desktop und keinen startmenü eintrag". Zu Recht — ein Hintergrundprogramm ohne Symbol ist praktisch unauffindbar: Es laeuft, aber es gibt keinen Weg hinein ausser der Adresse im Kopf. DIE VERKNUEPFUNG ZEIGT AUF --oeffnen, NICHT AUF --dienst. Ein Doppelklick soll Rippy OEFFNEN; ob der Dienst laeuft, ist dem Nutzer egal und er kann es auch nicht wissen. Zeigte das Symbol auf --dienst, startete jeder Klick einen ZWEITEN Server, der am belegten Port scheitert — das Fenster blitzt auf, im Browser passiert nichts. Ein Symbol, das beim zweiten Klick nichts tut, ist schlimmer als keins. `--oeffnen` sieht deshalb erst NACH, ob jemand antwortet, startet nur wenn noetig, und wartet dann, bis der Dienst wirklich da ist — statt sofort einen Browser auf eine tote Adresse zu schicken. Gemessen: erster Aufruf 2 s bis HTTP 200, zweiter Aufruf keine zusaetzlichen Prozesse. DIE ORDNER KOMMEN AUS DER REGISTRY, nicht aus %USERPROFILE%. Wer OneDrive benutzt oder seine Ordner verschoben hat, dessen Desktop liegt woanders — die Verknuepfung landete dann in einem Ordner, den niemand sieht, und der Nutzer suchte ein Symbol, das es nirgends gibt. UEBER POWERSHELL statt pywin32: Eine .lnk ist ein binaeres Shell-Objekt. pywin32 koennte es, waere aber 20 MB fuer vier Zeilen. Denselben Weg geht der alte Worker-Installer schon ("nativ via PowerShell"). ZWEI FEHLER, DIE DIE TESTS GEFUNDEN HABEN: - os.makedirs stand AUSSERHALB des try. Auf einem Laufwerk, das es nicht gibt, wirft es — aus "Verknuepfung konnte nicht angelegt werden" waere ein Abbruch der ganzen Installation geworden. - Der Test dafuer nahm fest Z: als "gibt es nicht". Auf dem Commander-PC ist Z: ein NETZLAUFWERK (X, Y, Z sind belegt). Ein fest verdrahteter Laufwerksbuchstabe ist eine Annahme ueber eine fremde Maschine; jetzt wird zur Laufzeit ein freier gesucht. Und der Apostroph: In PowerShell wird er innerhalb einfacher Anfuehrungszeichen durch VERDOPPELN maskiert. Ohne das braeche ein Pfad wie C:\Users\O'Brien\... das Skript entzwei, und der Fehler saehe aus wie ein Syntaxfehler in Rippy. GEMESSEN, nach echter Installation nach %LOCALAPPDATA%\Rippy: Desktop-Symbol -> Rippy.exe --oeffnen, mit Symbol und Beschreibung Startmenue -> ebenso Programme+Feat. -> Rippy 2.0.0, 100 MB, Deinstallieren funktioniert Autostart -> "...\Rippy.exe" --dienst Start ueber das Symbol: HTTP 200 nach 2 s Worker: TobisNicerPC, Encoder cpu-x264/x265/av1, vce, vce-av1 GEMESSEN: ruff sauber, 521 Tests gruen + 15 uebersprungen (vorher 512). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 11:40:39 +02:00
HitonabiandClaude Opus 5	f4a8d77598	feat(windows): Rippy arbeitet eigenstaendig — Rippen, Werkzeuge, Fähigkeiten ... WAS: Der Ablauf ist aus tasks.py heraus (ablauf.py, ohne Celery), die LocalQueue wird bedient, ein Laeufer arbeitet Auftraege im selben Prozess ab, und Rippy meldet sich mit gemessenen Faehigkeiten selbst als Arbeiter. WARUM: "Rippy fuer Windows soll standalone funktionieren" (Commander). Bis hierher konnte die Windows-App alles ANZEIGEN und nichts TUN — ein Rip waere eingereiht worden und fuer immer liegengeblieben, weil niemand ihn holt. DIE TRENNUNG: rip_disc hing an GENAU DREI Celery-Stellen in 234 Zeilen — self.update_state, _transcode_queue, transcode_files.apply_async. Alle drei sind Fragen der ZUSTELLUNG, nicht des Ablaufs. Sie sind jetzt Rueckrufe: tasks.py reicht die Celery-Fassung herein, standalone.py die lokale. OHNE Rueckruf komprimiert derselbe Prozess weiter — genau das, was ein Ein-Prozess-Rippy braucht. Der Ablauf selbst ist Zeile fuer Zeile derselbe; der Docker-Betrieb merkt vom Umbau nichts (Task-Namen, Argumente, Queues unveraendert). EINE ZUSTELL-STELLE statt drei: celery_client.abschicken() bedient alle Auftragsarten. Vorher rief jede Stelle send_task selbst auf — der Standalone-Betrieb haette an drei Stellen umgebogen werden muessen, beim naechsten Auftragstyp an einer vierten. WEITERER BLOCKER GEFUNDEN: ablauf.py holte detect_disc_type fest aus dem LINUX-Treiber, in einem try/except. Unter Windows waere es damit IMMER None gewesen und Rippen "hart verriegelt" — Rippy haette alles angezeigt und nichts gerippt, ohne dass irgendwo ein Fehler stuende. Jetzt fragt es den Treiber-Port. WERKZEUGE: ripping.py und caps.py suchten nur im PATH. Auf dem Commander-PC gemessen, vorher/nachher: vorher check_makemkv_installed() -> False (obwohl installiert) erkenne_encoder() -> nur CPU nachher MakeMKV 1.18.4 C:\Program Files (x86)\MakeMKV\makemkvcon64.exe HandBrake 1.11.2 ueber die API geholt, in 2,7 s Encoder cpu-x264, cpu-x265, cpu-av1, VCE, VCE-AV1 107 Presets, Ryzen 7 9700X, 16 Kerne, avx512f VCE ist die Hardwarebeschleunigung der Radeon — die hat Rippy auf diesem Rechner vorher nie gesehen, weil es HandBrake gar nicht fand. NEUE ROUTEN: GET /system/werkzeuge (was liegt wo, in welcher Fassung, gibt es Neueres) und POST /system/werkzeuge/{name}/holen. HandBrake kommt vollautomatisch von GitHub. MakeMKV wird NICHT mitgeliefert — Rippy laedt die offizielle Datei und startet sie (Black-Box-Trennung, KONZEPT.md § 6). makemkv.com antwortete beim Bauen mit HTTP 525; das wird im Klartext gemeldet, und eine selbst geholte Datei bleibt moeglich. HERZSCHLAG: /capabilities las die workers-Tabelle, die bisher nur der Celery-Herzschlag fuellte. Im Standalone-Betrieb stand dort "0 Worker" und die Encoder-Auswahl im UI blieb LEER — auf einem Rechner, der alles kann. Jetzt meldet sich der Prozess selbst, mit dem, was caps.py MISST. GEMESSEN, aus der fertigen EXE (29,0 MB): bereit nach 1 s, keine Fehler im Log Werkzeuge: beide gefunden, mit Version und Pfad Worker: 1 (TobisNicerPC), 5 Encoder, 107 Presets Die ganze Kette ist als Test festgehalten (test_kette.py): zustellen -> einreihen -> Laeufer -> ablauf -> Job endet in einem EHRLICHEN Zustand. Ohne Laufwerk geprueft, und das ist der wichtigere Fall: Ein Rip auf ein totes Geraet muss zuegig scheitern, nicht auf "pending" haengenbleiben. GEMESSEN: ruff sauber, 512 Tests gruen + 15 uebersprungen (vorher 489). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 11:27:54 +02:00
HitonabiandClaude Opus 5	288f9eeb8d	feat(tools): Werkzeuge finden, holen und aktuell halten — Grundlage fuer Windows ... WAS: rippy/tools/ mit katalog.py (finden + Version) und beschaffen.py (herunterladen, installieren, Update-Stand). ripping.py und caps.py fragen den Katalog statt shutil.which. DER BEFUND, DER DAS NOETIG MACHT: Der Bestand suchte AUSSCHLIESSLICH mit shutil.which(). Im Container stimmt das — dort liegen beide Werkzeuge in /usr/local/bin. Unter Windows findet es NICHTS, auch wenn alles installiert ist: Windows-Programme liegen in Program Files, nicht im PATH. Am 28.08.2026 auf dem Commander-PC nachgesehen — MakeMKV lag unter "C:\Program Files (x86)\MakeMKV\makemkvcon64.exe", which sah es nicht. Fuer einen Rippy, der unter Windows eigenstaendig arbeiten soll, ist das der Unterschied zwischen "laeuft" und "laeuft nicht". Vorher/nachher gemessen: vorher check_makemkv_installed() -> False (obwohl installiert) nachher check_makemkv_installed() -> True build_makemkv_cmd()[0] -> C:\Program Files (x86)\MakeMKV\makemkvcon64.exe SUCHREIHENFOLGE, mit Begruendung im Modul: eingestellt > Rippys eigener Werkzeug-Ordner > PATH > bekannte Installationsorte > Uninstall-Zweig der Registry. Rippys eigener Ordner steht VOR dem System, damit eine selbst gepflegte Fassung eine alte Systeminstallation schlaegt. VERSION: HandBrakeCLI kann --version. makemkvcon KANN DAS NICHT (usage.txt kennt keinen solchen Schalter) — die Version kommt aus dem Uninstall-Zweig. Dort steht bei MakeMKV zwar eine Version, aber InstallLocation ist LEER (nachgesehen); deshalb wird der Ordner ersatzweise aus DisplayIcon bzw. UninstallString abgeleitet. Der Test dafuer hat sofort einen Fehler gefunden: '"C:\...\uninstall.exe" /S' liess sich mit einem blossen strip('"') nicht aufloesen. BESCHAFFUNG, an echter Hardware gemessen: HandBrake GitHub-Release-API -> 1.11.2, HandBrakeCLI-1.11.2-win-x86_64.zip geladen, entpackt, gestartet: meldet sich als 1.11.2. 2,8 s. MakeMKV makemkv.com antwortete mit HTTP 525 (Cloudflare) — auch mit Browser-Kennung. Dieselbe Sperre, die im Projekt schon den Docker-Bau lahmlegt. Deshalb: Abruf wird versucht, ein Fehlschlag wird im Klartext gemeldet, und eine selbst geholte Datei laesst sich weiterhin verwenden. Ein Update-Server, der heute antwortet, darf keine Startbedingung fuer morgen sein. DREI FALLEN, GEGEN DIE ES TESTS GIBT: - Die .sig-Datei liegt im Release direkt neben dem ZIP und ist 566 Bytes gross. Wer nur nach "win" filtert, laedt sie. - "1.9.2" ist als Zeichenkette GROESSER als "1.11.2". Ein Update-Hinweis, der ab Version zehn dauerhaft in die Irre fuehrt — und genau dort ist HandBrake gerade. - Eine Fehlerseite kommt oft mit HTTP 200. Sie darf keine funktionierende Installation ersetzen: erst laden, pruefen, dann tauschen. Und: Ist die neueste Version unbekannt (Quelle tot), steht NICHT "Update verfuegbar" da. Eine Nichtauskunft ist keine Aussage. GEMESSEN: ruff sauber, 489 Tests gruen + 15 uebersprungen (vorher 456). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 11:12:21 +02:00
HitonabiandClaude Opus 5	059183c651	feat(windows): V2-4 fertig — RippySetup.exe, Taskmanager-Eintrag, Deinstallation ... WAS: Eine 28,6-MB-Datei, drei Betriebsarten. Doppelklick installiert, `--dienst` laeuft im Hintergrund, `--deinstallieren` raeumt sich weg. Dazu packaging/windows/build.py, das sie baut. DIE ZWEI COMMANDER-WUENSCHE, GEMESSEN: 1. EINTRAG IM TASKMANAGER ProcessName Rippy Beschreibung Rippy — automatisches Ripping Produkt Rippy Version 2.0.0 Der Prozessname kommt vom Dateinamen (bei der Installation kopiert sich die Datei als Rippy.exe), die Beschreibung aus einer eingebetteten Versions-Ressource. Ohne die steht dort nichts, und Windows SmartScreen sieht eine EXE ohne Herausgeberangabe genauso misstrauisch wie ein Mensch. 2. EINTRAG IN PROGRAMME UND FEATURES Aus der Registry zurueckgelesen, nicht behauptet: DisplayName Rippy DisplayVersion 2.0.0 Publisher Rippy InstallLocation <Zielordner> UninstallString "<pfad>\Rippy.exe" --deinstallieren EstimatedSize 29241 (KiB) NoModify/NoRepair 1 HKCU statt HKLM: Der Eintrag erscheint genauso in "Apps & Features", die Installation laeuft aber ohne UAC-Abfrage durch. VOLLER KREISLAUF GEMESSEN: installieren -> Rippy.exe + rippy.ico liegen da, Registry-Eintrag da, Autostart da; Dienst starten -> nach 1 s bereit, alle sieben Endpunkte HTTP 200, Oberflaeche kommt; deinstallieren -> nach ~4 s sind Datei, Ordner, Registry-Eintrag, Autostart UND das Aufraeum-Skript weg. VIER FEHLER, DIE NUR DIE FERTIGE EXE ZEIGT: 1. rippy/store baute die Engine BEIM IMPORT, mit PostgreSQL als Vorgabe. Im Windows-Paket gibt es psycopg2 bewusst nicht -> die EXE starb sofort. Die Engine entsteht jetzt beim ersten Zugriff. Und der Fehler war grundsaetzlicher als der fehlende Treiber: Ein Modul, das beim Import schon eine Verbindung aufbaut, laesst sich gar nicht mehr umstellen — store.verbinden() kaeme immer zu spaet. 2. celery_client baute den Broker-Client beim Import. Dasselbe Muster, und `from celery_client import celery_client` loeste es sogar dann aus, wenn nie ein Rip angestossen wird. Jetzt traege, mit KeinBroker als klarer Ansage statt eines Importfehlers. 3. Die Selbstloeschung beim Deinstallieren ging als EIN Argument an cmd. Python maskiert dabei die inneren Anfuehrungszeichen — cmd suchte einen Dateinamen mit Backslashes davor, fand nichts und meldete nichts (>nul). Registry und Autostart waren weg, die 28-MB-Datei blieb liegen: ein still scheiternder Hintergrundprozess, wie ihn AGENTS.md beschreibt. Jetzt ein Aufraeum-Skript, das 15-mal versucht (die Onefile-EXE laeuft als ZWEI Prozesse; der Starter haelt die Datei nach dem Ende noch offen). 4. deinstallieren() raeumte den STANDARD-Ordner auf statt des tatsaechlichen. Wer nach --ziel D:\Rippy installiert hatte, dessen Dateien waeren geblieben, waehrend ein fremder Ordner angefasst worden waere. Der Pfad steht in der Registry (InstallLocation) und wird jetzt dort gelesen. WAS NOCH NICHT GEHT, ausdruecklich: Ein RIP laesst sich unter Windows noch nicht anstossen — die Zustellung laeuft weiter ueber Celery. Die Umstellung auf die LocalQueue ist V2-5. Oberflaeche, Laufwerks-Erkennung, Auswurf und alles Lesende laufen. GEMESSEN: ruff sauber, 456 Tests gruen + 15 uebersprungen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 11:00:39 +02:00
HitonabiandClaude Opus 5	e5254c23f0	feat(daemon): V2-4 (Teil 3) — rippyd laeuft unter Windows, ohne Docker ... WAS: `rippyd` startet Rippy als EINEN Prozess — SQLite statt Postgres, LocalQueue statt Celery/Redis, In-Process-Bus statt Redis Pub/Sub, UI von FastAPI statt von nginx. Dieselbe API, dasselbe UI, derselbe Rip-Code. GEMESSEN (Windows 11, frische Python-3.12-Umgebung, ohne Docker/Postgres/Redis): bereit nach 1 s /api/health 200 /api/settings 200 /api/devices 200 /api/logs 200 /api/jobs 200 /api/capabilities 200 /api/health/vorraete 200 / (Weboberflaeche) 200 Ereignis-Waechter gesund: true, alter_sekunden: 0.5 SSE-Strom liefert `event: snapshot` mit vollem Zustand SQLite angelegt, WAL aktiv, alle Tabellen da ZWEI FEHLER, DIE NUR DER ECHTE LAUF ZEIGT: 1. STARLETTE REICHT LIFESPAN NICHT AN MOUNT-UNTERANWENDUNGEN WEITER. Das UI ruft /api/..., im Docker-Betrieb entfernt der nginx das Praefix. Ohne nginx haengt die API als Unteranwendung unter /api — und ihr startup_event lief nie. Folge: db.init_db() nicht ausgefuehrt, "no such table: settings", HTTP 500 auf /jobs, /settings, /logs, /capabilities, und der SSE-Strom blieb stumm. /api/health antwortete trotzdem mit 200, weil die Route keine Datenbank braucht — der Fehlschlag sah also aus wie "laeuft". Behoben ueber einen eigenen lifespan, der den der Unteranwendung mit ausloest. 2. EIN print() HAT DEN GANZEN START UMGEBRACHT. UnicodeEncodeError: 'charmap' codec can't encode characters -> ERROR: Application startup failed. Exiting. Windows-Konsolen arbeiten mit cp1252; Rippys Meldungen sind deutsch und voller Umlaute und Warnzeichen. Das Bittere: Es war nicht die WARNUNG, die den Start verhindert hat, sondern der VERSUCH, sie auszugeben. Behoben mit encoding="utf-8" UND errors="replace" — eine Ausgabe darf unter keinen Umstaenden etwas abbrechen koennen. BEFUND ZUR HARDWARE (kein Codefehler): Nach dem Auswurf-Test hat sich das USB-Laufwerk vom Bus getrennt. Windows kennt es nur noch als Karteileiche (Get-PnpDevice -Class CDROM -> Status "Unknown", Win32_CDROMDrive leer), weder ein Laufwerksbuchstabe noch \.\CdRom0..4 sind da. Die leere Geraeteliste ist damit die RICHTIGE Antwort. Bei bus-versorgten USB-Laufwerken ist das bekannt — der Auswurf zieht kurz mehr Strom. GEMESSEN: ruff sauber, 440 Tests gruen + 15 uebersprungen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 10:34:51 +02:00
HitonabiandClaude Opus 5	9d95c95d79	feat(drives): Windows-Treiber an echter Disc BEWIESEN ... WAS: Die Hardware-Schicht des Windows-Treibers ist nicht mehr nur gebaut, sondern gemessen. Messwerte stehen im Modul-Docstring, der gemessene BD-50-Wert als Testfall in test_cdrom.py. GEMESSEN (28.08.2026, LG BU40N extern, Laufwerk G:, echte BD-50): drive_status() -> 4 (CDS_DISC_OK), sofort IOCTL_CDROM_DISK_TYPE -> DATA_TRACK IOCTL_DISK_GET_LENGTH_INFO -> 48 149 364 736 Bytes = 44,84 GiB disc_status() -> 101 (CDS_DATA_1) detect_disc_type() -> 'bluray' device_info()['status'] -> 'ready' device_info()['type'] -> 'bluray' auswerfen_versuchen() -> True, 2,41 s drive_status() davor / danach -> 4 / 1 DIE LETZTE ZEILE IST DER EIGENTLICHE BEWEIS. Der Auswurf haengt nicht am Rueckgabewert des Steuercodes, sondern am ZUSTAND davor und danach: Die Disc war drin (4) und ist danach draussen (1). Genau das fehlte in v1 monatelang — dort quittierte das ioctl Erfolg, die Schublade blieb zu, und im Log stand "Disc ausgeworfen". Die 44,84 GiB pruefen die Schwelle gleich mit: Eine BD-50 liegt knapp unter den 55 GiB, ab denen classify() auf 'uhd' geht, und wird korrekt als 'bluray' eingeordnet. Wer die Schwelle senkt, macht aus jeder BD-50 eine UHD — und Rippy waehlte dann das falsche Kompressions-Preset. Der Testfall haelt den gemessenen Wert fest. Offen bleibt allein die Ereignis-Erkennung (WM_DEVICECHANGE) — die wird erst gebaut. Nebenbei: Beim Eintragen der Messwerte sind drei echte NUL-Bytes in die Datei geraten (eine Escape-Ebene im Schreib-Skript verschluckt). Python lehnt so eine Datei rundheraus ab ("source code string cannot contain null bytes") — im Binaermodus repariert und gegengeprueft. GEMESSEN: ruff sauber, 430 Tests gruen + 14 uebersprungen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 10:04:29 +02:00
HitonabiandClaude Opus 5	3d7f3b1680	feat(drives): V2-4 (Teil 2) — main.py laedt unter Windows, Treiber gemessen ... WAS: rippy/drives/__init__.py waehlt den Treiber fuer DIESE Maschine. main.py und prescan.py fragen ihn, statt fest den Linux-Treiber zu importieren. Damit ist der Blocker fuer den nativen Windows-Betrieb weg. GEMESSEN, vorher (frische Python-3.12-Umgebung unter Windows): >>> import main ModuleNotFoundError: No module named 'fcntl' GEMESSEN, nachher: main.py laedt unter Windows: JA Treiber: rippy.drives.windows Routen: 61 Laufwerke: ['\\.\G:'] Der Import stand in rippy/drives/linux.py -> detection.py -> fcntl. Genau dafuer gibt es den Port: Der Aufrufer sagt WAS, nicht WIE. test_treiberwahl.py haelt ausserdem fest, dass BEIDE Treiber denselben Satz Funktionen anbieten — sonst faellt eine fehlende erst im Betrieb als AttributeError auf, und zwar auf der anderen Plattform. DER TREIBER AN ECHTER HARDWARE (LG BU40N extern, Laufwerk G:, LEER): GetDriveTypeW("G:\\") -> 5 (DRIVE_CDROM) list_optical_devices() -> ['\\.\G:'] CreateFileW(r"\.\G:") -> Handle 380 CHECK_VERIFY2 bei leerem Laufwerk -> ERROR_NOT_READY (21) drive_status() -> 1 (CDS_NO_DISC) detect_disc_type() -> 'no_disc' device_info()['status'] -> 'empty' MEDIA_REMOVAL (entriegeln) -> Erfolg, 0,1 ms EJECT_MEDIA -> Erfolg, 664,8 ms Die 664,8 ms sind der Beleg, dass wirklich etwas passiert ist: Ein abgelehnter Steuercode kommt in rund 2 ms zurueck. BEFUND, DER EIN PLACEBO VERHINDERT HAT: IOCTL_STORAGE_LOAD_MEDIA (Schublade einziehen) antwortet auf diesem Laufwerk mit ERROR_INVALID_FUNCTION. Bei flachen und externen Laufwerken ist das die Regel. Deshalb gibt es bewusst KEINE einziehen()-Funktion — ein Knopf "Schublade schliessen", der auf der Haelfte aller Laufwerke stillschweigend nichts tut, waere genau die Sorte Placebo, die in Etappe 19 aufgeraeumt wurde. Dazu eine DeprecationWarning behoben: '\G' im Docstring ist keine gueltige Escape-Sequenz und waere in einer kuenftigen Python-Version ein harter Fehler. NOCH NICHT gemessen: das Verhalten MIT eingelegter Disc (Typ-Erkennung ueber die Groesse, und ein Auswurf, bei dem wirklich etwas drin ist). GEMESSEN: ruff sauber, 429 Tests gruen + 13 uebersprungen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 09:55:15 +02:00
HitonabiandClaude Opus 5	b723fee3a2	feat(drives): V2-4 (Teil 1) — Windows-Laufwerkstreiber, ohne Hardware geprueft ... WAS: rippy/drives/windows.py mit denselben zwei Vertraegen wie die Linux-Fassung (auswerfen_versuchen gibt False zurueck, eject wirft). Dazu win_ioctl.py: die Win32-Steuercodes, HERGELEITET statt abgeschrieben. WARUM ctypes und nicht pywin32: 20 MB zusaetzliche Abhaengigkeit, die in jedes PyInstaller-Paket muss und bei jedem Python-Wechsel neu passen will. Gebraucht werden fuenf Funktionen aus kernel32 — die spricht ctypes direkt an. DIE STEUERCODES WERDEN AUSGERECHNET, NICHT ABGETIPPT: win_ioctl.py enthaelt das CTL_CODE-Makro aus winioctl.h als Funktion; jede Konstante wird daraus gebildet. test_win_ioctl.py rechnet das Ergebnis gegen die in der Microsoft-Dokumentation stehenden Zahlen. Grund: Ein falscher IOCTL-Code meldet kein "unbekannter Befehl", sondern ERROR_INVALID_FUNCTION — und das liest sich wie "dieses Laufwerk kann das nicht". Man sucht dann am Geraet statt an einer Zahl. AGENTS Regel D, ernst genommen. DIE ZWEI PORT-REGELN GELTEN AUCH HIER: - Auswerfen heisst entriegeln, auswerfen, NACHSEHEN. Unter Linux wurde am 26.07.2026 gemessen, dass ein verriegeltes Laufwerk den Auswurf mit ERFOLG quittiert und nichts tut. IOCTL_STORAGE_EJECT_MEDIA meldet ebenfalls nur die Annahme des Befehls — also wird auch hier nachgesehen (CHECK_VERIFY2 muss ERROR_NOT_READY liefern). - Ein unzugaengliches Laufwerk ist UNBEKANNT, nicht leer. device_info kennt deshalb drei Zustaende, nicht zwei. EIN FEHLER, DEN DIE TESTS SOFORT GEFANGEN HABEN: Win32Fehler setzte self.winerror VOR super().__init__(). Nachgemessen: Ein zweiargumentiges OSError.__init__(code, text) setzt winerror wieder auf None. Damit erkannte _medium_da ERROR_NOT_READY nicht mehr, hielt jedes leere Laufwerk fuer einen echten Fehler und meldete "unbekannt" statt "leer". Vier Tests rot, Ursache in einer Minute gemessen statt geraten. ⚠️ WAS HIER NICHT BEWIESEN IST: dass echte Hardware sich so verhaelt. Das Laufwerk ist derzeit nirgends angeschlossen. Der Ablauf, die Fehlerunterscheidung und die Typ-Zuordnung sind gegen ein nachgebautes Laufwerk geprueft (51 Tests, laufen auf jeder Plattform) — die Hardware- Schicht gilt bis zu einer Messung als GEBAUT, nicht als BEWIESEN. GEMESSEN: ruff sauber, 400 Tests gruen + 4 uebersprungen (vorher 378). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 09:45:43 +02:00
HitonabiandClaude Opus 5	4337253797	docs: SAVEPOINT v4.0-beta — V2-0 bis V2-3 stehen, Laufwerk fehlt an der VM ... Vier Etappen gebaut und deployt, Polling ist weg (121 Anfragen/min je Tab -> ~2 einmalige Abrufe), SSE-Strom live belegt. Wichtig fuer die naechste Sitzung: Das optische Laufwerk haengt NICHT mehr an der VM. Rippy laeuft als reine Komprimier-Maschine. Und der Vorfall, der das aufgedeckt hat, ist dokumentiert — ein devices:-Eintrag in compose ist eine Startbedingung, und die hat api, worker und ui stillgelegt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 09:37:23 +02:00
HitonabiandClaude Opus 5	05ab655116	fix: ein fehlendes Laufwerk darf Rippy nicht am Starten hindern ... WAS: Die `devices:`-Eintraege fliegen aus docker-compose.yml. Was dieser Host wirklich hat, ermittelt deploy/geraete-override.sh und schreibt es in docker-compose.override.yml — die zieht Compose von allein dazu, der Befehl bleibt `docker compose up -d`. WARUM (Vorfall heute, 28.08.2026): Das USB-Laufwerk haengt nicht mehr an der VM. Ein ganz normaler Deploy legte daraufhin api, worker UND ui still: Error response from daemon: error gathering device information while adding custom device "/dev/sr0": no such file or directory Ein `devices:`-Eintrag ist eine STARTBEDINGUNG — und keiner der drei Container braucht zum STARTEN ein Laufwerk. Rippy war unten, und die Meldung stand mitten im Build-Rauschen (dieselbe Klasse wie das geschluckte `|| echo` beim .env-Kopieren am 26.07.). DER WIDERSPRUCH WAR AELTER ALS DER VORFALL: install.sh sagt bei fehlendem Laufwerk ausdruecklich "die Installation laeuft trotzdem durch; diese Maschine dient dann als reine KOMPRIMIER-Maschine" — die Compose-Datei sah das anders. Eine Maschine ohne Laufwerk ist ein VORGESEHENER Betriebsfall: der Windows-Worker und der GPU-Encoder sind genau das. Das Skript uebernimmt die Erkennung aus install.sh unveraendert: sr- und sg-Knoten ueber die SCSI-Adresse in /sys abgeglichen, nicht geraten. Und es schreibt die Override AUCH dann, wenn kein Laufwerk da ist — sonst bliebe eine alte Datei mit /dev/sr0 liegen und der Fehler waere derselbe, nur schwerer zu finden, weil sie gitignored ist und in keinem Diff auftaucht. deploy.sh ruft es vor dem Start auf. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 09:35:48 +02:00
HitonabiandClaude Opus 5	95705c8d88	feat(ui): V2-3 (Teil 2) — das UI haengt am Ereignis-Strom, Taktgeber raus ... WAS: EventStreamProvider haelt EINE SSE-Verbindung fuer die ganze Anwendung. Dashboard, Log-Kasten, Log-Seite, Laufwerksliste und Worker-Liste beziehen ihren Zustand daraus. Sieben von neun setInterval sind weg. GEMESSEN AN DEN TAKTGEBERN, je offenem Tab: Dashboard 5 Endpunkte / 4 s 75/min -> 0 Log-Kasten 2 Endpunkte / 5 s 24/min -> 0 Laufwerke 1 Endpunkt / 5 s 12/min -> 0 Log-Seite 1 Endpunkt /10 s 6/min -> 0 (+1 Abruf beim Oeffnen) Worker-Liste 1 Endpunkt /15 s 4/min -> 0 (+1 Abruf beim Oeffnen) ------ 121/min -> ~2 einmalige Abrufe Zwei Taktgeber bleiben bewusst: FirstRunWizard (laeuft nur VOR der Einrichtung) und RipTargetModal (nur solange der Dialog offen ist). DIE REGEL IST UMGEZOGEN, NICHT VERSCHWUNDEN: Ein Abriss ist keine Aussage ueber die Welt. Der Provider BEHAELT bei einem Fehler den letzten Stand und setzt nur `verbunden` auf false; es wird nie eine Liste geleert. Jede Komponente uebernimmt einen Wert nur, wenn er wirklich da ist — `devices === null` heisst "konnte nicht nachsehen", nicht "keine Laufwerke". Das war der Fehler hinter "wird oft neu geladen". EIN PLACEBO WENIGER: Oben rechts stand ein fest verdrahtetes "ONLINE" mit pulsierendem Punkt — es leuchtete gruen, auch wenn die API tot war. Jetzt zeigt es LIVE oder VERBINDUNG WEG, und im Tooltip steht, wann die letzte Meldung kam. DER SERVER SCHIEBT JETZT AUCH DEN SERVER-ZUSTAND: Neuer Ereignistyp system.status (Hardware, Worker, Ablageziele) im 15-Sekunden-Takt des Waechters — EINMAL im Server statt 15/min je Tab. Nur mitgeschickte Schluessel werden uebernommen; ein fehlender heisst "behalte deinen Stand". DAZU EIN FORMATFEHLER GEFUNDEN UND BEHOBEN: /logs bildet ts -> timestamp ab, mein Snapshot lieferte die rohe DB-Zeile. Das UI haette "Invalid Date" gezeigt — und zwar NUR im Live-Betrieb, nicht beim manuellen Neuladen. Jetzt gibt es _log_zeile() einmal, benutzt von beiden. UND EINEN ZWEITEN: system_lesen lief per asyncio.get_event_loop() in einem Worker-Thread — dort ist das NICHT die laufende Schleife. Die Coroutine waere nie gelaufen. Die Schleife wird jetzt im Startup festgehalten. GEMESSEN: ruff sauber, 378 Tests + 3 uebersprungen, `npm run build` durch (1650 Module). Der Live-Beweis steht noch aus — er kommt mit dem Deploy. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 09:32:50 +02:00
HitonabiandClaude Opus 5	f097a0b59d	feat(bus): Waechter — Worker-Aenderungen werden zu Ereignissen ... WAS: rippy/bus/waechter.py sieht im Takt von 1 s in der Datenbank nach und meldet Aenderungen an den Bus: job.created / job.phase / job.progress / job.finished und log.line. 12 Tests, ohne Datenbank lauffaehig. WARUM ES IHN BRAUCHT: Der Bus verteilt innerhalb EINES Prozesses. Der Worker ist aber ein eigener Prozess, im Docker-Betrieb ein eigener Container, im verteilten Betrieb ein anderer Rechner. Ohne Bruecke wuesste die API nichts vom Fortschritt eines Rips. WARUM UEBER DIE DATENBANK und nicht per HTTP-Rueckruf oder Redis: - HTTP-Rueckruf: jeder Fortschrittswert haengt an einer Verbindung, ein kurzer API-Neustart liesse Ereignisse verschwinden, und der Worker braeuchte zusaetzliche Konfiguration. - Redis Pub/Sub: sauber, kommt im verteilten Betrieb (V2-5) — aber der Standalone-Betrieb hat bewusst KEIN Redis, das war der Punkt von V2-2. - Die Datenbank ist ohnehin die Wahrheit ueber den Job-Zustand, ist in JEDEM Modus da, und der Worker schreibt dort sowieso hin. "Ist das nicht wieder Polling?" Doch — aber einmal, lokal und billig: vorher N Tabs x 9 Endpunkte alle 4-5 s ueber HTTP durch nginx durch das Rate-Limit; jetzt EINE Abfrage pro Sekunde von vier Spalten. Das Ziel war nie "nirgendwo nachfragen", sondern: der Browser fragt nicht mehr. DER TEST HAT EINEN ECHTEN FEHLER GEFUNDEN: Der Docstring versprach "erst neue Jobs, dann Aenderungen", die Schleife lieferte aber die Reihenfolge des dicts — ein Client haette ein job.progress fuer einen Job bekommen koennen, den er noch gar nicht kennt. Jetzt drei getrennte Durchlaeufe. Das Versprechen war richtig, der Code nicht. Und er stirbt nicht still: Fehler gehen ins Log UND als system.notice an den Bus (erster Fehlschlag, danach jeder zehnte), und lebt_seit_sekunden() macht sein Alter abfragbar — AGENTS.md, "wer einen Vorrat anlegt, macht sein Alter abfragbar". GEMESSEN: ruff sauber, 371 Tests gruen + 3 uebersprungen (vorher 359). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 09:23:03 +02:00