17 Commits

Include renames

Author	SHA1	Message	Date
HitonabiandClaude Opus 5	d3e86d2641	fix(windows): Der Schalter, den es nicht gibt, und vierzehn weitere Funde ... Commander: „Kompression fehlgeschlagen bei Spartacus … _t01.mkv: HandBrake endete mit Code 0" — 16,5 GB fertiger Rohschnitt, und die Kompression war in derselben Sekunde vorbei, in der sie begann. Nachgestellt mit genau der Befehlszeile, die Rippy baute: unknown option (--audio-codec) HandBrake has exited. $? = 0 Den Schalter `--audio-codec` gibt es bei HandBrakeCLI nicht; er heisst `-E` / `--aencoder`. Ein unbekannter Schalter ist fuer HandBrake kein Fehler, der Rueckgabewert ist 0. Der Test dazu forderte den falschen Namen sogar ein. Daraus wurde ein Rundgang durch den Windows-Pfad. Alles unten ist gemessen, nichts vermutet (Regel D). ## Die Kompression 1. `--aencoder` statt `--audio-codec`. Am mitgelieferten HandBrakeCLI 1.11.2 gemessen, mit einem 5-Sekunden-Encode auf der echten Roh-Datei bestaetigt. 2. HandBrakes letzte Zeilen werden aufgehoben (12 gepuffert, 4 in der Meldung) und `unknown option (...)` wird als eigener Fall erkannt, VOR allen anderen. Vorher wurde jede Zeile weggeworfen, die kein Fortschritt war — bei Rueckgabewert 0 blieb damit keine Auskunft uebrig. Die geratene Zeile „Meist ist der Zielordner nicht beschreibbar" ist raus; sie war falsch und hat die Suche in die falsche Richtung geschickt. 3. Ein `ue`-Umlaut im Pfad toetete die Kompression. HandBrake schreibt zwei Kodierungen in denselben Strom (derselbe Pfad einmal UTF-8, einmal CP850). In CP850 ist das Byte 0x81, und das ist in cp1252 — was `text=True` auf deutschem Windows waehlt — undefiniert: UnicodeDecodeError: charmap codec can't decode byte 0x81 Neu: `rip/handbrake_aufruf.py` mit `HB_LESEN`, benutzt von ripping.py und caps.py. Bewusst nicht binaer wie bei makemkvcon: HandBrake trennt Fortschrittszeilen mit CR, im Binaermodus waere der Balken weg. ## Die Rohdaten 4. `rohdaten.kandidaten` machte aus dem Arbeitsordner `F:\` ein `F:` und verband damit weiter. Das ist unter Windows der aktuelle Ordner auf Laufwerk F, nicht dessen Wurzel — 16,5 GB waren unsichtbar, und der Wiederholen-Dialog bot nur „Neu rippen" an. Die Falle steht woertlich im Kopf von `pfade.verbinden`. 5. Gesucht wurde unter der heutigen Einstellung statt unter der Wahl DIESES Rips (`meta["work_dir"]`). Genau dafuer wurde rohdaten.py am 26.07. gebaut; repariert wurde damals die Kandidatenliste, nicht der Aufrufer. Neu: `_arbeitsverzeichnis_des_jobs`, benutzt an vier Stellen. 6. Zwei Speicher fuer dieselben Ordner: Die Oberflaeche schreibt `outputDir`/`workDir` in die Datenbank, `betrieb` liest `storage.*` aus der Konfigurationsdatei, und die schreibt niemand. Gemessen: eingestellt `E:\Rippy`, angezeigt `C:\Users\...\Videos\Rippy`. Neu: `betrieb.mit_einstellungen`. ## Das Laufwerk 7. `device_info` fing den OSError ab und lieferte „unknown" ohne den Grund. Nach einem Rip mit Lesefehlern beantwortete das Laufwerk keine Medien-Abfragen mehr (Win32-Fehler 1), die Geraete-Auskunft aber schon — im UI stand eine volle Laufwerkskarte, kein Rip startbar, und im Protokoll das laengst veraltete „Disc erkannt". Neu: `ZUGRIFFS_GRUENDE`, ein Feld `grund` im Laufwerks-Eintrag und eine Protokollzeile je Wechsel. Eine fehlgeschlagene Disc-Erkennung wird ebenfalls protokolliert. 8. Der Linux-Treiber nannte ein unzugaengliches Laufwerk „empty", waehrend Windows richtig „unknown" sagt. Angeglichen, samt Feld-Paritaet. 9. `CreateFileW`, `DeviceIoControl` und `CloseHandle` hatten weder `restype` noch `argtypes` — 32-Bit-`c_int` fuer einen 64-Bit-HANDLE, in beide Richtungen. Mit `restype` aendert sich der Fehlerwert von -1 auf 0xFFFFFFFFFFFFFFFF; die Pruefung deckt jetzt beides ab. Am echten Laufwerk gegengeprueft, Fehlerpfad eingeschlossen. 10. Der Vor-Scan lief bei JEDER eingelegten Disc ein `makemkvcon info` mit 120 s Zeitgrenze — 20 bis 120 Sekunden „Disc wird gelesen". Frueher war das schnell, weil der Zweig unter Windows nie lief (`shutil.which`, repariert am 28.08.). Das Ergebnis landete allein in `toc["tracks"]`, das niemand liest: Der Rip-Dialog holt seine Liste ueber `/devices/{id}/scan-tracks`, wenn sie gebraucht wird. Entfernt. ## Notbremsen 11. `_frei_bytes` suchte den naechsten vorhandenen Ordner selbst. `os.path.dirname("Q:\\")` gibt sich selbst zurueck — ein Arbeitsverzeichnis auf einer abgezogenen Platte haette den Job vor dem Rip stumm haengen lassen. Benutzt jetzt `pfade.naechster_vorhandener`, das den Abbruch seit V2-1 hat. 12. `naechster_vorhandener` haelt Laufwerks- und UNC-Wurzeln jetzt absolut. 13. `aufraeum_skript` baut sein `rmdir /s /q` aus `InstallLocation` in der Registry. Waere das eine Laufwerks-Wurzel, loeschte die Deinstallation das Laufwerk. Nicht beobachtet, aber nicht wiedergutzumachen — der Loeschbefehl bleibt in dem Fall weg. ## Lesefehler MakeMKV sicherte 1 von 2 Titeln, endete mit 0, und Rippy schrieb „Rip fertig". Jetzt gibt es eine Warnung, auch wenn der Rip als Erfolg endet, und die MSG-Nummer steht im Protokoll: MakeMKVs Texte sind uebersetzt, die Nummern nicht. ## Aus der Gegenprobe am laufenden Rippy Die erste Fassung dieses Standes war installiert, als der Commander meldete: „nun oeffnen sich diverse fenster im hintergrund, gehen ganz kurz auf und dann wieder zu. Das laufwerk hoert auch einfach auf zu lesen." Beides Altlasten, die erst durch die neue Protokollzeile sichtbar wurden. 14. Prozesserzeugung mitgeschnitten: 14:54:40 timeout.exe timeout 4 ls -d C:\Users\...\d7ee6c06-... 14:54:40 WindowsTerminal.exe `rohdaten.pruefen` fragt mit `timeout N ls -d`, ob es ein Verzeichnis gibt. Unter Linux ist das richtig (os.path.isdir kann an einem toten CIFS-Mount im Kernel haengen, ein Kindprozess laesst sich abbrechen). Unter Windows ist es dreifach falsch: timeout.exe gibt es dort, kennt aber weder `ls` noch `-d`; sie braucht eine Konsole, und die reisst Windows auf; und ihr Rueckgabewert ist nie 0, die Antwort lautete also „weg" fuer JEDES Verzeichnis. Rohdaten waren unter Windows grundsaetzlich unsichtbar. Neu: `nativ_nachsehen()`. Die zwei gleichartigen Aufrufe in mounts.py bekommen dieselbe Absicherung. 15. Der Waechter fragte das Laufwerk alle drei Sekunden ab — auch mitten im Rip, also drei CreateFileW plus IOCTLs auf ein Geraet, das makemkvcon gerade liest: 12:49:52 bluray-Rip gestartet 12:50:09 [watcher] Laufwerk G: beantwortet keine Medien-Abfragen 12:50:12 MSG 2003 SCSI-Fehler ILLEGAL REQUEST:INVALID FIELD IN CDB 12:50:12 makemkvcon endete mit Code 11 `_auto_prescan` haelt sich seit dem 29.08.2026 an die Regel „waehrend eines Rips wird nicht gescannt"; die Laufwerksabfrage tat es nicht. Jetzt gilt in der Zeit der letzte bekannte Stand. ## Zwei Tests, die gelogen haben * `assert "--audio-codec" in cmd` schrieb den Fehler fest. * `lambda: {}` als Doppelgaenger fuer `get_settings(key, bei_fehler_leer)` brach, sobald ein Aufrufer einen Parameter benutzte — und zeigte dann auf den Code statt auf sich selbst. 977 Tests gruen, ruff sauber. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-30 15:11:00 +02:00
HitonabiandClaude Opus 5	b2acddbdfa	fix(windows): Drueberinstallieren, Linux-Reste im Windows-Betrieb, Ordner-Waehler ... Vier Fragen des Commanders vom 29.08.2026, drei davon mit Codefolge. ## 1. „Was passiert wenn man die Setup.exe einfach drueber installiert?" Bis hierher: nicht zuverlaessig. Rippy startet mit Windows, laeuft also fast immer — dann ist `Rippy.exe` gesperrt, `shutil.copy2` warf PermissionError, und die neue Fassung landete als `Rippy.exe.neu` daneben. Dazu die Meldung „wird beim naechsten Start uebernommen". **Diese Zusage hat niemand eingeloest.** `.neu` kam im ganzen Projekt genau einmal vor: an der Stelle, die es schrieb. Wer drueberinstallierte, behielt still die alte Fassung, und das Setup meldete Erfolg. Jetzt wird der laufende Rippy vorher beendet (`dienst_beenden` gibt es seit der Deinstallation und wartet auch die zwei Sekunden ab, die Windows fuer die Dateihandles braucht). Eine von einer aelteren Setup-Fassung liegengelassene `.neu` wird dabei uebernommen. Bleibt die Datei DANN noch gesperrt, gibt es einen klaren Fehler statt einer Zusage — Rippy im Infobereich beenden und das Setup erneut starten. Der Tausch laeuft bewusst im SETUP und nicht beim Dienststart: Windows sperrt eine laufende .exe, und `Rippy.exe` waere genau die zu ersetzende Datei. ## 3. Linux-Reste im Windows-Betrieb (Docker/Headless unveraendert) **`caps.py`: `os.path.isdir("/app")`.** Damit hielt sich der eigenstaendige Windows-Rippy fuer einen FREMDEN Worker — und das UI warnte vor fehlender Pfad-Uebersetzung auf einer Maschine ohne Container und ohne Freigabe. „Extern" heisst jetzt, was es meint: Rippy laeuft woanders als dieser Worker. **`caps.py`: `shutil.which("makemkvcon")` + `os.path.ismount(daten_dir)`.** Beide unter Windows immer falsch (Programme liegen nicht im PATH, ein normaler Ordner ist kein Mount). Die Schluessel-Auskunft blieb dauerhaft „unbekannt", obwohl MakeMKV samt Datenverzeichnis da war. Der Mount-Test bleibt fuer den Container, wo er einen Zweck hat. **`rohdaten.py`: `/app/temp/raw` und `/app/media` fest.** Dieses Modul findet die Rohdaten eines Jobs wieder — fuer den Wiederholen-Dialog und fuer „Rohdaten mitloeschen". Unter Windows fand es NIE etwas: Der Dialog meldete „keine Rohdaten", das Aufraeumen loeschte nichts, und die Bruchstuecke eines abgebrochenen Rips blieben liegen (bei 4K-UHD bis 100 GB). Sieben Tests wurden dabei rot, und zwar zu Recht: Sie pruefen Container-Regeln, liefen aber unter Windows. Die Wurzeln sind jetzt einspritzbar — beide Betriebsfaelle auf jedem Rechner pruefbar statt vom laufenden abhaengig. ## 4. „Der Durchsuchen button fehlt. Wie es der Installer auch macht" Neu: `OrdnerWaehler` — Pfadfeld plus „Durchsuchen …", benutzt fuer Ablage und Arbeitsverzeichnis. Es waere der DRITTE fest eingebaute Ordner-Browser geworden (RipTargetModal, StorageMounts); dieser hier ist wiederverwendbar. `/browse` weiss seit dem 28.08. selbst, in welchem Betrieb es laeuft. ⚠️ Beim Einbau fiel der Import unter den Tisch. `vite` pruefte das NICHT — das Buendel blieb byte-gleich gross, und zur Laufzeit waere es der naechste leere Bildschirm gewesen. Aufgefallen nur, weil die erwartete Anzahl Ersetzungen nicht stimmte. Im Browser gegengeprueft: alle sieben Laufwerke, Navigation in D:\, keine Konsolenfehler. 843 Tests gruen, ruff sauber. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-29 14:28:01 +02:00
HitonabiandClaude Opus 5	288f9eeb8d	feat(tools): Werkzeuge finden, holen und aktuell halten — Grundlage fuer Windows ... WAS: rippy/tools/ mit katalog.py (finden + Version) und beschaffen.py (herunterladen, installieren, Update-Stand). ripping.py und caps.py fragen den Katalog statt shutil.which. DER BEFUND, DER DAS NOETIG MACHT: Der Bestand suchte AUSSCHLIESSLICH mit shutil.which(). Im Container stimmt das — dort liegen beide Werkzeuge in /usr/local/bin. Unter Windows findet es NICHTS, auch wenn alles installiert ist: Windows-Programme liegen in Program Files, nicht im PATH. Am 28.08.2026 auf dem Commander-PC nachgesehen — MakeMKV lag unter "C:\Program Files (x86)\MakeMKV\makemkvcon64.exe", which sah es nicht. Fuer einen Rippy, der unter Windows eigenstaendig arbeiten soll, ist das der Unterschied zwischen "laeuft" und "laeuft nicht". Vorher/nachher gemessen: vorher check_makemkv_installed() -> False (obwohl installiert) nachher check_makemkv_installed() -> True build_makemkv_cmd()[0] -> C:\Program Files (x86)\MakeMKV\makemkvcon64.exe SUCHREIHENFOLGE, mit Begruendung im Modul: eingestellt > Rippys eigener Werkzeug-Ordner > PATH > bekannte Installationsorte > Uninstall-Zweig der Registry. Rippys eigener Ordner steht VOR dem System, damit eine selbst gepflegte Fassung eine alte Systeminstallation schlaegt. VERSION: HandBrakeCLI kann --version. makemkvcon KANN DAS NICHT (usage.txt kennt keinen solchen Schalter) — die Version kommt aus dem Uninstall-Zweig. Dort steht bei MakeMKV zwar eine Version, aber InstallLocation ist LEER (nachgesehen); deshalb wird der Ordner ersatzweise aus DisplayIcon bzw. UninstallString abgeleitet. Der Test dafuer hat sofort einen Fehler gefunden: '"C:\...\uninstall.exe" /S' liess sich mit einem blossen strip('"') nicht aufloesen. BESCHAFFUNG, an echter Hardware gemessen: HandBrake GitHub-Release-API -> 1.11.2, HandBrakeCLI-1.11.2-win-x86_64.zip geladen, entpackt, gestartet: meldet sich als 1.11.2. 2,8 s. MakeMKV makemkv.com antwortete mit HTTP 525 (Cloudflare) — auch mit Browser-Kennung. Dieselbe Sperre, die im Projekt schon den Docker-Bau lahmlegt. Deshalb: Abruf wird versucht, ein Fehlschlag wird im Klartext gemeldet, und eine selbst geholte Datei laesst sich weiterhin verwenden. Ein Update-Server, der heute antwortet, darf keine Startbedingung fuer morgen sein. DREI FALLEN, GEGEN DIE ES TESTS GIBT: - Die .sig-Datei liegt im Release direkt neben dem ZIP und ist 566 Bytes gross. Wer nur nach "win" filtert, laedt sie. - "1.9.2" ist als Zeichenkette GROESSER als "1.11.2". Ein Update-Hinweis, der ab Version zehn dauerhaft in die Irre fuehrt — und genau dort ist HandBrake gerade. - Eine Fehlerseite kommt oft mit HTTP 200. Sie darf keine funktionierende Installation ersetzen: erst laden, pruefen, dann tauschen. Und: Ist die neueste Version unbekannt (Quelle tot), steht NICHT "Update verfuegbar" da. Eine Nichtauskunft ist keine Aussage. GEMESSEN: ruff sauber, 489 Tests gruen + 15 uebersprungen (vorher 456). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 11:12:21 +02:00
HitonabiandClaude Opus 5	059183c651	feat(windows): V2-4 fertig — RippySetup.exe, Taskmanager-Eintrag, Deinstallation ... WAS: Eine 28,6-MB-Datei, drei Betriebsarten. Doppelklick installiert, `--dienst` laeuft im Hintergrund, `--deinstallieren` raeumt sich weg. Dazu packaging/windows/build.py, das sie baut. DIE ZWEI COMMANDER-WUENSCHE, GEMESSEN: 1. EINTRAG IM TASKMANAGER ProcessName Rippy Beschreibung Rippy — automatisches Ripping Produkt Rippy Version 2.0.0 Der Prozessname kommt vom Dateinamen (bei der Installation kopiert sich die Datei als Rippy.exe), die Beschreibung aus einer eingebetteten Versions-Ressource. Ohne die steht dort nichts, und Windows SmartScreen sieht eine EXE ohne Herausgeberangabe genauso misstrauisch wie ein Mensch. 2. EINTRAG IN PROGRAMME UND FEATURES Aus der Registry zurueckgelesen, nicht behauptet: DisplayName Rippy DisplayVersion 2.0.0 Publisher Rippy InstallLocation <Zielordner> UninstallString "<pfad>\Rippy.exe" --deinstallieren EstimatedSize 29241 (KiB) NoModify/NoRepair 1 HKCU statt HKLM: Der Eintrag erscheint genauso in "Apps & Features", die Installation laeuft aber ohne UAC-Abfrage durch. VOLLER KREISLAUF GEMESSEN: installieren -> Rippy.exe + rippy.ico liegen da, Registry-Eintrag da, Autostart da; Dienst starten -> nach 1 s bereit, alle sieben Endpunkte HTTP 200, Oberflaeche kommt; deinstallieren -> nach ~4 s sind Datei, Ordner, Registry-Eintrag, Autostart UND das Aufraeum-Skript weg. VIER FEHLER, DIE NUR DIE FERTIGE EXE ZEIGT: 1. rippy/store baute die Engine BEIM IMPORT, mit PostgreSQL als Vorgabe. Im Windows-Paket gibt es psycopg2 bewusst nicht -> die EXE starb sofort. Die Engine entsteht jetzt beim ersten Zugriff. Und der Fehler war grundsaetzlicher als der fehlende Treiber: Ein Modul, das beim Import schon eine Verbindung aufbaut, laesst sich gar nicht mehr umstellen — store.verbinden() kaeme immer zu spaet. 2. celery_client baute den Broker-Client beim Import. Dasselbe Muster, und `from celery_client import celery_client` loeste es sogar dann aus, wenn nie ein Rip angestossen wird. Jetzt traege, mit KeinBroker als klarer Ansage statt eines Importfehlers. 3. Die Selbstloeschung beim Deinstallieren ging als EIN Argument an cmd. Python maskiert dabei die inneren Anfuehrungszeichen — cmd suchte einen Dateinamen mit Backslashes davor, fand nichts und meldete nichts (>nul). Registry und Autostart waren weg, die 28-MB-Datei blieb liegen: ein still scheiternder Hintergrundprozess, wie ihn AGENTS.md beschreibt. Jetzt ein Aufraeum-Skript, das 15-mal versucht (die Onefile-EXE laeuft als ZWEI Prozesse; der Starter haelt die Datei nach dem Ende noch offen). 4. deinstallieren() raeumte den STANDARD-Ordner auf statt des tatsaechlichen. Wer nach --ziel D:\Rippy installiert hatte, dessen Dateien waeren geblieben, waehrend ein fremder Ordner angefasst worden waere. Der Pfad steht in der Registry (InstallLocation) und wird jetzt dort gelesen. WAS NOCH NICHT GEHT, ausdruecklich: Ein RIP laesst sich unter Windows noch nicht anstossen — die Zustellung laeuft weiter ueber Celery. Die Umstellung auf die LocalQueue ist V2-5. Oberflaeche, Laufwerks-Erkennung, Auswurf und alles Lesende laufen. GEMESSEN: ruff sauber, 456 Tests gruen + 15 uebersprungen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 11:00:39 +02:00
HitonabiandClaude Opus 5	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	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	6438beec05	fix(worker): kein CMD-Blitzen mehr - und die 7200-Sekunden-Meldung ist erklaert ... Zwei Meldungen, beide auf dieselbe Wurzel zurueckgefuehrt: Der Worker startet Konsolenprogramme, und das hat unter Windows Nebenwirkungen. 1. "Es geht immer alle paar Sekunden ne CMD auf." Kein Geist, sondern der HERZSCHLAG. Der Worker laeuft als pythonw.exe, also ohne eigene Konsole. Wer ohne Konsole ein Konsolenprogramm startet, bekommt von Windows eine NEUE - und die ist sichtbar. `capture_output=True` hilft nicht: es leitet die Datenstroeme um, unterdrueckt aber kein Fenster. Und caps.py fragt jede Minute `HandBrakeCLI --help`, `--preset-list` und `--version` ab, dazu makemkvcon aus der Schluessel-Automatik: vier bis fuenf Fenster pro Minute, in Schueben. Neues winlauf.py haelt CREATE_NO_WINDOW an EINER Stelle; alle elf Aufrufe in caps.py, ripping.py und schluessel.py benutzen es. Auf Linux ist der Wert 0 und creationflags=0 eine Nulloperation - im Worker-Container gegengeprueft, damit derselbe Code auf beiden Seiten laeuft. 2. Die 7200 Sekunden sind CELERYS EIGENE UMRECHNUNG, nicht die Uhren. Erst fiel auf, dass die Sekundenbruchteile nur 40 ms auseinanderliegen (.177269 vs .134799) - derselbe Augenblick, zweimal verschieden gerechnet. Die Quelle sagt warum (celery/utils/time.py): def utcoffset(): # Sekunden WEST von UTC, in Stunden return time.altzone // 3600 # CEST -> -2 ; UTC -> 0 def adjust_timestamp(ts, offset, here=utcoffset): return ts - (offset - here()) * 3600 Absender VM (offset 0), Empfaenger Windows-PC (here() = -2): ts - (0 - (-2)) * 3600 = ts - 7200. Celery verschiebt den empfangenen Stempel also selbst und vergleicht ihn dann mit der eigenen Uhr. Die Annahme dahinter - Ereignisse truegen Ortszeit - stimmt nicht, `Event()` stempelt Epoch. Abhilfe gemessen, nicht geraten: Mit TZ=UTC meldet Windows utcoffset 0 (timezone=0, isdst=0 - auf dem Commander-PC geprueft), damit wird die Umrechnung zur Nulloperation. Beide .bat-Dateien setzen es jetzt. Nebeneffekt ist erwuenscht: Der Worker rechnet dann in derselben Zone wie die VM und wie Rippys UI. Fuer Rippy war die Meldung ohnehin folgenlos - /capabilities fragt per Celery-Ping (Frage/Antwort, ohne Zeitstempel), nicht ueber die Gossip-Ereignisse. Aber eine Warnung, die bei jedem Blick ins Log steht und nichts bedeutet, kostet Vertrauen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 16:05:54 +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	fd1feaaee3	fix(ui): die Ablage war im UI ueberhaupt nicht einstellbar ... Der Grund, warum der erste Rip mit externem Encoder scheitern MUSSTE - und Commander-Vorgabe: "Wenn ein externes Ziel eingehaengt ist, soll Rippy das ausgewaehlte als Arbeitsziel verwenden. Das stellt man ja sowieso in den Einstellungen ein. Das muss auch fuer den Automatik-Modus so sein." Genau das ging nicht. outputDir stand in den Einstellungen, wurde von der Vollautomatik (main.py) und der Schnellwahl (RipTargetModal) gelesen - aber es gab NIRGENDS ein Eingabefeld. Die Ablage klebte auf /app/media, der Container-Platte. Das Arbeitsverzeichnis hatte eine Auswahlliste der eingehaengten Ziele, das Ziel nicht. Folge im Praxistest: Rohdaten auf der NAS (die der PC erreicht), Ziel auf der VM-Platte (die er nicht erreicht, kein Samba dort). Der externe Encoder konnte lesen, aber nicht schreiben - und das haette man mit den vorhandenen Bedienelementen gar nicht anders einstellen koennen. JETZT: Ablage-Auswahl in Einstellungen -> Ripping, mit derselben Liste eingehaengter Ziele wie das Arbeitsverzeichnis. Damit wirkt sie automatisch auch in der Vollautomatik und in der Schnellwahl, weil beide outputDir lesen - also genau so, wie der Commander es beschrieben hat. DAZU die Pruefung, die den Vorfall verhindert haette: Sobald ein EXTERNER Worker gemeldet ist, warnt das UI, wenn Ablage und Arbeitsverzeichnis nicht beide auf einer erreichbaren Freigabe liegen. Drei Faelle, jeweils mit der Konsequenz im Klartext: - Arbeitsverzeichnis auf der Container-Platte -> externer Encoder kann nicht lesen - Arbeit auf Freigabe, Ablage lokal -> kann lesen, nicht schreiben (der Vorfall) - beide auf VERSCHIEDENEN Freigaben -> laeuft, kostet aber eine Vollkopie "Extern" ist dabei keine Heuristik ueber IPs oder Namen: caps.py meldet es selbst (`extern`), weil /app im Rippy-Image immer existiert und ausserhalb nie. Zusaetzlich meldet der Worker jetzt seine `pfad_map` - damit kann das UI im naechsten Schritt sagen, ob die Uebersetzung ueberhaupt gesetzt ist. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 11:58:58 +02:00
HitonabiandClaude Opus 5	fe12401e34	fix(worker): Hardware-Encoder und CPU-Merkmale auf Windows - plus ehrliche Transcode-Fehler ... Aus dem gescheiterten Test-Rip des Commanders (Job 95afdc89) und seiner UI-Durchsicht. Der Reihe nach. ## 1. Der externe Encoder wurde SEHR WOHL gesehen (Diagnose-Korrektur) Der Commander schloss aus der Meldung, das System sehe seinen PC nicht. Live gemessen sagt das Gegenteil: meta.transcode_node = tobisnicerpc@TobisNicerPC VM-Worker-Log = nur rip_disc, KEIN transcode_files 22:19:41.271 Kompression eingereiht 22:19:41.453 "Keine Roh-MKVs gefunden" <- 182 ms spaeter Das Routing hat funktioniert. Sein PC nahm die Aufgabe an und lehnte sie sofort ab, weil er /app/media/rippy/<job> nicht finden kann - ein Pfad, der nur INNEN im Container existiert. Der Rip war vollstaendig (79,6 GB auf der NAS). ## 2. Der Hardware-Encoder-Bug war meiner leite_backends_ab() verlangte zusaetzlich ein Geraet: /dev/dri fuer VAAPI/QSV/VCE bzw. nvidia-smi fuer NVENC. Unter WINDOWS gibt es beides nicht - der PC des Commanders (RX 9070 XT) meldete deshalb nur CPU-Encoder, obwohl HandBrakes Windows-Build vce_*/nvenc_*/qsv_* beherrscht. Der Bug traf genau den Anwendungsfall, fuer den externe Worker gedacht sind. Die Pruefung war ausserdem ueberfluessig: HandBrake probiert Hardware beim Start selbst an und listet nur Nutzbares - auf der VM belegt durch "qsv: not available on this system" bei gleichzeitig fehlendem qsv_* in --help. Jetzt ist HandBrakes Liste die einzige Auskunft. Dazu nach FAMILIE unterschieden (nvenc/qsv/vce/vaapi) statt alles in "vaapi" zu werfen - eine AMD-Karte lief unter dem Intel-Namen. Hardware-AV1 bekommt eine eigene Kennung, weil es die beste Kombination aus Tempo und Groesse ist und sonst unsichtbar bliebe. ## 3. Vektorbefehle unter Windows - gemessen, nicht "unbekannt" Es gibt dort kein /proc/cpuinfo, also meldete der Windows-Worker "Vektorbefehle unbekannt" - gerade auf der Maschine, die encodieren soll. Jetzt ueber IsProcessorFeaturePresent (kernel32, winnt.h dokumentiert) plus CPU-Name aus der Registry. Auf dem Commander-PC gegengeprueft: vorher: AMD64 Family 26 Model 68 Stepping 0 / Vektorbefehle unbekannt jetzt: AMD Ryzen 7 9700X 8-Core Processor / avx512f / 16 Kerne Damit verschwindet die AVX2-Warnung fuer diesen Worker von selbst - genau das hatte der Commander gefordert. ## 4. Ehrliche Fehlermeldung statt "Keine Roh-MKVs gefunden" Neues _erreichbarkeit_pruefen() unterscheidet jetzt drei Faelle statt einem: Pfad nicht erreichbar UND kein Mapping gesetzt (nennt RIPPY_PATH_MAP samt Beispiel), Mapping gesetzt aber greift nicht, oder Pfad einfach nicht da. Und es prueft BEIDE Pfade - im Fall des Commanders lag die Quelle auf der erreichbaren NAS, das ZIEL aber auf der VM-Platte ohne Samba; das waere erst beim Schreiben nach Stunden Rechenzeit aufgefallen. Jede Meldung sagt jetzt ausdruecklich, dass die Rohdaten NICHT verloren sind und "Neu komprimieren" genuegt. ## 5. Persoenliche Werte raus Vier Platzhalter trugen die Umgebung des Commanders (192.168.178.20, TOBIS-PC, seine Jellyfin- und Rippy-IP). In einem Repo, das weitergegeben wird, hat das nichts verloren. Nebenbei dreimal in die eigene Falle getappt: deutsche Anfuehrungszeichen in DOPPELT gequoteten Python-Strings beenden den String vorzeitig. Der Bestand nutzt dafuer einfach gequotete f-Strings - jetzt auch meine. NOCH OFFEN und wichtig: RIPPY_PATH_MAP wird von niemandem GESETZT (Installer, UI, Compose). Ein Windows-Worker kann damit grundsaetzlich nicht transcodieren. Das ist der naechste Schritt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 11:51:47 +02:00
HitonabiandClaude Opus 5	883c1c290b	fix(caps,ui): Encoder werden gemessen statt behauptet ... Der Modulkopf von caps.py verspricht "ehrlich erkannt, nicht behauptet" - erkenne_encoder() tat aber drei Mal das Gegenteil: 1. cpu-x264 und cpu-x265 standen fest verdrahtet in der Liste ("immer dabei"). Ein Rip-Worker OHNE HandBrake behauptete damit, komprimieren zu koennen; jeder Transcode dort endete sofort mit "nicht installiert". 2. 'vaapi' wurde allein wegen /dev/dri gemeldet, ohne zu pruefen, ob HandBrake das ueberhaupt kann. Auf der VM gemessen: das Worker-Image kennt svt_av1/x264/x265/mpeg4/mpeg2/VP8/VP9/theora und KEINEN einzigen Hardware-Encoder. Rippy haette VAAPI versprochen und dann versagt. 3. Ueber die Rechenleistung sagte es gar nichts. Genau deshalb war nicht zu sehen, dass ein 4K-Encode auf dieser Maschine Tage braucht: CPU-Modell ist das generische "QEMU Virtual CPU version 2.5+", grep -c avx2 /proc/cpuinfo = 0, nur bis sse4_2. x265 lebt von AVX2. Gemessen an der Leseposition des Quellstroms: 28-55 h fuer einen Film, 3,84 von 4 Kernen gesaettigt. Abhilfe waere der CPU-Typ 'host' in Proxmox. Jetzt wird die Encoder-Liste aus `HandBrakeCLI --help` geparst (Abschnitt -e/--encoder, Formatstrings im Worker-Image gemessen - AGENTS Regel D), und Hardware zaehlt nur, wenn Geraet UND HandBrake-Unterstuetzung da sind. Neu gemeldet: cpu-av1 (svt_av1 ist wirklich verfuegbar) sowie CPU-Modell, Kernzahl und Vektorbefehlsstufe je Worker. UI: Kerne/Vektorbefehle stehen bei jedem Worker (Worker-Tab und Einstellungen -> System), dazu die ungefilterte HandBrake-Auskunft und eine sichtbare Warnung, wenn AVX2 fehlt - inklusive des Hinweises auf den VM-CPU-Typ. Der Warntext liegt in lib/encoder.ts, damit er nicht doppelt im Code steht. Mit im gleichen Zug (dieselbe Datei): der Schalter "Alle Tracks rippen" ist entfallen. Er war ein Placebo - abcde bekommt keine Track-Auswahl und es gab auch keine Oberflaeche, um eine Teilmenge zu waehlen. Eine Audio-CD wurde also immer vollstaendig gerippt, egal wie der Schalter stand. An seiner Stelle steht jetzt die Wahrheit. 7 Tests, Testdaten sind echte HandBrake-Ausgaben von der VM. Der Parser ist zusaetzlich gegen die vollen 697 Zeilen der echten --help gegengeprueft. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-25 21:04:42 +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 Fable 5	5778ac4645	Praxis-Feedback-Runde: CIFS-Cap-Fix, TMDB v3-Keys, 4K-UHD-Typ, Vollautomatik, Job-Verwaltung, Worker-Namen ... Zwei bewiesene Bug-Fixes: - SMB-Mount 'Unable to apply new capability set': mount.cifs hebt CAP_DAC_READ_SEARCH an, die in Dockers Default-Caps fehlt (auf der VM reproduziert: Bounding-Set a82425fb ohne Bit 2; mit der Capability verschwindet der Fehler). Fix: cap_add DAC_READ_SEARCH fuer den api-Container. - TMDB fiel still aus: Client konnte nur v4-Bearer-Tokens, der uebliche 32-Hex-v3-Key bekam 401 und die Suche lieferte nur OMDb. Jetzt beide Key-Arten (ist_v4_token + api_key-Query-Param lt. developer.themoviedb.org, mit Tests) — damit kommen auch die deutschen Texte an (language=de-DE war ueberall schon gesetzt). Neu: GET /metadata/status + 'Verbindung pruefen' in Einstellungen -> APIs (Live-Check am Cache vorbei). Features aus dem Commander-Feedback: - 4K UHD als eigener Disc-Typ: classify >= 55 GiB (BD-66/BD-100; BD-50 bleibt bluray), beide detection.py + Tests, eigene Badge-Farbe in Dashboard/Laufwerken, Prescan-Label '4K UHD'. UHD-Rip-Fehler 'Failed to open disc' (Code 11) bekommt Klartext: LibreDrive-Firmware noetig. - Vollautomatik (Setting autoRipStart): Disc erkannt -> Rip startet ohne Popup in den Schnellwahl-Ordner (Serie->Serien, sonst Filme, CD->Musik). - Job-Verwaltung: 'Neu komprimieren' nur noch mit can_retry (Rohdaten liegen wirklich da), DELETE /jobs/{id} + 'Erledigte aufraeumen' (Dateien bleiben immer), 'Alle herunterladen' im Job-Detail (gestaffelte Einzel-Downloads statt Server-Zip von 40-GB-Dateien). - Worker zuordenbar: WORKER_NAME-Env als stabiler Anzeigename (fixt auch die Offline-Leichen nach Rebuilds), info.hostname/ip gemeldet, Online-Abgleich ueber hostname, DELETE /workers/{name} + Papierkorb im UI, Quelle-Anzeige an der Disc-Karte ('Quelle: TMDB - 99 % sicher'). - Ripping-Tab nach Medium gegliedert (Video/Audio-CD/Allgemein) + Untertitel-Klartext (--all-audio/--all-subtitles bleiben komplett), CD -> Musik-Vorauswahl im Ziel-Dialog, Ordner-Verwaltung beschriftet und standardmaessig eingeklappt. - Docs: SAVEPOINT v3.3, ROADMAP Etappe 14 + Ideen (nativer Windows-Worker, deutsche OMDb-Texte via TMDB-Find), README. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 13:29:10 +02:00
HitonabiandClaude Fable 5	e032a9df1c	feat(backend): Media-Server-Aufbereitung, echte Webhooks, SMB-Klartext, UHD-Arbeitsverzeichnis, MakeMKV-Key via UI ... - jobs.meta (Migration in beiden db.py): Disc-Metadaten wandern in den Job — Quelle fuer Job-Detail-Popup (GET /jobs/{id}/detail), Ordner-Benennung, NFO. - medien.py (Worker, mit Tests): Zielordner 'Titel (Jahr)' statt Job-UUID; movie.nfo/tvshow.nfo (Kodi-Schema, kodi.wiki/view/NFO_files) + poster.jpg fuer jellyfin/emby/kodi; plex nur Benennung; Kollision -> Job-ID-Suffix. - notify.py (identisch in API+Worker, mit Tests): Webhook bei Job-Ende — Discord ({content}, discord.com/developers), Slack ({text}, api.slack.com/messaging/webhooks), ntfy (Rohtext + ?title=, docs.ntfy.sh), generisches JSON. Vorher war das Setting ein Placebo: nichts sendete je. POST /notifications/test beweist die Anbindung sofort. - mounts.py: NT_STATUS-Fehler -> handelbarer Klartext (ACCESS_DENIED ohne Credentials = Gast-Abfrage verweigert), Timeout-Meldung, mount-Hinweis bei error(13). Mit Tests. - tasks.py: Platz-Check per Disc-Groesse (ioctl BLKGETSIZE64) VOR dem Rip; Arbeitsverzeichnis workDir (unter /app/media, z.B. NAS) statt fix /app/temp/raw — 4K-UHD-Rohdaten (bis 100 GB) sprengen sonst die VM-Platte; MakeMKV-Key aus UI-Settings (~/.MakeMKV/settings.conf, Format wie entrypoint.sh) gilt ab dem naechsten Rip ohne Rebuild. - caps.py: Werkzeug-Versionen (MakeMKV aus ENV MAKEMKV_VERSION im Image, makemkvcon hat keinen --version-Schalter lt. usage.txt; HandBrakeCLI --version lt. handbrake.fr/docs) + Key-Quelle; workers.info-Spalte. - /browse liefert jetzt auch DATEIEN (Name + Groesse) — der 'leere' bluray-Ordner war voll, der Browser zeigte nur Unterordner. - GET /system/info: Versionen, Plattenplatz, Key-/Webhook-Status. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 08:55:22 +02:00
HitonabiandClaude Fable 5	b584cc29ad	Universal-Sprint: Wizard, UI-Mounts, Encoder-Erkennung, Task-Split, README ... Commander-Ziel: All-in-one, universell, weitergebbar. - First-Run-Wizard: startet automatisch bei neuer Installation (Keys, Verarbeitung, erkannte Hardware); /setup + /setup/complete - Data-Mounts via UI: Einstellungen -> Speicherziele haengt NFS/SMB direkt ein (mounts.py, CAP_SYS_ADMIN + rshared-Propagation, Auto-Remount beim Start, CIFS-Creds via Datei statt Kommandozeile); nfs-common/cifs-utils im api-Image - Encoder-Erkennung: jeder Worker meldet beim Start ehrlich seine Faehigkeiten (caps.py -> workers-Tabelle), GET /capabilities, Anzeige in Wizard + Verarbeitung-Tab - Task-Split: transcode_files als eigener Task auf Queue "transcode" (Basis fuer optionale Remote-GPU-Worker, deploy/remote-transcode-worker.yml EXPERIMENTELL) + POST /jobs/{id}/retry-transcode + UI-Knopf "Neu komprimieren" bei fehlgeschlagenen Jobs - API-Keys aus der DB: Settings-UI/Wizard ueberstimmen Env — vorher waren die Key-Felder im UI reine Dekoration (Clients lasen nur Env) - README komplett neu: generischer Schnellstart, Laufwerk-Override via docker-compose.override.yml, Architektur, Env-Tabelle Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-23 20:49:08 +02:00