86 Commits

Include renames

Author	SHA1	Message	Date
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	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	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	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	1fbe2cfc55	fix(test): Snapshot-Tests brauchten eine Datenbank — die Ampel hat keine ... WAS: test_snapshot_* ersetzen den Store per monkeypatch, statt db.list_jobs() wirklich aufzurufen. WARUM ROT (Lauf 170): Die Ampel startet KEINE Postgres. Mein neuer Test war der erste im ganzen Repo, der eine Datenbank angefasst hat — alle anderen in test_api_smoke.py pruefen nur Importe und Routen. Auf der VM und lokal waere es nie aufgefallen: dort ist eine DB da bzw. der ganze Test wird uebersprungen (kein fcntl unter Windows). Geprueft wird die Snapshot-LOGIK ("konnte nicht nachsehen" ergibt None, nicht []), nicht die Datenbank. Also gehoert die Datenbank da nicht rein. Dazu ein zweiter Test: der Snapshot muss alle vier Bereiche liefern (jobs/workers/logs/devices) — ein Client, dem einer fehlt, muesste den Rest raten und fiele auf Polling zurueck. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 09:20:58 +02:00
HitonabiandClaude Opus 5	55db9eb13f	feat(api): V2-3 (Teil 1) — Ereignis-Bus und SSE-Endpunkt /api/v2/events ... WAS: rippy/bus mit Ereignis-Schema, In-Process-Treiber und Ringpuffer. Dazu der SSE-Strom in der API: erst ein Snapshot, danach nur Deltas, mit lueckenloser Wiederaufnahme ueber Last-Event-ID. WARUM: Ein offener Tab plus ein Worker verursachen heute rund 133 Anfragen pro Minute (Dashboard 75 + Log-Kasten 24 + Laufwerke 12 + Worker-Liste 4 + Log-Seite 6 + Tray 12). Das Rate-Limit stand einmal UNTER dieser Zahl — daher die sich leerende Job-Liste im Sekundentakt. Mit einer offenen Verbindung sind es null. DREI EIGENSCHAFTEN, ALLE AUS v1-FEHLERN: 1. Der Bus traegt NUR Nachrichten ueber Aenderungen, nie den Zustand. Wer den Zustand will, fragt den Store. Damit kann ein verpasstes Ereignis auch keinen Zustand loeschen — anders als beim fuenffachen `catch(() => [])` im alten UI, wo jeder fehlgeschlagene Abruf "es gibt keine Jobs" bedeutete. 2. Eine zu grosse Luecke wird ANGESAGT, nicht verschluckt. nachliefern() gibt None ("hol dir ein ganzes Bild") statt [] ("nichts verpasst") — dieselbe Unterscheidung wie timeout-Rueckgabe 124 bei den Netzpfaden. Stillschweigend weiterzumachen waere schlimmer: Das UI hielte sich fuer aktuell und waere es nicht. 3. Der Snapshot meldet unlesbare Laufwerke als None, nicht als leere Liste. "Konnte nicht nachsehen" ist etwas anderes als "gibt es nicht". Ein unbekannter Ereignistyp fliegt beim Senden HOCH statt durchzugehen. Ein Tippfehler waere sonst der stillste aller Fehlschlaege: Nachricht raus, kein Empfaenger, nirgends ein Hinweis. Ein langsamer Zuhoerer (Tab im Hintergrund, lahmes Handy) bremst den Sender nicht — er wird markiert und bekommt beim naechsten Mal einen Snapshot. Ein Rip darf nicht auf einen Browser warten. GEMESSEN: ruff sauber, 359 Tests gruen + 3 uebersprungen (vorher 346). 13 neue Bus-Tests laufen auf jeder Plattform; die vier SSE-Tests haengen an main.py und laufen damit in der Ampel. NOCH OFFEN in V2-3: das UI auf den Strom umstellen (neun setInterval) und die Ereignisse an den Zustandsaenderungen ausloesen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 09:09:33 +02:00
HitonabiandClaude Opus 5	dd1d0b7365	refactor(core): V2-1 — die vier Ports, ein Store, ein Laufwerks-Treiber ... WAS: rippy/ports.py beschreibt Store/Queue/Bus/Drives als Protocol. Zwei weitere Doppelungen sind zusammengelegt: db.py (API+Worker) wird rippy/store, und der Auswurf (api/devices.py + ripping.wirf_disc_aus) wird rippy/drives/linux. Verhalten unveraendert. WARUM: Drei Betriebsarten tragen nur, wenn ein Modus die Auswahl der Treiber hinter vier Nahtstellen ist statt ein eigener Codestand (KONZEPT-V2.md §1). Diese Etappe zieht die Nahtstellen ein, ohne schon einen zweiten Treiber zu haben — die kommen in V2-2 (SQLite/LocalQueue) und V2-4 (Windows). DIE UNANGENEHMERE DOPPELUNG WAR DER AUSWURF: Er stand zweimal da, mit UNTERSCHIEDLICHEN Vertraegen — devices.eject wirft OSError, ripping. wirf_disc_aus gibt False zurueck und wirft nie. Beides ist richtig fuer seine Seite (Browser-Meldung gegen "ein Rip stirbt nicht an einer klemmenden Schublade"). Jetzt liegt EINE Mechanik darunter (auswerfen_mit_grund) und beide Vertraege unveraendert darueber. Die API-Fassung war ausserdem NIE getestet — jetzt schon, inklusive "reicht ENOENT/EPERM unveraendert weiter". get_settings hatte den einzigen echten Verhaltensunterschied der beiden db.py: die Worker-Fassung schluckte jeden Fehler und gab {} zurueck. Nicht still entschieden, sondern sichtbar gemacht — der Parameter bei_fehler_leer steht jetzt in der Signatur, mit der offenen Frage im Docstring. {} heisst fuer den Aufrufer "nichts gesetzt", nicht "konnte nicht nachsehen"; das ist dieselbe Klasse wie catch(() => []) im alten UI. Zu entscheiden in V2-2. ZWEITER BEINAHE-FEHLER DIESER ETAPPE: linux.py importierte detection auf Modulebene — und das zieht fcntl. Damit waere ripping.py und ueber es der NATIVE WINDOWS-WORKER nicht mehr ladbar gewesen. Diesmal haben die Tests es sofort gefangen (4 Sammelfehler). Behoben an der Wurzel: Konstanten und die reine classify() leben jetzt in drives/cdrom.py, ganz ohne fcntl. Nebengewinn — die classify-Tests liefen bisher NUR in der Ampel ("erst nach dem Push bewiesen") und laufen jetzt ueberall. Ausserdem: .dockerignore-Testmuster brauchen **, sonst greifen sie nur in der obersten Ebene. Im laufenden Container nachgezaehlt: 30 test_*.py lagen in den Images. GEMESSEN: ruff sauber, 301 Tests gruen + 1 uebersprungen (vorher 290; +4 neue eject-Tests, +7 classify-Tests die jetzt lokal laufen). Kein Modul liegt mehr doppelt im Repo. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 08:54:28 +02:00
HitonabiandClaude Opus 5	b98dc5eef5	refactor(core): V2-0 — gemeinsames Paket rippy statt drei Zwillingsdateien ... WAS: Neues Paket src/rippy (core/drives/rip). detection.py, makemkv_daten.py und notify.py lagen je ZWEIMAL im Repo — unter docker/api UND docker/worker, byte-identisch. Jetzt gibt es sie einmal; beide Container importieren dieselbe Datei. Verhalten unveraendert. WARUM: Es gab kein geteiltes Paket zwischen den Containern, deshalb die Kopien. docker/api/db.py sagt es im Kopfkommentar selbst: "Wer die Struktur aendert, aendert BEIDE Dateien." Ein Waechter-Test (test_zwillinge_sind_byteweise_identisch) hat das mechanisch abgesichert — er war noetig, weil die Konstruktion falsch war. Erste Etappe des v2-Plans (KONZEPT-V2.md §8.3). IM EINZELNEN: - src/rippy/{core/notify, drives/detection, rip/makemkv_daten}.py - conftest.py in der Wurzel legt src/ auf den sys.path (die Ampel ruft pytest dort auf). - Beide Dockerfiles kopieren src/rippy nach /app/rippy — /app ist Arbeitsverzeichnis und uvicorn-App-Dir, also ohne PYTHONPATH findbar. - worker_setup_paket packt das Paket ausdruecklich mit ins Zip: die Schleife sah nur die oberste Ebene, ein Unterordner waere nie mitgekommen und der Windows-Worker beim Start gestorben. - Die zwei Test-Dateien fuer makemkv_daten sind zu einer verschmolzen (die Faelle aus beiden). Damit entfaellt auch der importlib-Umweg im Worker-Test: der war noetig, weil bei "pytest -q" aus der Wurzel docker/api zuerst eingesammelt wird und jeder weitere Import nur noch den sys.modules-Cache trifft — die Worker-Kopie wurde also nie angefasst. Netto -13 doppelte Tests, +2 neue (siehe unten). EIN FEHLER, DEN DER UMBAU FAST AUSGELIEFERT HAETTE: In tasks.py steht der detection-Import in einem "try/except ImportError" — absichtlich, denn der native Windows-Worker hat kein fcntl und soll trotzdem starten. Das except verschluckt aber JEDEN ImportError, auch einen falschen Modulpfad. Auf Linux haette der Worker ab sofort still detect_disc_type=None gesetzt und jeden Rip verweigert, ohne dass irgendwo ein Fehler stuende — genau die Klasse "still scheiternder Hintergrund-Prozess" aus AGENTS.md. Gefunden ueber eine zweite Suche mit eingerueckten Treffern. Waechter dagegen: src/rippy/test_paket.py prueft mit importlib.util.find_spec (fuehrt nichts aus, laeuft also auch auf Windows ohne fcntl), dass es die drei Modulpfade wirklich gibt. Beim Wegnehmen von detection.py gegengeprueft: Test wird rot, nach Wiederherstellen gruen. GEMESSEN: ruff sauber, 290 Tests gruen + 1 uebersprungen (lokal, ohne die zwei Linux-only-Module). Kein Modul liegt noch doppelt im Repo. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 08:38:29 +02:00
Hitonabi	a32a1bb075	fix: bare except in main.py	2026-07-27 16:56:36 +02:00
Hitonabi	de500f9890	feat: complete rewrite of worker installer in Flet (standalone exe)	2026-07-26 22:07:24 +02:00
Hitonabi	e165e2a0d3	feat: Komplettierung der aktuellen Rippy-Etappe ... - Versionsanzeige für den Windows-Worker im UI inkl. Prüfung - Absicherung der install.sh gegen fehlendes systemd - Serien-Episoden-Erkennung und Laufzeitabgleich anhand TMDB-Daten (Heuristik) - Umstellung der Windows-Worker-Installation auf SchTasks (Dienst-Ersatz) - Kodi-Bibliotheks-Refresh über JSON-RPC integriert	2026-07-26 21:13:27 +02:00
HitonabiandClaude Opus 5	bfb13f44a5	fix(ui+api): das "Neuladen" war HTTP 429 - und "Neu" komprimierte immer ... Zwei Commander-Befunde, beide mit derselben Wurzel: Rippy hat sich selbst ausgebremst und dann geschwiegen. ## "Wenn der Worker installiert ist, wird dieser Bereich oft neu geladen" Gemessen statt geraten. Die Antworten von /jobs und /capabilities waren ueber zwanzig Sekunden byteweise identisch, alle Endpunkte antworteten unter 30 ms - es wurde also gar nichts neu geladen. Im nginx-Log standen dagegen 97 Antworten mit HTTP 429. Drei Fehler griffen ineinander: 1. Das Limit war zu klein fuer Rippy selbst: 100 Anfragen/min, waehrend ein offener Tab 111/min verursacht (Dashboard 75 + Log-Kasten 24 + Laufwerke 12) und der Windows-Tray weitere 12/min dazulegt. 2. Der nginx gab die Client-Adresse nicht weiter. Fuer die API kam damit ALLES von 172.19.0.6 - Browser, zweiter Tab und Tray teilten sich einen Eimer (812 von 876 Anfragen). Das erklaert die Kopplung an den Worker: tray.py fragt /api/jobs ueber Port 80, also durch denselben Proxy. 3. Ein abgewiesener Abruf leerte das UI. `catch(() => [])` heisst "es gibt keine Jobs" - richtig waere "ich weiss gerade nichts Neues". Fuer einen Takt stand "Keine Jobs", die Zaehler sprangen auf (0), vier Sekunden spaeter war alles zurueck. Behoben: X-Real-IP im nginx, Grenze auf 600/min mit vorgerechneter Herleitung, jeder Fehlschlag laesst den alten Stand stehen (null statt []), axios bekommt eine Zeitgrenze, und das Dashboard trennt schnelle Daten (Jobs/Laufwerke, 4 s) von langsamen (Hardware/Worker/Ablagen, 12 s) - 75/min werden zu 30/min. Ein greifendes Limit steht ab jetzt im Log, gedrosselt auf eine Meldung pro Client und Minute. ## "Hier gibt es den Button 'neu' aber WAS wird dann gemacht?" Immer die Komprimierung - auch bei einem Job, dessen RIP abgebrochen war. Am 26.07.2026 waeren aus 5,1 GB Bruchstueck (von rund 40 GB) brav ein Film geworden, der bei 12 % aufhoert. Die Phase war nach `status = "failed"` nicht mehr feststellbar, also wird sie jetzt vermerkt (rip_fertig in den Job-Metadaten: false beim Rip-Start, true bei der Uebergabe an die Kompression). Daraus folgt die Beschriftung: "Neu komprimieren", "Neu rippen" - oder bei Bestandsjobs ohne Vermerk ein Dialog, der beide Wege erklaert und die Groesse der Rohdaten als Entscheidungshilfe nennt. Geraten wird nicht. Fuer den Rip-Fall gibt es POST /jobs/{id}/retry-rip: neuer Job mit neuer ID (sonst laege das Bruchstueck im Roh-Verzeichnis des neuen Rips), Titel/Ablage/Sprachwahl uebernommen, mit ehrlicher Absage wenn keine Disc im Laufwerk liegt. 10 neue Tests (289 gruen), darunter eine Kopplungspruefung: der Name der Phasen-Marke muss in worker/tasks.py und api/phasen.py zusammenpassen - genau diese Sorte Auseinanderdriften hat die Zombie-Erkennung ein Release lang blind gemacht. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 16:49:10 +02:00
HitonabiandClaude Opus 5	19f3dc5330	fix(zombies): "running" fehlte - ein abgestuerzter RIP wurde NIE gefunden ... Der Commander: "Ausserdem ist gerade mitten im Rip das Laufwerk ausgegangen... glaube ich zumindest." Gemessen war es etwas anderes, und der Fund ist groesser als der Vorfall. WAS MESSBAR WAR: Job 2182d525 status=running progress=12 (Rip gestartet 14:00:24) makemkvcon laeuft NICHT (per /proc geprueft, PID gegengeprueft) Rohdatei 5.167.382.528 Bytes, waechst in 10 s nicht Laufwerk Status 4 (Disc drin), /dev/sr0 + /dev/sg1 da Worker-Start 14:07:02 <- mein `docker compose up -d --build` Das Laufwerk ist also NICHT ausgegangen. Der Rip wurde von MEINEM Deploy getoetet: `up -d --build` baut den worker-Container neu, und der laufende Rip stirbt mit ihm. Genau davor warnt der SAVEPOINT seit v3.18 - die Warnung half nichts, weil sie niemand liest und nichts sie prueft. DER EIGENTLICHE FUND: Die Zombie-Erkennung lief um 14:09:04 und meldete `{'geprueft': 0, 'aufgeraeumt': []}` - obwohl der tote Job direkt vor ihr lag. Ursache: ARBEITS_STATI = ("ripping", "transcoding", "canceling") # zombies.py db.update_job(job_id, status="running", ...) # tasks.py - der Rip Der Rip setzt "running", gesucht wurde "ripping". Dieser Wert steht ausschliesslich in Celerys Task-META und NIE in einer Job-Zeile (nachgeprueft: kein einziger Schreiber im ganzen Baum). Die Zombie-Erkennung aus v3.14 wurde gebaut, um genau einen abgestuerzten Rip zu finden - und hat ihn nie gesehen. Besonders tueckisch: `geprueft: 0` sah bei jedem Worker-Start wie "nachgesehen, alles gesund" aus, waehrend sie nach einem Status suchte, den es nicht gibt. Deshalb blieb der Job auf "processing 12 %" stehen - mit einer Restzeit-Schaetzung von 1 h 30 min obendrauf, die es fuer einen toten Prozess nicht geben duerfte. GEBAUT: * "running" in ARBEITS_STATI. * Ein Test, der das Auseinanderlaufen MECHANISCH verhindert: Er liest tasks.py, sammelt jeden Status, den der Worker per db.update_job in eine Job-Zeile schreibt, und verlangt, dass jeder davon entweder ein Arbeitsstatus oder ein Endzustand ist. Ein Kommentar haette das nicht verhindert. * GET /health/arbeit + eine Sperre in deploy.sh: Laeuft ein Job, bricht der Deploy ab (uebersteuerbar mit RIPPY_TROTZDEM=1 - dann ist es eine Entscheidung und kein Versehen). Ein Satz Code gegen eine verlorene Stunde. * Server-Status zeigt jetzt die eingehaengten FREIGABEN mit freiem Platz, nicht nur die Container-Platte (Commander-Wunsch). Genau dort liegen die Rohdaten, und bei externem Encoden muessen sie dort liegen - wer wissen wollte, ob noch Platz fuer eine Disc ist, sah die falsche Zahl. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 16:16:05 +02:00
HitonabiandClaude Opus 5	f146f33f5d	feat(installer): Verknuepfung auf dem Desktop - mit Rippy-Icon ... Commander: "Und wenn man den worker installiert braucht man auch eine exe auf dem Desktop abgelegt wird zum starten you know?" Berechtigt: Die Startdateien lagen nur im Programmordner. Wer den Worker von Hand starten wollte, musste erst "C:\Program Files\Rippy Worker" suchen - und genau das war heute noetig, als der Worker stand. Jetzt legen beide Installer eine Verknuepfung "Rippy Worker" auf den Desktop (GUI mit Haekchen, Kommandozeile per -KeineDesktopVerknuepfung abschaltbar). Drei Details, die den Unterschied machen: * Das ICON wird mit ausgeliefert. rippy.ico lag im Repo, ging aber nie an die Zielmaschine - die Verknuepfung haette das Batch-Standardsymbol getragen und waere zwischen den anderen Icons unfindbar gewesen. Jetzt im Worker-Paket. * WindowStyle 7 (minimiert): start-tray.bat startet pythonw, also ohne Konsolenfenster - aber die .bat selbst blitzt sonst kurz auf. Gilt jetzt auch fuer die Autostart-Verknuepfung, wo derselbe Blitz war. * Der DEINSTALLER nimmt sie mit, an beiden moeglichen Orten (eigener Desktop und Desktop aller Benutzer). "Rueckstandsfrei entfernbar" ist ein MUSS-Kriterium; ein totes Symbol auf dem Desktop waere genau so ein Rueckstand. Dieselbe Rechte-Ueberlegung wie beim Autostart: bei einer Installation unter "Programme" auf den Desktop ALLER Benutzer, sonst auf den eigenen - bei einer UAC-Erhoehung ueber ein fremdes Admin-Konto waere der eigene der falsche. Layout headless gerendert und angesehen (Fenster 648 -> 672 px, nichts ueberlappt), beide .ps1 mit echtem PowerShell 5.1 geprueft, .exe neu gebaut. Und die CRLF-Falle aus dem Savepoint hat prompt wieder zugeschlagen: Mein Python-Rewrite machte aus install-gui.ps1 LF - zurueckgedreht, `file` bestaetigt BOM und CRLF fuer beide. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 15:46:15 +02:00
HitonabiandClaude Opus 5	9230d0dd7a	fix(weitergabe): drei Luecken geschlossen, die einen Fremden gestolpert haetten ... Weitergabe nicht durch Lesen geprueft, sondern indem ich mich wie ein fremder Rechner verhalten habe: frischer `git clone` von Gitea in ein leeres Verzeichnis, dann `./install.sh --nur-pruefen`. Ergebnis: 2,6 MB, alles gruen, Laufwerk samt richtigem sg-Knoten ueber die SCSI-Adresse erkannt. Der Weg selbst traegt. Drei Luecken sind dabei aufgefallen: 1. IN BEISPIELBEFEHLEN STAND MEINE IP. `install.ps1` und `remote-transcode-worker.yml` nannten im Aufruf-Beispiel 192.168.178.162 - also genau die Zeile, die ein Fremder kopiert. Jetzt Platzhalter, beim Windows-Installer mit dem Hinweis, wo die richtige IP steht (und dass es NICHT die des eigenen PCs ist - der haeufigste Irrtum). 2. DER ASSISTENT FRAGTE DEN MAKEMKV-BETA-KEY NICHT. Er stand in der README, in der .env und in den Einstellungen - nur nicht dort, wo man beim Einrichten hinsieht. Ein Fremder installiert also, legt eine Blu-ray ein und bekommt spaeter einen Fehlschlag, ohne dass ihn jemand darauf hingewiesen haette. Das ist die wahrscheinlichste Stolperstelle einer frischen Installation. Jetzt fragt der Assistent ihn ab, mit dem Unterschied im Klartext: DVDs gehen ohne, Blu-ray braucht ihn - und er ist NICHT der Disc-Schluessel einer 4K-Disc. 3. Eine Docstring nannte meine NAS-IP als Beispiel - jetzt neutral (//NAS/rippy). Tests und Log-Beispiele behalten die echten Namen: Sie dokumentieren Messungen, und genau das ist ihr Wert. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 15:18:30 +02:00
HitonabiandClaude Opus 5	148ac494c2	feat(sprachen): Rippy fragt vor dem Rip, welche Sprachen du willst ... Commander-Anforderung: "Die Disc hat Material in X Sprachen und X Untertiteln - Rippy muss VOR dem Rip fragen: Was genau willst du haben? In der Automatik muss das ebenfalls einstellbar sein." Die Auskunft lag laengst vor und wurde weggeworfen: Derselbe Titel-Scan, der die Titel-Tabelle fuellt, liefert in derselben makemkvcon-Ausgabe die Streams mit. Ein zweiter Info-Lauf haette eine Minute Wartezeit gekostet - jetzt kommt beides aus einem Aufruf. Format an der Akira-Blu-ray im Laufwerk gemessen (AGENTS Regel D): SINFO:<titel>,<stream>,<attribut>,<code>,"<wert>" 1 = Typ ("Audio"/"Subtitles"), 3 = Sprachcode, 4 = Sprachname, 6 = Codec, 14 = Kanaele, 30 = Beschreibung DIE FALLE dabei: Die Sprache steht in 3/4, NICHT in 28/29. Die tragen auf JEDEM Stream "eng"/"English" - auch auf einer deutschen Tonspur und auf dem Videostream; das ist MakeMKVs eigene Anzeigesprache. Wer 28 nimmt, haelt jede Disc fuer englisch. Ein Test haelt das fest. Angewendet wird die Wahl bei der KOMPRESSION, nicht beim Rippen - drei Gruende: der Rip bleibt vollstaendig und verlustfrei (Muss-Feature laut KONZEPT); HandBrake hat dafuer dokumentierte Schalter (--audio-lang-list / --subtitle-lang-list, die genau die ISO-639-2-Codes nehmen, die MakeMKV liefert - beides gegengeprueft); und wer spaeter andere Sprachen will, komprimiert neu statt die Disc wieder einzulegen. Genau das sagt der Dialog auch, sonst glaubt man, es werde unvollstaendig gerippt. Nichts angeklickt heisst "alles behalten" - das Verhalten von vorher. Auch die Einstellung ist bewusst LEER vorbelegt: Ein stilles "deu" wuerde bei einem japanischen Original die Originaltonspur wegwerfen, ohne dass jemand gefragt hat. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 15:10:21 +02:00
HitonabiandClaude Opus 5	58f4991d92	fix(mounts): 3 min 15 s hingen in EINER Zeile - os.makedirs auf dem toten Mount ... Nachtrag, weil die letzte Runde die Wiederanbindung nicht schneller machte (202 s statt 150 s). Die Zeitstempel im Log zeigten, wo die Zeit sitzt: 12:53:56 API gestartet 12:54:03 "antwortet nicht - wird neu verbunden" <- Erkennung: 7 s, gut 12:57:18 "eingehaengt" <- Reparatur: 3 min 15 s Die Erkennung war also schon schnell; die REPARATUR fraess die Zeit. Und zwar nicht in den Mount-Versuchen, sondern in der ersten Zeile von mounten(): os.makedirs(ziel, exist_ok=True) `exist_ok` prueft mit os.path.isdir, und ein `stat` auf einen toten CIFS-Mount blockiert im Kernel bis zum SMB-Timeout. Ausgerechnet der Aufruf, der nur "lege den Ordner an, falls er fehlt" bedeutet, hing drei Minuten - BEVOR irgendeine der sorgfaeltig begrenzten Pruefungen dran war. Dritter Fund derselben Sorte an einem Tag: os-Aufruf auf einen Netzpfad ohne Zeitgrenze. Jetzt klaert `pfad_lage()` die Lage mit einem abbrechbaren Kind-Prozess (`timeout 4 ls -d`, drei Antworten: da / weg / unklar), und makedirs laeuft nur bei "weg". Dieselbe Falle in `reparieren()` (os.path.ismount als Vorbedingung - gebraucht wird es nicht, `umount -l` auf einen leeren Pfad kostet nichts) und in `aushaengen()` (ismount + rmdir). Dazu steht die DAUER jetzt im Log ("neu verbunden (4.2s)"). Sie war die entscheidende Spur; wer sie ablesen kann, muss sie nicht rekonstruieren. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 15:01:09 +02:00
HitonabiandClaude Opus 5	2a90538473	fix: Deinstaller, Verwaltungsfenster, Dashboard-Widerspruch, Mount-Tempo ... Vier Meldungen des Commanders, alle nachgemessen. 1. DEINSTALLER LIEF NICHT MEHR - reproduziert mit echtem PowerShell: Der Typ [System.Windows.Forms.MessageBox] wurde nicht gefunden. `Add-Type -AssemblyName System.Windows.Forms` stand EINE ZEILE ZU SPAET, die MessageBox wurde davor benutzt. Der Deinstaller starb also in seiner ersten Arbeitszeile, jedes Mal. Zwei weitere Maengel gleich mit: Kodierung war ASCII trotz Umlauten, und `Remove-Item -Recurse -Force $PSScriptRoot` loescht den Ordner, in dem das laufende Skript liegt - das klappt auf Windows nicht zuverlaessig (venv-DLLs sind geladen). Jetzt raeumt ein losgeloestes cmd nach, sobald PowerShell weg ist. Der erzeugte Deinstaller ist gegengeprueft: parst, BOM da, Umlaute intakt. 2. VERWALTUNGSFENSTER (Doppelklick aufs Tray). Zeigt Status, Aufgaben und Log, plus Knoepfe fuer Rippy, Log-in-Rippy und Deinstallieren - Deinstallieren geht damit auch aus dem Tray-Menue. Eigener PROZESS statt Fenster im Tray, weil pystray und tkinter beide den Haupt-Thread wollen; tkinter statt WinForms, weil es bei jeder Windows-Python-Installation dabei ist. Headless gerendert und angesehen. Alles Fachliche kommt von Rippy (/capabilities, /jobs), damit dort nicht eine zweite, abweichende Wahrheit steht. 3. DASHBOARD-WIDERSPRUCH. Oben stand "Akira im Laufwerk erkannt", die Server-Status-Karte gleichzeitig "Bereit - keine Disc in Arbeit / Disc einlegen". Zwei Aussagen, ein Blick. Die Karte fragt jetzt /devices und sagt "Disc erkannt - wartet auf Rippen starten" samt Titel. 4. MOUNT-TEMPO. Der Commander: "150 Sekunden? Das ist verrueckt langsam." Recht hat er. Gemessen ging die Zeit fast komplett in einen FEHLVERSUCH: `umount -l` ist lazy, der Abbau passiert spaeter, und wer direkt danach mountet, riskiert dass der Abbau hinter dem neuen Mount landet. Der erste Reparaturversuch scheiterte dadurch regelmaessig - und der zweite kostete 30 s mount-Timeout plus Pruefungen. Jetzt werden 1,5 s auf den Abbau gewartet, bevor neu gemountet wird; die Wache prueft erstmals nach 3 s statt 10 s und benutzt zum ERKENNEN die einfache schnelle Probe (die Doppelprobe steckt dort, wo der Wettlauf lauert: direkt nach dem Mount). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 14:52:53 +02:00
HitonabiandClaude Opus 5	4cf7acbb96	fix(mounts): DIE URSACHE gefunden - die CIFS-Verbindung stirbt mit dem Container ... Der Savepoint v3.17 fuehrte das als "Ursache liegt beim NAS, nicht gefunden". Gemessen ist es etwas ganz anderes, und es liegt bei uns: /proc/fs/cifs/DebugData -> Net namespace: 4026532653 api-Container -> net:[4026532653] DIESELBE worker-Container -> net:[4026532540] andere Die CIFS-Verbindung lebt in der NETZ-NAMESPACE DES API-CONTAINERS - dort wird sie eingehaengt, weil nur dieser Container CAP_SYS_ADMIN hat. Wird der Container neu gebaut, stirbt sein Netz-Namespace und mit ihm der Socket. Der Mount steht danach weiter in /proc/mounts (per rshared auf den Host propagiert) und sieht vollkommen gesund aus - aber jeder Zugriff laeuft in den CIFS-Timeout. Damit erklaert sich alles, was vorher widerspruechlich aussah: warum es nach JEDEM Deploy passiert, warum `mount` Erfolg meldet, warum /proc/mounts genau eine korrekte Schicht zeigt, und warum nur ein echtes Neu-Verbinden hilft. Das NAS ist unschuldig (eine Sitzung, Status 1, 630 Credits, Ping 0,47 ms). Zweiter Fund, der den Rest erklaert: Direkt nach einem frischen Mount antwortete die Freigabe - und Sekunden spaeter nicht mehr. Das ist ein Wettlauf mit `umount -l`: lazy heisst, der Abbau passiert spaeter, und faellt er samt Propagation hinter den neuen Mount, zeigt der Pfad wieder auf die Leiche. Eine einzige Probe kann das nicht sehen - deshalb prueft `wirklich_erreichbar()` zweimal mit drei Sekunden Abstand, und zwar sowohl beim Mounten als auch in der Wache. Dazu: erste Pruefung der Wache schon nach 10 s statt 60 s. Genau dann ist die Lage nach einem Deploy kaputt. Ehrlich offen bleibt die strukturelle Folge: Der api-Container HAELT die NAS-Verbindung. Startet er mitten in einem Rip neu, verliert auch der Worker sein Ziel. Das saubere Gegenmittel waere ein Mount auf dem HOST statt im Container - ein eigener Umbau, und er widerspraeche "Speicherziele ueber das UI einhaengen". Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 14:32:51 +02:00
HitonabiandClaude Opus 5	549727f648	fix(mounts): Wache, die die Freigabe nach einem Rebuild von selbst zurueckholt ... Dreimal in Folge reproduziert, jetzt bei JEDEM Deploy: Nach `docker compose up -d --build` ist die CIFS-Freigabe tot. `mount` meldet Rueckgabewert 0, /proc/mounts zeigt genau eine korrekt aussehende Schicht, die Erreichbarkeits-Probe antwortet direkt nach dem Mount sogar - und Sekunden spaeter laeuft jeder Zugriff in die Zeitgrenze. Derselbe Ablauf ein bis zwei Minuten spaeter stellt sie zuverlaessig her (POST /storage-mounts/rippy/repair, mehrfach belegt). Die Ursache liegt am NAS und ist nicht gefunden. Aber die Wirkung ist teuer: Nach jedem Update war jeder Rip auf die NAS kaputt, ohne dass irgendwo etwas davon zu sehen war - und der Commander haette es jedes Mal von Hand richten muessen. Wenn die Heilung bekannt und billig ist, gehoert sie automatisiert, auch ohne die Ursache zu kennen. Die Wache sieht jede Minute nach und verbindet stumme Freigaben neu. Zwei Dinge sind dabei wichtiger als die Heilung selbst: 1. NIE waehrend ein Job laeuft. Neu verbinden heisst `umount -l`; mitten in einem Rip oder Encode waere das ein Datenverlust. Die Wache steht still, solange irgendein Job nicht durch ist - auch bei einem wartenden, der jeden Moment anlaufen kann (db.hat_arbeit). 2. Gemeldet wird nur der UEBERGANG. Ist das NAS ausgeschaltet, waere ein Log je Minute ein Wasserfall. Der Zustand steht in /health/vorraete, damit man sehen kann, dass die Wache lebt - dieselbe Lehre wie heute Nachmittag beim stillen except. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 14:24:09 +02:00
HitonabiandClaude Opus 5	be04a9772e	fix(auswurf): CDROMEJECT meldete Erfolg und tat nichts - erst entriegeln ... Commander-Meldung: "Den Button gibt es in den Settings, aber es passiert nicht, das Laufwerk geht nicht auf." Am laufenden System nachgestellt, mit der Disc, die gerade drin lag: wirf_disc_aus("/dev/sr0") -> True CDROM_DRIVE_STATUS danach -> 4 (Disc drin) Das ioctl wird also ANGENOMMEN und tut nichts. Ursache: MakeMKV verriegelt waehrend des Rips die Laufwerkstuer (CDROM_LOCKDOOR 1) und entriegelt sie nicht wieder. Ein verriegeltes Laufwerk quittiert den Auswurf trotzdem mit Erfolg. Gegenprobe an derselben Disc: CDROM_LOCKDOOR 0 + CDROMEJECT -> Status 2 (SCHUBLADE OFFEN) Genau das macht das Werkzeug `eject` immer: erst entriegeln, dann auswerfen. Zweite Haelfte des Fixes, und die wichtigere: Das Ergebnis wird GEPRUEFT statt geglaubt. Bisher gab wirf_disc_aus True zurueck, sobald das ioctl nicht geworfen hatte - und ins Log kam "Disc ausgeworfen", waehrend die Schublade zu blieb. Deshalb ist der Fehler in v3.14 durchgerutscht: Dort wurde richtig festgestellt, dass die Einstellung von niemandem gelesen wurde, und danach WURDE sie gelesen - ausgeworfen wurde weiterhin nicht. Jetzt wird das Laufwerk gefragt (bis zu 5 s, die Schublade braucht ein bis zwei), und "kein Datentraeger" zaehlt mit, weil ein Slot-Laufwerk keine Schublade hat. Dieselbe Luecke steckte im Auswurf-Knopf der API (devices.eject) - dort mit Klartext-Fehler, wenn die Disc drin bleibt. Der Auswurf sitzt uebrigens schon an der richtigen Stelle: nach dem Rip, VOR dem Einreihen der Kompression. Und das Laufwerk ist waehrend `transcoding` frei - has_active_job blockiert nur bei pending/running, der Worker laeuft mit 4 Slots. Die zweite Disc parallel war also nur am nicht aufgehenden Laufwerk gescheitert. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 14:03:10 +02:00
HitonabiandClaude Opus 5	87537bf3e5	fix(mounts): Ergebnis pruefen statt glauben - "mount" meldet Erfolg und liefert nicht ... Nachtrag zum vorigen Commit, weil der die Freigabe noch nicht zurueckbrachte. Dreimal reproduziert: Beim API-Start meldete `mount` Rueckgabewert 0, das Log schrieb "rippy: eingehaengt", /proc/mounts zeigte GENAU EINE korrekt aussehende Schicht mit den richtigen Optionen - und `timeout 6 ls /app/media/rippy` lief trotzdem in die Zeitgrenze. Derselbe Ablauf ein zweites Mal, per POST /storage-mounts/rippy/repair, stellte sie sofort her (30 s, danach erreichbar). Der erste SMB-Sitzungsaufbau kurz nach dem Container-Start geht also gelegentlich schief, ohne es zu melden. Ein Rueckgabewert von `mount` beweist deshalb nichts. Jetzt: Nach dem Mount wird geprueft, ob die Freigabe ANTWORTET (ist_erreichbar, harte Grenze). Wenn nicht, einmal loesen und neu mounten. Hilft auch das nicht, fliegt ein Fehler mit Klartext - dann steht im Log "FEHLER" statt "eingehaengt", was schlicht die Wahrheit ist, und der Nutzer bekommt den Hinweis auf die Reparatur-Funktion statt eines Rips, der spaeter still scheitert. Damit ist die Kette geschlossen: os.path.isdir kann nicht mehr im Kernel haengen (voriger Commit), die Rohdaten-Schleife stirbt nicht mehr daran, und ein Mount gilt erst als hergestellt, wenn er antwortet. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 13:46:37 +02:00
HitonabiandClaude Opus 5	a15623cc70	fix(mounts): Freigabe kam nach einem Rebuild nicht zurueck - Erreichbarkeit zuerst ... Bestandsfehler, beim Gegenpruefen dieser Sitzung aufgefallen und dreimal reproduziert: Nach `docker compose up -d --build` war die CIFS-Freigabe TOT (4 von 4 Zugriffen liefen in 10 s Timeout, /storage-mounts meldete `reachable: false`) - und blieb es. Erst POST /storage-mounts/rippy/repair stellte sie in einer Sekunde her. Beim API-Start haette dasselbe passieren muessen. Warum nicht: if os.path.ismount(ziel): return schreibtest(ziel) Der Mountpunkt existiert im NEUEN Container weiter (Bind-Mount vom Host), also sagte ismount "ist schon da" und alle_remounten() brach genau hier ab. Dazu oeffnet schreibtest() eine Datei OHNE Zeitgrenze - auf einem toten CIFS blockiert das im Kernel, und der Start-Thread haengt dauerhaft (das waren die zwei Threads im Zustand D, die diese Sitzung schon einmal gekostet haben). Jetzt entscheidet ist_erreichbar() zuerst - das hat eine harte Grenze (`timeout 3 ls`, seit 24.07. im Einsatz). Antwortet die Freigabe, sind ismount und schreibtest danach gefahrlos. Antwortet sie nicht, faellt es durch auf loesen + frisch mounten: derselbe Weg, den reparieren() geht, nur automatisch. Fuer den Commander heisst das: Der NAS-Mount steht nach einem Deploy wieder von selbst, statt still zu fehlen. Ohne das war jeder Rip auf die NAS nach einem Update kaputt, ohne dass irgendwo etwas davon zu sehen war. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 13:40:58 +02:00
HitonabiandClaude Opus 5	8ccca90e3c	fix(api): "konnte nicht nachsehen" ist nicht "ist weg" ... Gemessen nach dem letzten Deploy: Der ERSTE Zugriff auf die CIFS-Freigabe stallt nach einem Container-Neustart mehrere Sekunden (die SMB-Sitzung wird neu aufgebaut), danach antwortet sie in 0,01 s - zehn von zehn Versuchen, NAS per Ping bei 0,47 ms. Die Freigabe ist also gesund, nur der erste Griff ist teuer. In diesem Fenster lief die Pruefung in ihre Zeitgrenze, der Vorrat notierte "keine Rohdaten", und der Knopf "Neu komprimieren" verschwand - obwohl 74 GB dalagen. Der Nutzer haette daraus geschlossen, seine Daten seien weg. Genau diese Sorte Fehlschluss ("aus einem Zustandswert auf einen Mechanismus") hat das Projekt schon zweimal bezahlt. Deshalb drei Antworten statt zwei: "da", "weg", "unklar". 124 ist der Rueckgabewert von `timeout`, wenn es das Kind abgeschossen hat - das heisst NICHT angesehen. Bleibt eine Pruefung unklar und der Vorrat hatte vorher einen Treffer, wird die letzte bekannte Antwort gehalten statt Abwesenheit behauptet. Wer eine Ja/Nein-Antwort braucht (verzeichnis_da), bekommt im Zweifel weiter Nein - das ist die richtige Richtung fuer eine einzelne Abfrage. Live davor geprueft: Die Schleife LEBT jetzt (alter_sekunden 30 -> 21 -> 12 -> 3 ueber 100 s) und heilt sich selbst - sobald die Freigabe antwortete, stand mit_treffer=1 und can_retry=true. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 13:34:39 +02:00
HitonabiandClaude Opus 5	2554c2633b	fix(api): os.path.isdir hing im Kernel und toetete die Schleife - harte Zeitgrenze ... Ursache gefunden, nicht geraten. Der neue Diagnose-Endpunkt sagte `rohdaten.alter_sekunden: null` - die Funktion war NIE EINMAL fertig geworden, und kein Fehler war gemeldet. Der Blick auf die Threads des API-Prozesses zeigte zwei im Zustand **D** (uninterruptible sleep, im Kernel blockiert): tid=1600034 name=uvicorn state=D tid=1600037 name=uvicorn state=D Der Mechanismus: Die Schleife startete ihren ersten Durchlauf, waehrend Rippy beim Container-Start die CIFS-Freigabe neu einhaengte. Ihr `os.path.isdir` blieb im Kernel stecken, `asyncio.to_thread` kam nie zurueck, die Schleife erreichte ihr `sleep` nie - und war damit fuer immer tot. Sichtbar war nur, dass can_retry dauerhaft false blieb. Ein Timeout um den Aufruf haette nichts geholfen: Ein im Kernel haengender Thread laesst sich aus Python nicht abbrechen, jeder Versuch haette einen weiteren Thread verbrannt, bis der Pool leer ist. Ein Kind-PROZESS laesst sich abbrechen. Geprueft wird jetzt mit `timeout 4 ls -d <pfad>` - dasselbe Werkzeug, das mounts.ist_erreichbar seit dem 24.07.2026 fuer genau dieses Problem benutzt (dort fuer den toten NAS-Mount). Laeuft es in die Zeitgrenze, gilt das Verzeichnis als "nicht da": Ein Ort, den man nicht in Sekunden ansehen kann, ist fuer einen Rip ohnehin unbrauchbar. os.listdir bleibt fuer /app/media selbst - das ist ein lokales Verzeichnis, die Freigaben sind Unterordner davon. Und os.path.isdir bleibt fuer den Rueckfall auf /app/temp/raw: ein Docker-Volume, dort kann nichts haengen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 13:28:02 +02:00
HitonabiandClaude Opus 5	0d8426d353	diag(api): Vorrats-Schleifen pruefbar machen - der stille except hat gekostet ... Live-Befund: /jobs/<id>/rohdaten findet die 74,1 GB, aber can_retry blieb ueber 80 Sekunden false - der Vorrat der Hintergrund-Schleife war leer. Direkt im Container aufgerufen fuellt die Funktion ihn korrekt. Warum die Schleife im Server-Prozess nichts tat, war NICHT zu sehen: Der `except Exception: pass` verschluckte jeden Grund. Zwei Konsequenzen, unabhaengig von der Ursache: 1. Die Schleife MELDET ihren Fehler jetzt (print in den Container-Log) statt ihn zu verschlucken. Ein Hintergrund-Prozess, der still scheitert, ist schlimmer als einer, der laut scheitert. 2. Neuer Diagnose-Endpunkt GET /health/vorraete: nennt fuer Ping- und Rohdaten-Vorrat, wie ALT der letzte Durchlauf ist. Bleibt so ein Vorrat leer, ist am Endpunkt selbst naemlich nichts zu sehen - er antwortet nur dauerhaft "nichts gefunden". Die naheliegende Erklaerung (asyncio-Tasks ohne Referenz werden vom GC geholt) ist widerlegt: Die aeltere Ping-Schleife laeuft nach demselben Muster und lebt - ueber 72 Sekunden blieb jeder /capabilities-Aufruf unter 10 ms, waehrend ein toter Ping-Vorrat je 30 s einen synchronen Nachping von ~1 s gekostet haette. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 13:23:32 +02:00
HitonabiandClaude Opus 5	9fbaed4af8	fix(api): Rohdaten-Suche in den Hintergrund - /jobs darf nie am NAS haengen ... Bei der Live-Gegenprobe gemessen: Waehrend der CIFS-Mount nach einem Container-Neustart hochkam, brauchten /jobs und /jobs/<id>/rohdaten jeweils 10,0 Sekunden - genau der CIFS-Timeout. Das Dashboard fragt /jobs alle vier Sekunden ab; ein schlafendes NAS haette es damit dauerhaft eingefroren. Dieselbe Loesung wie beim Celery-Ping in /capabilities (v3.15): eine Hintergrund-Schleife im 30-Sekunden-Takt sieht nach, wo Rohdaten liegen, und /jobs liest nur noch ab. Kennt der Vorrat einen Job noch nicht (frischer Fehlschlag), zaehlt der billige lokale Ort auf der Container-Platte - der antwortet immer sofort. Live geprueft, nachdem der Mount stand: /jobs 0,022 s, /rohdaten 0,014 s, can_retry = true, 79.604.951.639 Bytes (74,1 GB) gefunden. Der 80-GB-Rohschnitt des Commanders ist damit erstmals ueber das UI wieder erreichbar. Der leere Treffer davor war KEIN Codefehler: der Mount stand in dem Moment schlicht noch nicht. Beleg nachgeliefert - im Container gemessen findet die Suche den Pfad in 0,000 s. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 13:15:42 +02:00
HitonabiandClaude Opus 5	108368d583	fix(jobs): Rohdaten werden gesucht statt geraten - "Neu komprimieren" ging nicht ... Bei der Live-Gegenprobe des neuen /rohdaten-Endpunkts aufgefallen, und der Fund ist groesser als der Endpunkt: Job 95afdc89 hatte `can_retry = false`, obwohl 79,6 GB intakter Rohschnitt unter /app/media/rippy/<id> lagen. Der Knopf "Neu komprimieren" existierte gar nicht. Der SAVEPOINT v3.16 schrieb dazu: "Rohschnitt 79,6 GB intakt -> 'Neu komprimieren' genuegt, kein Neu-Rip." Das war falsch, und zwar doppelt: _kann_neu_komprimieren suchte in /app/temp/raw/<id> und unter dem AKTUELLEN workDir -> Knopf erschien nicht retry_transcode berechnete raw_dir aus demselben aktuellen workDir -> haette am falschen Ort gesucht Ursache in beiden Faellen: Der Rip war mit einer Wahl NUR FUER DIESEN RIP auf die NAS gelegt worden (gibt es seit v3.15), die Einstellung selbst stand auf leer. Damit zeigte nichts mehr auf die Datei. Wieder derselbe Fehler, den dieses Projekt schon mehrfach bezahlt hat: aus einem Zustandswert (der heutigen Einstellung) auf einen Mechanismus (wohin damals gerippt wurde) geschlossen, statt nachzusehen. Neues Modul rohdaten.py sucht jetzt an allen Orten, die ueberhaupt in Frage kommen: Container-Standard, eingestelltes Arbeitsverzeichnis und jedes Ablageziel unter /app/media. Der Suchraum ist geschlossen, weil _arbeitsverzeichnis() im Worker nur diese zulaesst; verwechseln kann man nichts, weil Roh-Verzeichnisse exakt wie die Job-ID heissen (vollstaendige UUID) und fertige Ablagen "Titel (Jahr) [kurz-id]". Nicht in die Job-Zeile geschrieben, obwohl das sauberer waere: create_all legt nur fehlende TABELLEN an, keine Spalten - und Bestandsjobs (genau dieser Fall) haetten den Wert ohnehin nicht. 11 Tests, darunter der echte Fall, ein toter CIFS-Mount und der Klassiker "/app/media-boese". Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 13:09:44 +02:00
HitonabiandClaude Opus 5	843c54cd1a	fix(test): Erwartung korrigiert - ohne Quelle ist die Confidence 0,3, nicht 0,0 ... Meine eigene Testannahme war falsch, nicht der Code: Antwortet keine Metadaten-Quelle, setzt _scan_video bewusst 0,3 mit `type: unknown` und behaelt den Disc-Titel. Der Rip laeuft dann trotzdem, die Datei heisst nur wie das Disc-Label. Genau dieser Zweig ist Bestand und richtig. Gefunden von der Ampel (Lauf 140) - lokal laeuft dieses Modul nicht, es braucht fcntl. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 13:01:34 +02:00
HitonabiandClaude Opus 5	0c269a97ee	fix(metadaten): exakt schlaegt unscharf - Jikan beendet die Kette nur bei Treffer ... Der SAVEPOINT v3.16 vermutete, das Aehnlichkeits-Gate 0,55 sei "grosszuegig" und Jikan stehe in der Kette zu frueh (vor OMDb). Nachgerechnet - titel_aehnlichkeit ist eine reine Funktion - ergibt sich ein anderes Bild als vermutet: "Alien" vs. "Alien 9" -> 0,83 TRIFFT "Inception" vs. "Deception" -> 0,78 TRIFFT "Hero" vs. "Heroman" -> 0,73 TRIFFT "The Dark Knight" vs. "Dark Knight Rises" -> 0,69 TRIFFT Ein Kinofilm, den TMDB verpasst, bekam damit Anime-Metadaten mit Confidence 0,85 - und OMDb, das ihn kennt, wurde nie gefragt. Bemerkenswert dabei, und das widerlegt die Vermutung "einfach zu niedrig": Fuer den Fall, fuer den Jikan ueberhaupt eingebaut wurde, ist das Gate sogar zu HOCH. "Evangelion 2.22" gegen den MAL-Titel "Evangelion: 2.0 You Can (Not) Advance" ergibt 0,51 und faellt durch. Eine einzelne Zahl kann beides nicht leisten. Deshalb zwei Schwellen statt Umsortieren (Reihenfolge bleibt, AGENTS Regel B): Nur ein praktisch exakter Titel (>= 0,9) beendet die Kette. Ein unscharfer Treffer wird GEMERKT, dann wird OMDb gefragt - und erst wenn OMDb nichts hat, kommt er als VORSCHLAG mit Confidence 0,6 zum Zug. Damit gewinnt "exakt" immer gegen "unscharf", egal aus welcher Quelle. Antwort auf die Commander-Frage "JIKAN ist drin - wird das genutzt?": ja, und ab jetzt an der richtigen Stelle. Ehrlicher Vorbehalt: Live gegengeprueft ist das nicht - MyAnimeList war waehrend dieser Sitzung durchweg weg (Jikan antwortete HTTP 504 auf jede Anfrage). Die Arithmetik des Gates ist davon unberuehrt und in test_jikan_helpers.py festgehalten, die Kettenlogik in test_prescan_helpers.py. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 12:59:26 +02:00
HitonabiandClaude Opus 5	8b7bdfe798	feat(api): drei Endpunkte, die das Raten beenden - plus Restzeit in /jobs ... GET /worker-setup/pfad-map - was ein externer Worker fuer RIPPY_PATH_MAP eintragen muss, abgeleitet aus Rippys eigenen Mounts. DAS war der stille Blocker: /app/media/... sind Container-Pfade, ein externer Worker sieht sie nur uebersetzt, und dieses Mapping setzte NIEMAND. Externes Encoden konnte deshalb nie funktionieren, obwohl das Celery-Routing einwandfrei arbeitete (Job 95afdc89: angenommen, 182 ms spaeter abgelehnt). Hat Rippy keine Freigabe, sagt der Endpunkt das im Klartext samt Abhilfe - statt ein leeres Mapping zu liefern. GET /presets - Preset-Namen der Worker plus Empfehlung MIT Begruendung. Die Namen standen bisher fest verdrahtet an vier Stellen im UI. GET /jobs/{id}/rohdaten + DELETE /jobs/{id}?rohdaten=true - was liegen bleibt, wenn ein Job aus der Liste fliegt. Grund (v3.14): Entfernen loescht bewusst keine Dateien, aber Job und Rohdaten haengen nur an der Job-ID - der Rohschnitt ist danach UNERREICHBAR. Damals verwaisten so 75 GB unsichtbar, gefunden erst per SSH. /jobs liefert jetzt eta_sekunden + eta_text. Die Schaetzung entsteht in der API und nicht im Browser, aus drei Gruenden: ein Seitenwechsel setzte die Messreihe zurueck, zwei offene Tabs zeigten verschiedene Zahlen, und fuer einen externen Encoder-Worker gaebe es gar keine - genau dort wollte der Commander sie sehen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 12:58:06 +02:00
HitonabiandClaude Opus 5	4195854bf8	feat(bausteine): Preset-Liste, Pfad-Vorschlag und Restzeit - alles gemessen ... Vier neue reine Bausteine, jeder mit Tests. Sie beantworten Fragen, die Rippy bisher geraten oder gar nicht gestellt hat. 1. caps.parse_preset_liste - die Preset-NAMEN, die das HandBrake DIESES Workers wirklich kennt (`--preset-list`, Format im Worker-Image gemessen). Damit endet das Raten: die Namen unterscheiden sich je HandBrake-Version, und ein erfundener Name laesst die Kompression scheitern. Richtigstellung zum SAVEPOINT v3.16: Dort galt es als unmoeglich, die Hardware-Preset-Namen auf der Rippy-VM zu ermitteln, weil dort kein Hardware-Encoder laeuft. Gemessen ist das falsch - die Kategorie `Hardware/` steht vollstaendig in der Liste (VCN, NVENC, QSV, MF). HandBrake trennt zwei Fragen: --preset-list nennt alle Presets, --help nur die nutzbaren Encoder. Zwei Fragen, zwei Quellen. 2. mounts.pfad_map_vorschlag/pfad_map_zeile - der fehlende Anschluss fuer RIPPY_PATH_MAP. Geraten werden muss dafuer nichts: Rippy hat die Freigabe selbst eingehaengt und kennt ihre Quelle (//host/share). Mountpunkt plus Quelle IST das Mapping. NFS gibt bewusst "" - Windows-Schreibweise ist nicht ableitbar (AGENTS Regel D). Der Test fand dabei sofort die dokumentierte Windows-Falle: os.path.join baute `/app/media\rippy` in einen Container-Pfad, das Mapping waere still wirkungslos geblieben. _mountpoint nutzt jetzt posixpath. 3. presets.empfehlung - "immer das Beste" (Commander-Anforderung) ohne Punktesystem: fuer jede Lage eine feste Reihenfolge echter Namen, genommen wird der erste, den der Worker kennt. Hardware nur, wenn die Familie wirklich gemeldet ist (vce -> Preset heisst VCN, sonst liefe eine AMD-Karte unter dem Intel-Namen). vaapi und MF werden nie empfohlen: fuer vaapi gibt es kein Preset, bei MF ist die Nutzbarkeit nicht ablesbar. 4. eta - Restzeit aus dem gemessenen Fortschritt. Messreihe je Phase (Rip und Kompression haben nichts miteinander zu tun), Stillstand verlaengert die Schaetzung, und unter zwei Messwerten oder 60 Sekunden Spanne gibt es ehrlich keine Aussage. Test mit den echten 25.07.-Werten: 1,44 % in 29 min landet bei "noch ca. 1 Tag 23 h" - genau die Angabe, deren Fehlen den 50-Stunden-Lauf unsichtbar machte. Dazu: HandBrakes "Invalid preset <Name>" wird uebersetzt. Vorher stand im UI nur "HandBrake endete mit Code 3" - dass der Preset-NAME das Problem ist, war daraus nicht zu erraten. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 12:57:51 +02:00
HitonabiandClaude Opus 5	35cfcbcb07	style: echte Umlaute im ganzen Projekt + Installer im Rippy-Look ... Commander-Rueckmeldung: Umlaute fehlen. Ausloeser war sichtbar der Installer - "Diese Maschine uebernimmt die Video-Kompression fuer Rippy" stand woertlich im Screenshot. ## Die .ps1-Falle war loesbar, nicht unumgehbar Bisher galt: ausgelieferte .ps1 MUESSEN ASCII sein, weil PowerShell 5.1 sie ohne BOM als ANSI liest. Das ist nur die halbe Wahrheit - gemessen mit echtem powershell.exe 5.1: ohne BOM: $s = "Größe: äöü" + Unerwartetes Token -> Skript kaputt mit BOM: Groesse: aeoeue + laeuft, Length 16 korrekt Alle drei Skripte sind jetzt UTF-8 MIT BOM und tragen echte Umlaute; unter 5.1 gegengeprueft (BOM vorhanden, Parser fehlerfrei, Text korrekt gelesen). Der Kopfkommentar sagt das jetzt richtig statt "ASCII-only". ## Umstellung: Text ja, Bezeichner nein Umlaute gehoeren in Kommentare und Anzeigetexte, nicht in Funktionsnamen oder Datenschluessel. Deshalb je Sprache das passende Werkzeug: - Python: ueber den TOKENIZER - angefasst wurden ausschliesslich COMMENT- und STRING-Tokens. 156 Stellen. Code ist damit garantiert unberuehrt. - TypeScript: nur // und /* */ Kommentare sowie JSX-Text (kann per Definition kein Bezeichner sein). 24 Stellen. `const waehlen`, `let laeuft`, `plaetze`, `GeraetInfo` sind nachweislich unversehrt. - install.sh: Anzeigetext, aber die Shell-Funktionen (gruen/rot/gelb/titel) und der Schalter --nur-pruefen bleiben ASCII - das sind Schnittstellen. - Markdown: 0 Aenderungen, die Doku hatte schon Umlaute. ZWEI FEHLER MEINES KONVERTERS, beide von Werkzeugen gefangen: 1. In f-Strings steht in {...} CODE, kein Text. Aus f"{groesse}" wurde f"{größe}", waehrend die Variable groesse hiess - Ruff meldete F821 "Undefined name". Der Konverter lagert Einsetzungen jetzt aus. 2. Ein Dict-Schluessel wurde umbenannt: die Wortliste enthaelt das PRAEFIX "uebersprung", der Tabu-Schutz prueft aber ganze Woerter. bericht[...] ist wieder ASCII - Umlaute in Datenschluesseln brechen JSON-Runden und DB-Felder. ## Installer im Rippy-Look Statt hellgrau jetzt dieselben Toene wie das Web-UI (aus lib/design.ts uebernommen): slate-900 Flaeche, dunkle Eingabefelder, Amber-Hauptknopf wie "Los geht's" im Wizard. Oben ein Kopfbereich mit dem Farbverlauf amber -> indigo -> purple und dem Disc-Symbol - in WinForms per Paint-Ereignis gezeichnet, weil es dort keine Verlaeufe von der Stange gibt. Geprueft, nicht gehofft: Das Fenster wurde headless in ein PNG gerendert (DrawToBitmap) und angesehen - Verlauf, Symbol, Umlaute und Farben sitzen. RippyWorkerSetup.exe neu gebaut (57344 -> 60416 Bytes); Umlaute und das requireAdministrator-Manifest sind in der .exe verifiziert. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-25 22:37:23 +02:00
HitonabiandClaude Opus 5	11597eb00c	perf+cleanup(api): /capabilities war 1,0 s; vier tote Endpunkte entfernt ... Beides in main.py, deshalb ein Commit. ## 1. Das "Laggen" hatte genau eine Ursache Gemessen ueber alle 15 Endpunkte, die das UI beim Laden braucht: /capabilities 1,010 s /system/updates 0,491 s (haengt am Knopf, nicht am Seitenaufbau) /metadata/status 0,412 s (dito) die anderen 12 < 0,025 s /capabilities ist der einzige langsame, der beim SEITENAUFBAU zuschlaegt - und fuenf Stellen holen ihn (Dashboard, Einstellungen, Worker-Tab, Wizard, Rip-Dialog). Jede Seite zahlte eine Sekunde. Die Ursache ist kein Fehler, sondern das Wesen des Celery-Pings: er sammelt Antworten bis zum Timeout und kann nicht frueher aufhoeren, weil er nicht weiss, wie viele Worker noch antworten wollen. Den Timeout zu kuerzen wuerde Antworten langsamer Remote-Worker verschlucken - also genau die Maschinen, um die es beim externen Encoding geht. Jetzt pingt eine Hintergrund-Schleife im 5-s-Takt (neben Disc-Watcher und Key-Refresh, die es dort schon gibt), der Endpunkt liest nur ab. Vorrat aelter als 30 s - Schleife noch nicht angelaufen oder gestorben - dann EINMAL synchron pingen: lieber langsam als falsch ("alles offline", obwohl alles laeuft). ## 2. Vier tote Endpunkte raus Jeder ein Ueberrest eines ersetzten Entwurfs, keiner mit Aufrufer (mechanisch gegengeprueft: alle api.*-Aufrufe des UI gegen alle Routen): POST /prescan Metadaten-Vorschau-Seite ist seit v3.4 weg. Die PreScan-Klasse bleibt - sie hat 5 echte Fundstellen, der Watcher ruft sie im Prozess. POST /jellyfin/format Macht seit v3.2 der Worker (medien.py), und zwar an der richtigen Stelle: er kennt den Ausgabeordner und ist nach dem Rip am Zug. Mit ihm fallen nfo_generator.py und image_downloader.py weg (sonst unbenutzt). GET /stream/jobs Der unangenehmste: erst Placebo, am 23.07. "repariert" statt entfernt - aber ein EventSource im UI gab es nie (das Dashboard nutzt setInterval(..., 4000)). Also keine harmlose Leiche, sondern eine Endlosschleife je Verbindung, die jeder aufmachen konnte. GET /worker-setup/windows-gui Ohne Aufrufer seit die .exe den .bat-Umweg ersetzt hat (v3.9). install-gui.ps1 selbst lebt weiter, sie steckt in der .exe. main.py: 1726 -> 1682 Zeilen, dazu 279 Zeilen in zwei geloeschten Modulen. Tests halten beide Seiten fest: die vier Routen muessen WEG bleiben, und die drei, an denen die Worker-Installation haengt (/worker-setup/paket, /windows, /windows-exe), muessen DA sein. Ausserdem eine Doppelung entfernt - mein eigener _sicherer_dateiname-Test aus dem Vorcommit pruefte dasselbe wie der bestehende test_dateiname_validierung_blockt_pfad_tricks, und der war die ganze Zeit korrekt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-25 21:41:48 +02:00
HitonabiandClaude Opus 5	a1aabd591d	fix(test): Ampel rot - der Backslash-Test prueft nichts ... Meine eigene Zeile aus dem vorigen Commit. Im Quelltext stand "a\b.mkv" mit EINEM Backslash - Python liest \b als Backspace-Zeichen, der String enthaelt also gar keinen Backslash, und _sicherer_dateiname gab korrekt True zurueck. Der Test behauptete, den Backslash-Pfad zu pruefen, und tat es nicht. Jetzt ein Raw-String r"a\b.mkv". Warum das lokal nicht auffiel: test_api_smoke.py ueberspringt sich unter Windows selbst (main.py -> detection.py -> fcntl). Genau die Luecke, die im Savepoint als offener Punkt steht - hier hat sie sofort zugeschlagen. Lehre: Tests, die nur in der Ampel laufen, sind erst nach dem Push bewiesen, und Backslashes gehoeren in Raw-Strings. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-25 21:12:39 +02:00
HitonabiandClaude Opus 5	ef0a574a70	fix(worker,api): Platten-Schutz griff nicht, Fortschritt log, Auswurf tat nichts ... Vier Funde aus der Durchsicht, alle auf der VM gemessen. 1. DER PLATTEN-SCHUTZ AUS c065967 WAR WIRKUNGSLOS _original_aufheben() entschied per os.stat().st_dev, ob umgehaengt oder kopiert werden muss. Im Worker-Container gemessen - beides gleichzeitig wahr: st_dev /app/temp = 2050 st_dev /app/media = 2050 → identisch os.rename(...) → EXDEV, "Invalid cross-device link" Der Kernel vergleicht bei rename() den MOUNT, nicht das Geraet. /app/temp (Docker-Volume) und /app/media (Bind-Mount) sind zwei Mounts DERSELBEN ext4-Partition. Die Pruefung sah "gleiches Dateisystem", uebersprang die Platzpruefung, und shutil.move kopierte doch - 75 GB bei 37 GB frei. Der Schutz haette genau den Schaden zugelassen, gegen den er gebaut wurde. Jetzt wird os.rename VERSUCHT statt vorhergesagt: klappt es, ist es umgehaengt und fertig; kommt EXDEV, steht die Kopie fest und ERST DANN wird der Platz geprueft. Das ist keine Vermutung mehr, sondern die Antwort des Kernels. Vier Tests in test_original_aufheben.py, darunter genau der Fall, der die Platte fuellte. Die zwei alten Tests in test_medien.py sind dorthin gewandert - sie taeuschten per gefaelschtem os.stat "verschiedene Dateisysteme" vor, also genau die Annahme, an der der Schutz scheiterte. 2. DIE FORTSCHRITTSANZEIGE ZEIGTE DEN SCAN, NICHT DEN ENCODE get_progress_from_line matchte jede Zahl vor einem Prozentzeichen. HandBrake gibt Prozente aber in drei Phasen aus (Formatstrings aus dem Binary gelesen): Scanning title %d of %d, preview %d, %.2f %% → laeuft VOR dem Encode bis 100 % Encoding: task %d of %d, %.2f %% (%.2f fps, avg → der echte Wert Encoding: task %d of %d, Searching for start time, ... → Vorlauf Dazu warf `if progress > 0` im Aufrufer jeden Wert unter 1,00 % weg. Live beobachtet: Anzeige stand auf 99 %, der Encode bei 1,06 %; sie fiel erst auf 1, als der Encode die 1-%-Marke ueberschritt. Jetzt wird nur die Encoding-Zeile gelesen, `task N of M` mitgerechnet (sonst springt die Anzeige bei Zwei-Pass-Presets mitten in der Datei zurueck), und -1 heisst "keine Angabe" - dasselbe Muster wie bei get_progress_from_prgv. 3. "AUTOMATISCHER AUSWURF" WURDE VON NIEMANDEM GELESEN Die Einstellung (Standard: ein, "Disc nach erfolgreichem Ripping automatisch auswerfen") kam in keiner Zeile Backend-Code vor. DVD/Blu-ray warfen deshalb NIE aus, Audio-CDs IMMER, weil abcde `-x` fest verdrahtet bekam. Jetzt entscheidet die Einstellung beides: wirf_disc_aus() per CDROMEJECT-ioctl (fcntl-guarded, der native Windows-Worker laedt das Modul auch) und `-x` nur noch, wenn gewuenscht. 4. PFAD-PRUEFUNG FIEL AUF PRAEFIX-NAMEN HEREIN Elf Stellen prueften mit nacktem startswith(MEDIA_ROOT). "/app/media-boese/x" beginnt mit "/app/media", liegt aber ausserhalb - betroffen waren auch /browse und /browse/mkdir, wo der Pfad vom Nutzer kommt. Neuer Zwillings-Helfer unter_wurzel() in api/main.py und worker/tasks.py, alle elf Stellen umgestellt, Tests in beiden. Nebenbefund: _zielbasis() benutzte os.path.normpath - unter Windows werden daraus Backslashes, die MEDIA_ROOT-Pruefung greift nicht mehr, und das gewaehlte Ziel faellt still auf den Standard zurueck. Genau die Falle, die _arbeitsverzeichnis() drei Zeilen weiter dokumentiert und mit posixpath vermeidet. Live war es nie (nur aus rip_disc, das auf Windows verriegelt ist), jetzt konsistent. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-25 21:05:11 +02:00
HitonabiandClaude Opus 5	8bb075c656	feat(rip): Arbeitsverzeichnis je Rip waehlbar statt global vorgegeben ... Commander-Vorgabe 25.07.2026: "Du sollst es nicht automatisch setzen, es soll auswaehlbar sein - z. B. beim Rippen starten, oder VORHER wenn Vollautomatik eingeschaltet ist." Bisher gab es nur die globale Einstellung workDir, und die war ein freies Textfeld - man musste den Container-Pfad (/app/media/...) kennen. Beim Akira-Rip landeten deshalb 74 GB Rohdaten auf der 148-GB-VM-Platte, obwohl eine NAS-Freigabe mit 2,3 TB eingehaengt war. - RipTargetModal: neue Auswahl "Arbeitsverzeichnis fuer die Rohdaten", gespeist aus /storage-targets (mit Kennzeichnung als Netzwerk-Freigabe und freiem Platz je Ziel). Leer = "Standard aus den Einstellungen", der Wert wird zur Orientierung mit angezeigt. Bei Musik ausgeblendet - CD-Rips gehen direkt als FLAC ins Ziel, ohne Roh-Zwischenstufe. - POST /jobs nimmt work_dir entgegen, mit derselben Pfad-Haerte wie das Ziel (_validiere_ziel: muss unter /app/media liegen), und legt es in die Job-Metadaten. - _arbeitsverzeichnis(einstellungen, job_wahl) im Worker: Wahl dieses Rips -> Setting -> Container-Default. Damit bleibt die Einstellung genau das, was bei Vollautomatik-Rips greift, weil dort niemand gefragt wird. Der Text im Einstellungen-Tab sagt das jetzt auch so. - posixpath statt os.path in _arbeitsverzeichnis: das sind immer Container-Pfade, auch wenn ein nativer Windows-Worker das Modul laedt (der uebersetzt erst spaeter per pfad_lokal). os.path.normpath machte unter Windows Backslashes daraus, wodurch die MEDIA_ROOT-Pruefung nicht mehr griff - lokal als Testfehler aufgefallen. - Test deckt die Reihenfolge und die Ausbruchsversuche ab. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-25 19:59:37 +02:00
HitonabiandClaude Opus 5	f449c4ee34	fix(uhd): 4K-UHD geloest - makemkvcon holt Schluessel unter Linux nie ... Richtigstellung des Vortags-Befunds. Dort stand, MakeMKVs Schluessel-Kanal sei abgeschaltet. Das war FALSCH: die Herleitung stuetzte sich auf zwei Hostnamen aus alten Forumsbeitraegen (hkdata.fairuse.org, hkdata.crabdance.com), die zwar wirklich nicht mehr aufloesen, von MakeMKV aber laengst nicht mehr benutzt werden. Aufgedeckt durch den Einwand des Commanders, unter Windows ginge es sofort. Gegenprobe mit demselben Laufwerk und derselben Disc (Akira UHD, MKB v76): Linux (Worker) Windows Verbindungen KEINE EINZIGE 185.84.108.20:443 Meldung 3338 nie "Downloading latest HK" _private_data.tar 2048 B, 0 Keys 6,4 MB, 604 Keys Disc volume key unknown TCOUNT:5, geht auf Gegengeprueft mit leerem UND gefuelltem Speicher, mit und ohne --noscan, mit dev:/dev/sr0 und disc:0, mit geloeschter update.conf. Linux fragt nie. Die Meldungsvorlage "Downloading latest %1 to %2 ..." steckt sehr wohl im Linux-Binary - sie loest nur nicht aus. Gleiches Symptom im MakeMKV-Forum, seit Jahren offen (t=25782, t=34022). Der Dienst lebt; der Worker erreicht 185.84.108.20:443 sogar problemlos. BEWIESEN: Nach Uebernahme des Windows-Schluesselspeichers oeffnet makemkvcon auf der VM die Akira-UHD - "Operation successfully completed", TCOUNT:5, fuenf Titel, identisch zum Windows-Ergebnis. Erster belegter UHD-Disc-Zugriff auf der Rippy-Maschine. - makemkv_daten.py (beide Zwillinge): zaehle_schluessel, private_data_pruefen, schluesselspeicher_status, private_data_schreiben. Die Pruefung lehnt einen Speicher OHNE hkd_*.bin ab - sonst laedt jemand den leeren Vorrat einer frischen Installation hoch, nichts aendert sich, und niemand versteht warum. Modulkopf komplett neu, inkl. der Fehldiagnose als Warnung fuer spaeter. - API: GET/POST /system/keystore. Der Rohkoerper der Anfrage IST die Datei (binaer - JSON/Base64 waere Ballast, Multipart kann die API nicht). Groessengrenze 64 MB = client_max_body_size in nginx.conf. - UI: neuer Block "Disc-Schluessel fuer 4K-UHD" UEBER dem KEYDB-Block, mit Schluessel-Anzahl, Upload und Anleitung fuer den Windows-Weg. KEYDB.cfg ist jetzt als Notnagel beschriftet. Worker-Plakette zeigt die Anzahl; 0 heisst sichtbar "4K-UHD scheitert". - tasks.py: UHD-Fehlertext sagt den Windows-Weg an und nennt die Anzahl bekannter Schluessel dieses Workers. - caps.py meldet schluessel je Worker. - Alle Falschaussagen korrigiert: UI (3), Anleitung (2), README (3), KONZEPT §8 + §10, Worker-Dockerfile, makemkv_key.py (dort stand "Den AACS-Schluessel zieht MakeMKV via LibreDrive ohnehin selbst aus dem Laufwerk" - gilt fuer Blu-ray, NICHT fuer UHD). - SAVEPOINT v3.11, ROADMAP Etappe 18 (Etappe 17 mit Nachtrag), AGENTS. Offen: voller UHD-Rip inkl. Transcode-E2E; und ob sich der Abruf unter Linux doch anstossen laesst. Quellen (AGENTS Regel D): - Linux laedt keine Hashed Keys, gleiches Symptom: https://forum.makemkv.com/forum/viewtopic.php?t=25782 https://forum.makemkv.com/forum/viewtopic.php?t=34022 - Schluessel als hkd_*.bin in _private_data.tar: https://forum.makemkv.com/forum/viewtopic.php?t=32675 - Meldungsformat: https://www.makemkv.com/developers/usage.txt Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-25 11:18:09 +02:00
HitonabiandClaude Opus 5	0935766f61	feat(uhd): KEYDB.cfg-Unterstuetzung - MakeMKVs Schluessel-Kanal liefert nichts mehr ... 4K-UHD scheiterte an "The volume key is unknown for this disc". Am 25.07.2026 im Worker-Container nachgemessen: Laufwerk und MakeMKV sind in Ordnung (LibreDrive v06.3 / Meldung 1011, Disc wird gelesen, AACS-Dump geschrieben) - MakeMKV versucht gar nicht erst, online einen Schluessel zu holen. Belege: _private_data.tar enthaelt nur die Index-Datei und KEINE hkd_*.bin; auch mit geloeschter update.conf (Meldung 5074 belegt den Web-Kontakt) und mit app_UpdateEnable="1" kam keiner; hkdata.fairuse.org und hkdata.crabdance.com loesen weltweit nicht mehr auf (NXDOMAIN gegen Fritz!Box, 8.8.8.8, 1.1.1.1). Betroffen war Akira UHD (MKB v76, Pressung Dez. 2020) - also gerade KEINE Neuerscheinung. Der bisherige Fehlertext ("Disc neuer als die Schluessel-Datenbank, mit einem der naechsten Updates rippbar") war falsch. Einziger heute funktionierender Weg ist eine vom Nutzer selbst mitgebrachte KEYDB.cfg. Rippy liefert KEINE Schluessel mit, laedt keine herunter und verteilt keine - es stellt nur den Platz bereit und zeigt an, was dort liegt. - Datenverzeichnis persistent gemountet (MAKEMKV_DATA_HOST, Default /srv/rippy/makemkv): KEYDB.cfg und AACS-Dumps ueberleben jeden Rebuild. Vorher loeschte jeder "up -d --build" beides - inklusive des Dumps, auf den die Fehlermeldung selbst verwies. - entrypoint.sh und tasks.py schreiben settings.conf ergaenzend statt zerstoerend. Der entrypoint bricht bei nicht beschreibbarem Verzeichnis nicht mehr ab - mit "restart: unless-stopped" waere das ein Crashloop gewesen, in dem auch reines DVD-Rippen tot ist. - Neues Zwillings-Modul makemkv_daten.py (docker/api + docker/worker, byteweise identisch; test_zwillinge_sind_byteweise_identisch wacht darueber und wurde durch absichtliches Verstellen als wirksam nachgewiesen). - API: GET/POST/DELETE /system/keydb, GET /system/aacs-dumps(/{dateiname}). JSON-Body statt Multipart - python-multipart ist bewusst nicht installiert und wuerde die API beim Import toeten. nginx client_max_body_size 64m, sonst scheitert der Upload mit 413, bevor die API ihn sieht. - UI (Einstellungen -> System): Status, Hochladen per Datei-Dialog, Entfernen, Dump-Download, KEYDB-Plakette je Worker (nur wo das Verzeichnis wirklich gemountet ist - ein Remote-Transcode-Worker truege sonst eine Warnung, die ihn nichts angeht). - parse_msg() + log_cb: MakeMKV-Meldungen landen im Rippy-Log (gedrosselt: Code 1003 raus, keine Wiederholungen, max. 40 je Rip). Nebenbei behoben: der alte Parser (split(",", 4)[3]) schnitt jede Meldung am ersten Komma ab. - Fuenf Stellen richtiggestellt, die behaupteten, MakeMKV-Updates braechten die neueste Disc-Schluessel-Datenbank mit (UI, Anleitung, README, Worker-Dockerfile, makemkv_key.py). NICHT bewiesen: ein erfolgreicher UHD-Rip - es lag keine KEYDB.cfg mit dem Akira-Schluessel vor. Belegt sind der Befund und die neue Mechanik. So steht es auch im SAVEPOINT und in der ROADMAP. Quellen (AGENTS Regel D): - Datenverzeichnis + Dateiname GROSS/case-sensitiv: https://forum.makemkv.com/forum/viewtopic.php?t=30636 - hkd_*.bin in _private_data.tar: https://forum.makemkv.com/forum/viewtopic.php?t=32675 - headless settings.conf / app_UpdateEnable: https://forum.makemkv.com/forum/viewtopic.php?t=20364 - KEYDB.cfg-Zeilenformat (libaacs): https://github.com/ShiftMediaProject/libaacs/blob/master/KEYDB.cfg - MSG-/PRGV-Format: https://www.makemkv.com/developers/usage.txt Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-25 01:26:08 +02:00
HitonabiandClaude Opus 4.8	f74f4e54f6	fix(api): Job-Meta (poster_path) an die Jobliste durchreichen ... GET /jobs nutzt response_model=List[Job]; das Job-Model hatte kein meta-Feld, also schnitt FastAPI die Disc-Metadaten (poster_path) weg -> Dashboard.tsx bekam job.meta = undefined -> Filmstreifen-Platzhalter statt TMDB-Poster, sowohl in der Jobliste als auch im aktiven Rip-Header (beide aus /jobs). Additiv: meta: Optional[Dict] ins Job-Model + in _job_row_to_model parsen (json.loads wie im Detail-Endpunkt, defensiv gegen kaputtes JSON). Keine UI-Aenderung noetig -- posterUrl() rendert dann die vorhandenen Poster. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-25 00:03:41 +02:00
HitonabiandClaude Opus 4.8	0832ef777c	chore(handoff): portabel machen + Doku/Onboarding glaetten (Review-Umsetzung) ... Aus dem Weitergabe-Review. Kein Verhaltenswechsel fuer den Ursprungs-Host (alle Defaults = bisheriges Verhalten): Portabilitaet: - Laufwerk-Geraeteknoten via .env parametrisiert (OPTICAL_SR/OPTICAL_SG, Defaults sr0/sg1) - der #1-Blocker: auf Fremdhosts liegt das sg-Node woanders. - deploy.sh generisch (RIPPY_VM/RIPPY_REPO_URL/... aus der Umgebung) - keine festen Besitzer-Adressen (interne IP + DDNS) mehr im Repo. - POSTGRES_PASSWORD in compose durchverdrahtet (Default rippy) - war No-op. Aufraeumen (toter/irrefuehrender Code): - udev/ entfernt (fehlende Regeldatei, falscher Container-Name; durch ioctl- Polling ersetzt - reine Altlast). - docker/postgres/*, docker/redis/*, init.sql entfernt (nie eingebunden). Onboarding: - FirstRunWizard verdrahtet: App.tsx fragt GET /setup und zeigt den Einrichtungs-Assistenten beim ersten Start (war gebaut, aber nie gerendert). Doku: - README: Laufwerk-Abschnitt auf .env, ENV-Tabelle (OPTICAL_*/POSTGRES), rshared-Anleitung, neuer Abschnitt "Haertung fuer fremde/exponierte Netze". - config_validation.py: TMDB Pflicht->empfohlen, Zeichensalat-Tippfehler gefixt. - .env.example: TMDB-Wording, OPTICAL_*-Variablen. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-24 23:32:59 +02:00
HitonabiandClaude Opus 4.8	6a082cf77c	fix(mounts): mounten() idempotent - stale/tote Mounts vor Re-Mount loesen ... Folgefix zum remount-Vorfall 24.07.: mounten() fiel bei einem TOTEN Mount (os.path.ismount wirft OSError) auf den echten `mount` durch und stapelte auf die Leiche. Ueber viele Neustarts (via rshared propagiert, ueberlebt Container-Recreate) wuchs das auf 12 Schichten; die tote oberste blockierte jeden Zugriff (ls-Timeout, obwohl SMB-445 offen) -> Medien-Mount unbrauchbar. Fix: _stale_mounts_loesen(ziel) loest per lazy `umount -l` alle Schichten, bevor neu gemountet wird -> kein Stapeln mehr, Re-Mount idempotent. Ein gesunder Mount wird weiterhin frueh erkannt (os.path.ismount) und unangetastet gelassen. Tests (test_mounts_helpers.py): Loesch-Schleife bis leer (monkeypatch) + Verdrahtung. Ruff gruen. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-24 22:04:00 +02:00
HitonabiandClaude Opus 4.8	46a8f50c34	fix(api): remount nicht-blockierend (Netz-Mount darf API-Start nicht haengen) ... Vorfall 24.07.: Beim API-Start blockierte der synchrone CIFS-Schreibtest in alle_remounten()/mounten() im Kernel (wait_for_response), als der SMB-Server langsam war -> ~5 min "Waiting for application startup", kein Endpoint bedient (bis der soft-Mount per Timeout abbrach). startup_event() lief isoliert sauber, also war es der blockierende Netz-Mount, nicht die App-Logik. Fix: remount als Hintergrund-Task (asyncio.create_task) statt await -> die API kommt sofort hoch, die Mounts stellen sich her sobald der Server antwortet. Test (test_api_smoke.py): haelt den Nicht-blockierend-Vertrag per Quelltext- Inspektion fest, im Stil der anderen Verdrahtungs-Tests. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-24 21:50:32 +02:00
HitonabiandClaude Opus 4.8	3f47b504c2	feat(api): MakeMKV-Beta-Key automatisch erneuern ... Der kostenlose Beta-Key wechselt ~monatlich und laeuft zum Monatsende ab; bisher musste er von Hand nachgetragen werden, sonst blockt Blu-ray-Ripping irgendwann still. Neu: taeglicher Forum-Abgleich (t=1053) -> Key in die Settings (makemkvAppKey). Der Worker liest ihn VOR jedem Rip (tasks.py) -> wirkt ohne Rebuild ab dem naechsten Rip. - docker/api/makemkv_key.py: extract_key (pure, testbar) + fetch_current_key + refresh_once/refresh_loop; loggt in die App-Logs (add_log). - docker/api/main.py: refresh_loop als startup-Task. - docker/api/test_makemkv_key.py: Parser-Tests - fingen den Bug, dass Beta-Keys laenger als 64 Zeichen sind (Regex {50,} statt {64}). Betrifft nur die Software-Lizenz (oeffentlicher Gratis-Key), NICHT Disc-Schluessel - die zieht MakeMKV via LibreDrive selbst. Ruff gruen, 4 Tests gruen, Live-Fetch gegen das echte Forum verifiziert. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-24 21:27:38 +02:00
HitonabiandClaude Fable 5	20cdfedb85	feat(installer): fertige .exe mit Rippy-Icon + ohne Konsolenfenster (statt .vbs) ... Commander-Einwand: .vbs ist abgekuendigt (Win11 24H2 Feature-on-Demand) und wird oft als gefaehrlich geflaggt. Loesung: echte .exe. - RippyWorkerSetup.exe (50 KB): install-gui.ps1 via ps2exe kompiliert — eingebettetes Rippy-Disc-Icon (deploy/worker-windows/rippy.ico), kein Konsolenfenster (-noConsole), WinForms (-STA). E2E getestet: Fenster oeffnet, conhost-Zaehler unveraendert (kein Konsolenfenster). Vorgebaut auf Windows (build-exe.ps1) + committet — eine Windows-.exe kann nicht von Linux (Rippy-Host) gebaut werden. WICHTIG: friert KEINE Versionen ein — HandBrake wird zur Laufzeit (GitHub latest) und der Worker-Code live von Rippy geholt; nur bei GUI-Aenderungen neu bauen. - API: GET /worker-setup/windows-exe (FileResponse); Dockerfile kopiert die .exe ins Image. .gitattributes: *.exe/*.ico als binary. - UI (Worker -> Windows): 'Installer herunterladen (.exe)' als Haupt-Weg (generisch, GUI fragt Adresse ab; die einzutragende IP wird als Hinweis angezeigt). .vbs-Erzeugung entfernt. CLI bleibt Profi-Alternative. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 19:15:42 +02:00
HitonabiandClaude Fable 5	4fb29d16cf	feat(worker): grafischer Windows-Installer (GUI statt CLI) ... Commander-Wunsch: die CLI-Installation ist grausam. Jetzt: - install-gui.ps1 (WinForms, ASCII-only): Fenster mit Feldern (Rippy-IP, Worker-Name, Autostart-Checkbox), Install-Knopf mit Live-Log, danach 'Worker starten'-Knopf. Gleiche Schritte wie der CLI-Installer (Worker-Code + HandBrake latest + venv + Tray/Start/Uninstall). Braucht nur Python 3.10+, keine externe GUI-Runtime. - API: GET /worker-setup/windows-gui serviert die GUI; Dockerfile kopiert sie ins worker_dist/. - UI (Worker-Tab, Windows): 'Grafischen Installer herunterladen (.bat)' als Haupt-Weg — die .bat wird CLIENT-seitig mit der eingetragenen LAN-IP erzeugt (Blob-Download), Doppelklick laedt+startet die GUI von Rippy. Der CLI-Befehl bleibt als Profi-Alternative. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 18:47:57 +02:00
HitonabiandClaude Fable 5	dc1ceda0c2	fix(capabilities): Node-Zuordnung eindeutig bei mehreren Workern pro Host ... Laufen zwei Worker auf demselben Rechner (Befund 24.07.: alter + neuer Windows-Worker auf TobisNicerPC), war die Node-Zuordnung mehrdeutig — der Hostname-Match traf irgendeinen. Jetzt disambiguiert der Name-Teil des Celery-Knotens (WORKER_NAME), sonst Fallback auf den ersten Host-Treffer. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 18:33:22 +02:00
HitonabiandClaude Fable 5	47d07d6168	fix(mounts): Reparatur crashte an makedirs + reachable-Check auf 3s begrenzt ... - mounten(): FileExistsError von os.makedirs abgefangen und ismount OSError toleriert — ein toter Mount taeuschte isdir, die Reparatur brach ab. - ist_erreichbar(): 'timeout 3 ls' statt os.listdir — der direkte Zugriff blockierte sonst ~10s bis zum CIFS-Timeout (traege Speicherziele-Seite). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 18:23:12 +02:00
HitonabiandClaude Fable 5	4ba02047db	Drei Praxis-Bugs: tote NAS-Mounts reparierbar, HandBrake-Versionen konsistent, Encoder-Wahl beim Rip ... 1) Speicher-Mounts robust (Befund: toter CIFS-Mount nach NAS-Ausfall/Rebuild — mounted:false, verschwand aus 'Verfuegbare Ziele', Neu-Anlegen -> 409, man sass fest): - mounts.py: ist_erreichbar() (listdir, soft-Mount bricht schnell ab), ist_gemountet() faengt OSError toter Mounts, aushaengen() mit umount -l Fallback, reparieren() (lazy abhaengen + frisch mounten). - /storage-mounts liefert 'reachable'; POST bei existierendem Namen: aktiv -> 409, tot -> automatische Reparatur mit neuen Angaben; neuer POST /storage-mounts/{name}/repair (gespeicherte Zugangsdaten). - /storage-targets crasht nicht mehr an totem Mount (os.path.ismount OSError abgefangen). - UI: eigene 'Netzwerk-Mounts'-Liste mit Status (aktiv/nicht erreichbar/ getrennt) + Reparieren- und Entfernen-Knopf — tote Mounts sind sichtbar und wiederherstellbar statt zu verschwinden. 2) HandBrake-Versionen konsistent (Befund: Docker 1.6.1, Windows-Skript fest 1.9.2, Update-Check meldet 1.11.2 — verwirrend): - Windows-Installer zieht jetzt DYNAMISCH die neueste Version (GitHub latest, Fallback 1.11.2) — passt zum Update-Check. - Update-UI erklaert klar: Docker = stabiles Debian-Paket (bewusst aelter, kein Fehler), Windows = neueste. MakeMKV-Update zeigt den Befehl. 3) Encoder-/Worker-Auswahl beim Rip (Feature): - Celery worker_direct=True: jeder Worker konsumiert zusaetzlich seine Direkt-Queue. API-Helper transcode_queue(node) routet gezielt an den gewaehlten Worker, faellt aber sicher auf die geteilte transcode-Queue zurueck, wenn er offline ist (kein Haengenbleiben). - /capabilities liefert den Celery-Node je Worker; POST /jobs nimmt transcode_node (-> Job-meta); rip_disc + retry-transcode routen danach. - Rip-Dialog: Encoder-/Worker-Dropdown, sichtbar ab 2 Online-Workern. - ping_worker-Task zum Verifizieren des gezielten Routings. - Nebenfund gefixt: DeviceDiscovery leitete die Titel-Auswahl (titles) gar nicht an die API weiter — jetzt titles + transcode_node. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 18:19:57 +02:00
HitonabiandClaude Fable 5	3987c31b1e	Update-Check im System-Tab, Worker-Adressfeld mit Heimnetz-Warnung, Save-Knopf raus aus dem Worker-Tab ... 1. Update-Erkennung (Commander-Frage 'wie kriegen wir Updates mit?'): GET /system/updates vergleicht installierte Versionen (Worker-Info) mit makemkv.com (Versionsnummer der Download-Seite) und der HandBrake- GitHub-Release-API (releases/latest), 12 h gecacht. Einstellungen -> System: 'Auf Updates prüfen' + fertiger Update-Befehl bei MakeMKV. Selbst-Update gibt es bewusst NICHT (waere Docker-Socket-Zugriff); dafuer ist MAKEMKV_VERSION jetzt per .env uebersteuerbar — Update ohne Code-Aenderung. HandBrake-Abweichung wird als Info dargestellt (Debian-Paket hinkt der offiziellen Version bewusst hinterher). 2. Worker-Anbindung: editierbares Adressfeld statt stillschweigend window.location.hostname — Befund: ueber die externe Domain kopierte Befehle liefen in den Reverse-Proxy (401) und Worker koennen Redis/ Postgres eh nur im Heimnetz erreichen. Amber-Warnung bei oeffentlich aussehender Adresse, Anleitung ergaenzt. 3. 'Einstellungen speichern' ist im Worker-Tab ausgeblendet — dort gibt es nichts zu speichern, der Knopf verwirrte nur. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 15:39:20 +02:00