4 Commits

Include renames

Author	SHA1	Message	Date
HitonabiandClaude Opus 5	1b84ec2a45	fix(windows): Vollstaendiger Rundgang durch die Docker-Reste ... Commander: „Bro, du musst alles was rippy jetzt im code hat für Windows Bauen! Jeden pfad, alles wo die tools drauf zugreifen. Diese Rippy version MUSS 100% Windows Kompatibel sein. Prüfe bitte den kompletten Quellcode nach Docker Resten." Systematisch gesucht statt Fundstelle fuer Fundstelle: feste POSIX-Pfade, Linux-Programme, POSIX-eigene Aufrufe, `shutil.which`, `posixpath` auf echten Pfaden, Container-Texte. Sechs echte Fehler dabei. ## 1. `/dev/{name}` in drei Endpunkten — der schwerste Das UI ruft `/devices/{id}/eject`, `/scan-tracks` und `/tracks` mit der Kennung aus der Geraeteliste auf, unter Windows also `G`. Gebaut wurde daraus `/dev/G` — steht in keiner Laufwerksliste. **Auswerfen und „Disc scannen" antworteten unter Windows IMMER mit 404**, ohne dass irgendwo stand, warum. Hin- und Rueckweg gehoeren zusammen: Beide Treiber haben jetzt `kennung()` und `pfad_zu_kennung()`. Wer die Kennung vergibt, loest sie auch auf. ## 2. `os.path.isdir("/app")` — zum zweiten Mal Nach `caps.py` (heute frueh) auch in `ablauf.py`: Der eigenstaendige Windows-Rippy hielt sich fuer einen FREMDEN Worker und haette sich selbst vorgeworfen, Container-Pfade nicht zu erreichen — auf einer Maschine ohne Container. Die Entscheidung ist jetzt einspritzbar; vorher hing der Test daran, ob es einen Ordner `/app` gibt. ## 3. `shutil.which` in `schluessel.py` Ausgerechnet im Modul, das es NUR unter Windows gibt: Es suchte makemkvcon im PATH, wo unter Windows nie ein Programm aus „Programme" steht. Die Schluessel-Automatik fuer 4K-UHD lief damit nie an. ## 4. `posixpath.join` auf echten Pfaden `rohdaten.py` baute `C:\Roh/datei.mkv` — gemischte Trenner, die im UI falsch aussehen und jeden Vergleich brechen. ## 5. Container-Pfad in einer Nutzermeldung „Roh-Datei bleibt in /app/temp erhalten" nennt jetzt den echten Ordner. Wer die Datei retten will, sucht sonst am falschen Ort. ## 6. Container-Pfade als UI-Vorbelegung Rip-Dialog und `useBetrieb` starteten mit `/app/media`, bis die Antwort da war. Leer ist ehrlicher: Es behauptet nichts. ## Und HandBrakes „Code 0" Code 0 heisst ERFOLG. Rippy meldete trotzdem „fehlgeschlagen", weil die Datei nicht am erwarteten Ort lag: **HandBrake bestimmt den Container aus dem PRESET, nicht aus der Endung** — ein MP4-Preset schreibt `.mp4` neben das verlangte `.mkv`. Jetzt erzwingt `--format` den Container passend zur Endung (an HandBrake 1.11.2 gegengeprueft), und falls doch etwas daneben liegt, wird es gefunden statt weggeworfen. ## Der Waechter `test_keine_container_reste.py` prueft mechanisch, dass im Windows-Weg kein Container-Pfad ohne Begruendung steht. Die Ausnahmen stehen namentlich mit Grund da (Linux-Zweige, benannte Rueckfaelle) — und ein zweiter Test wirft jede Ausnahme raus, die niemand mehr braucht. Ueber den Tokenizer, nicht ueber „faengt mit Anfuehrungszeichen an": Der erste Anlauf blieb prompt an seinem eigenen `r\"\"\"`-Docstring haengen. 887 Tests gruen, ruff sauber. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-29 16:14:10 +02:00
HitonabiandClaude Opus 5	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
Hitonabi	c3e77399ad	fix(worker): mock ntpath.dirname in test_erreichbarkeit so it passes on Linux CI runner	2026-07-27 17:13:45 +02:00
HitonabiandClaude Opus 5	96c400f2f2	fix(worker): erster Film in einer neuen Ablage war immer unerreichbar ... Im ersten vollstaendigen Durchlauf aufgefallen: Der Rip lief sauber durch (40 GB Akira, Marke rip_fertig sprang korrekt auf true), die Kompression brach 0,2 s spaeter ab mit "Dieser Worker erreicht die Ziel (fertige Datei) nicht: \\192.168.178.62\rippy\movies\Akira (1988)". Die Freigabe war erreichbar. Es fehlten zwei noch nie angelegte Ordner - movies und der Filmordner darin. Die Pruefung liess aber nur EINE fehlende Ebene durch (sie sah nach dirname), obwohl gleich darauf os.makedirs die ganze Kette anlegt. Damit war jeder ERSTE Film in einer neuen Ablage systematisch unerreichbar. Jetzt zaehlt, ob irgendein Vorfahre existiert (erster_vorhandener_ordner, begrenzt auf 12 Stufen, damit auf einer toten Freigabe nicht endlos geklopft wird). Zweiter Fehler in derselben Meldung: Sie behauptete "RIPPY_PATH_MAP ist gesetzt, deckt diesen Pfad aber nicht ab" - und nannte im selben Satz den korrekt uebersetzten UNC-Pfad. Wer dem folgte, suchte in der Karte statt in der Freigabe. Die Karte wird nur noch beschuldigt, wenn sie den Pfad wirklich nicht angefasst hat; sonst steht da, was zutrifft: uebersetzt, aber gerade nicht erreichbar. Dazu der Artikel-Fehler "erreicht die Ziel" behoben. Diese Pruefung hatte KEINEN einzigen Test - deshalb kam beides durch. Jetzt 12 (301 gruen). Beim Schreiben ist noch ein dritter Fehler aufgefallen: `isdir=os.path.isdir` als Vorgabewert bindet die Funktion beim IMPORT, ein Ersetzen geht danach ins Leere. Aufloesung jetzt beim Aufruf. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 17:43:51 +02:00