62 Commits

Author	SHA1	Message	Date
Hitonabi	a221a161f4	feat: Tray-Icon fuer Worker GUI (pystray) — Fenster schliessen minimiert ins Tray	2026-07-26 22:33:54 +02:00
Hitonabi	9a151f3d8b	feat: Worker V2 Flet GUI mit Feature-Parität und neuem Installer	2026-07-26 22:01:27 +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
Hitonabi	d15900d1eb	fix(audio): nur die beste Tonspur pro Sprache verlustfrei kopieren	2026-07-26 20:55:57 +02:00
Hitonabi	96c400f2f2	fix(worker): erster Film in einer neuen Ablage war immer unerreichbar ... Im ersten vollstaendigen Durchlauf aufgefallen: Der Rip lief sauber durch (40 GB Akira, Marke rip_fertig sprang korrekt auf true), die Kompression brach 0,2 s spaeter ab mit "Dieser Worker erreicht die Ziel (fertige Datei) nicht: \\192.168.178.62\rippy\movies\Akira (1988)". Die Freigabe war erreichbar. Es fehlten zwei noch nie angelegte Ordner - movies und der Filmordner darin. Die Pruefung liess aber nur EINE fehlende Ebene durch (sie sah nach dirname), obwohl gleich darauf os.makedirs die ganze Kette anlegt. Damit war jeder ERSTE Film in einer neuen Ablage systematisch unerreichbar. Jetzt zaehlt, ob irgendein Vorfahre existiert (erster_vorhandener_ordner, begrenzt auf 12 Stufen, damit auf einer toten Freigabe nicht endlos geklopft wird). Zweiter Fehler in derselben Meldung: Sie behauptete "RIPPY_PATH_MAP ist gesetzt, deckt diesen Pfad aber nicht ab" - und nannte im selben Satz den korrekt uebersetzten UNC-Pfad. Wer dem folgte, suchte in der Karte statt in der Freigabe. Die Karte wird nur noch beschuldigt, wenn sie den Pfad wirklich nicht angefasst hat; sonst steht da, was zutrifft: uebersetzt, aber gerade nicht erreichbar. Dazu der Artikel-Fehler "erreicht die Ziel" behoben. Diese Pruefung hatte KEINEN einzigen Test - deshalb kam beides durch. Jetzt 12 (301 gruen). Beim Schreiben ist noch ein dritter Fehler aufgefallen: `isdir=os.path.isdir` als Vorgabewert bindet die Funktion beim IMPORT, ein Ersetzen geht danach ins Leere. Aufloesung jetzt beim Aufruf. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 17:43:51 +02:00
Hitonabi	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
Hitonabi	f7555a17d1	fix(zombies): die Fehlermeldung unterscheidet jetzt Rip von Kompression ... Nachtrag, direkt am echten Fall aufgefallen. Die Zombie-Erkennung hat den toten Rip gefunden (Beleg: nach 140 s noch "processing 12 %", nach 160 s "failed") - aber der Fehlertext sagte: "Die Rohdateien wurden NICHT geloescht: mit 'Neu komprimieren' laeuft die Kompression erneut, ohne die Disc noch einmal zu rippen." Der Satz war fuer einen toten TRANSCODE geschrieben, wo die Roh-MKV vollstaendig ist. Seit "running" mit zu den Arbeitsstati gehoert, traf er auch abgebrochene RIPS - und da ist er schlicht falsch: Die Datei ist ein Bruchstueck (im Vorfall 5,1 GB von rund 40), und wer dem Rat folgt, komprimiert einen Film, der bei 12 % aufhoert. Jetzt unterscheidet der Text die Phase: Rip tot -> "Der Rip war bei 12 % - die Roh-Datei ist UNVOLLSTAENDIG ... Richtig ist: Disc wieder einlegen und neu rippen." Transcode tot -> "Der Rip war fertig, nur die Kompression nicht ..." Die deutschen Anfuehrungszeichen haben dabei zum vierten Mal an einem Tag zugeschlagen (in DOPPELT gequoteten Python-Strings beendet das schliessende Zeichen den String). Die betroffenen Zeilen sind jetzt einfach gequotet, wie es der Bestand ohnehin macht. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 16:23:15 +02:00
Hitonabi	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
Hitonabi	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
Hitonabi	c171f8879c	feat(schluessel): der Windows-PC holt die 4K-Schluessel jetzt selbst ... Auf Commander-Entscheid gebaut. Belegt am 25.07.2026 auf beiden Maschinen: `makemkvcon` unter LINUX ruft Disc-Schluessel NIE ab, die WINDOWS-Version schon (Meldung 3338). Deshalb scheiterte jede unbekannte UHD-Disc auf der VM mit "The volume key is unknown", und der Weg, der funktioniert, war Handarbeit: Laufwerk an den PC, Disc oeffnen, _private_data.tar suchen, im UI hochladen. Das laeuft jetzt von selbst - und zwar ZWEISCHICHTIG, mit Absicht: 1. Der WAECHTER (verlaesslich): sieht _private_data.tar nach und laedt sie zu Rippy hoch, sobald sie sich geaendert hat. Braucht keine Laufwerkserkennung, kein Disc-Oeffnen, nichts geraten. Deckt auch den Fall ab, dass man die Disc einfach in der MakeMKV-Oberflaeche oeffnet. 2. Das ANSTOSSEN (nach bestem Wissen): liegt eine Disc im Laufwerk, wird `makemkvcon info` darauf losgelassen - dabei holt MakeMKV den Schluessel. Warum getrennt: Das Format der BELEGTEN `DRV:`-Zeile liess sich auf dem Commander-PC nicht messen, weil dort kein optisches Laufwerk steckt (alle 16 Plaetze melden `DRV:i,256,999,0,"","",""` - das ist gemessen). Geraten wird also nur in Schicht 2, und wenn die Vermutung falsch ist, passiert dort einfach nichts - Schicht 1 arbeitet weiter. Die teure Annahme steckt nie im verlaesslichen Teil. Gemessene Fundstellen: Datenverzeichnis ist `%USERPROFILE%\.MakeMKV` (NICHT %APPDATA%\MakeMKV, wie man vermuten wuerde) - dort lag die echte Datei mit 6.420.480 Bytes. Programm: C:\Program Files (x86)\MakeMKV\makemkvcon64.exe, v1.18.4. Hochgeladen wird mit ROHEM Koerper an POST /system/keystore, weil der API python-multipart fehlt. Die Automatik schaltet sich selbst ab, wenn MakeMKV nicht installiert ist: Auf einem reinen Encoding-PC gibt es nichts zu holen, und eine Schleife, die jede Minute ins Leere greift, waere nur Rauschen. Ihre Meldungen gehen ueber die Log-Bruecke auch nach Rippy - das ist genau die Auskunft, auf die man nach dem Einlegen einer neuen UHD-Disc wartet. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 15:14:52 +02:00
Hitonabi	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
Hitonabi	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
Hitonabi	87484d6863	feat(worker): der externe Worker wird erwachsen - Log in Rippy, Anzeige, Slots ... Commander 26.07.2026: "der externe Encoder Worker ist ein bisschen duenn - der koennte noch viel mehr." Drei Punkte, alle am Tray. 1. LOG IN RIPPY STATT TXT-DATEI (ausdruecklich gewuenscht). Das Tray schrieb sein Log nach %LOCALAPPDATA% und oeffnete es im Editor - wer wissen wollte, warum der Worker nichts tut, musste sich an den PC setzen. Neue Bruecke (logbruecke.py) meldet die wichtigen Zeilen nach Rippy, Quelle "w:<name>", und die Logs-Seite hat jetzt Knoepfe je Quelle: "was macht mein PC" ist ein Klick. Der Filter konnte Quellen schon immer, es gab nur keinen Knopf. Durchgelassen wird WENIG und mit Grund: Die Job-Meldungen stehen laengst in Rippy (tasks.py schreibt sie selbst). Es fehlte, was DANEBEN passiert und den Worker unbrauchbar macht, ohne dass ein Job existiert - hochgefahren oder nicht, Verbindung zu Redis/Postgres, Abstuerze. Alles andere fliegt weg: Celery ist bei --loglevel=info gespraechig, die logs-Tabelle hat keine Aufraeumung, und ein zugemuelltes Log ist so unbrauchbar wie keins. Dazu eine Drossel (30 Zeilen/Minute), die MELDET, wieviel sie verschluckt hat. Zeilenformat woertlich aus dem laufenden Container abgenommen (Celery 5.4.0). Die lokale Datei bleibt - sie ist genau dann die einzige Auskunft, wenn Rippy nicht erreichbar ist. 2. DAS TRAY ZEIGT, WAS LAEUFT. Vorher stand dort "laeuft" oder "gestoppt" - auf einer Maschine, die stundenlang an einem Film rechnet, ist das keine Auskunft. Jetzt Titel, Prozent und Restzeit, geholt von Rippys /jobs. Bewusst dieselbe Quelle wie das Dashboard, damit im Tray nicht eine zweite, abweichende Schaetzung steht. Dazu: Windows schlaeft nicht mehr mitten im Encode ein (SetThreadExecutionState, ohne ES_DISPLAY_REQUIRED - der Bildschirm darf ausgehen). Die Sperre wird zurueckgenommen, sobald nichts laeuft, und auch bei einem harten Ende des Trays - sonst schlaeft der PC nie wieder ein und niemand weiss warum. 3. MEHRERE ENCODES GLEICHZEITIG. Der Worker lief fest mit --pool=solo und nahm genau EINEN Auftrag an. Der Installer fragt die Zahl jetzt (GUI: Feld neben dem Namen, mit der erkannten Kernzahl daneben), Vorbelegung ab 12 Kernen zwei, sonst einer: HandBrake nutzt schon alle Kerne, aber x265 skaliert nicht linear. Auf Windows gibt es keinen prefork-Pool (kein fork) - deshalb --pool=threads, was hier passt, weil die Arbeit ein Kind-Prozess ist und der Thread nur wartet. GUI-Layout headless gerendert und angesehen (nichts ueberlappt, 16 Kerne korrekt erkannt), beide .ps1 mit echtem PowerShell 5.1 geprueft, BOM und CRLF erhalten, .exe neu gebaut. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 14:17:14 +02:00
Hitonabi	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
Hitonabi	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
Hitonabi	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
Hitonabi	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
Hitonabi	29444805a8	fix(build): der MakeMKV-Fallback der VM war seit Monaten tot - Kette jetzt dreistufig ... Beim Aufraeumen der VM-.env aufgefallen und nachgemessen (25.07.2026): https://www.makemkv.com/download HTTP 200 <- Repo-Standard https://www.makemkv.com/download/old HTTP 525 (Cloudflare) web.archive.org-Schnappschuss HTTP 404 <- stand in der VM-.env Die VM zeigte also auf eine KAPUTTE Adresse. Aufgefallen ist es nie, weil dort die vendor/-Tarballs liegen und der Download-Zweig gar nicht erreicht wird. Nimm die Tarballs weg, und jeder Bau scheitert mit 404 - waehrend die Konfiguration gesund aussieht. Genau diese Sorte Fehler ist bei einer Uebergabe teuer, weil sie erst beim Fremden zuschlaegt. ## Bereinigt (auf Commander-Wunsch, Sicherung liegt auf der VM) .env.sicherung-vor-aufraeumen-20260725 angelegt, dann: - MAKEMKV_URL_BASE raus -> es gilt der Compose-Standard, der liefert. Von Docker gegengeprueft: MAKEMKV_URL_BASE: https://www.makemkv.com/download - JWT_SECRET_KEY raus -> Ueberrest der in v3.4 ausgebauten Anmeldung, wirkungslos. ## Fallbacks BEHALTEN, aber echt gemacht (Commander-Vorgabe) Vorher war der "Fallback" eine Zeile, die man von Hand eintragen musste - und die hier ins Leere zeigte. Jetzt eine automatische Kette: 1. vendor/-Tarballs (braucht kein Netz, zuverlaessigster Weg) 2. MAKEMKV_URL_BASE 3. MAKEMKV_URL_FALLBACK (NEU, wird automatisch versucht wenn 2 versagt) Stufe 3 ist ABSICHTLICH leer vorbelegt. Es gibt derzeit keine belegbare zweite Quelle (siehe Messung oben), und eine einzutragen, die nicht liefert, waere schlimmer als keine - genau das lag auf der VM vor. Wer eine eigene Quelle hat (Spiegel im LAN), traegt sie ein und sie wird automatisch genutzt. Scheitert alles, nennt die Fehlermeldung jetzt die beiden Wege, die FUNKTIONIEREN, statt nur einen curl-Rueckgabewert zu hinterlassen. ## Geprueft, beide Zweige - vendor-Pfad: Bau durch, 828 MB - Download-Pfad: im FREMDEN Klon ohne Tarballs gebaut - Bau durch, 777 MB, makemkvcon liegt unter /usr/local/bin/. Die leere Fallback-Stufe wird korrekt uebersprungen, "Erste Quelle lieferte nicht" erschien nicht. docker compose config validiert. README und .env.example nennen die gemessenen HTTP-Antworten, damit niemand wieder eine 404-Adresse als Fallback eintraegt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-25 22:50:54 +02:00
Hitonabi	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
Hitonabi	65edf8369e	feat(worker-windows): Installation nach "Programme", Zielordner frei waehlbar ... Commander-Wunsch: nicht ins Benutzerprofil, sondern wie jedes andere Programm nach C:\Program Files - und selbst waehlbar, mit diesem Standard. ## Was neu ist - Feld "Installieren nach" mit Knopf "Aendern ..." (Ordner-Dialog). Standard ist [Environment]::GetFolderPath("ProgramFiles") + "Rippy Worker" - der ECHTE Pfad; deutsche Windows-Versionen zeigen im Explorer "Programme", der Pfad heisst trotzdem "Program Files". - Der Ordner-Dialog liefert den ELTERN-Ordner, "Rippy Worker" haengt der Installer selbst an. Sonst koennte die Deinstallation einen fremden Ordner mitloeschen - sie macht Remove-Item -Recurse auf das Zielverzeichnis. - install.ps1 bekommt -InstallDir mit demselben Standard. ## Drei Folgen, die mitbehandelt werden mussten 1. RECHTE. In C:\Program Files darf nur ein Administrator schreiben. Die .exe traegt jetzt ein requireAdministrator-Manifest (-requireAdmin in build-exe.ps1), fragt also beim Doppelklick EINMAL per UAC - danach stimmen die Rechte fuer alles Weitere. Verifiziert: "requireAdministrator" steckt im Manifest, "asInvoker" nicht mehr. Zusaetzlich prueft der Installer VOR dem Entpacken, ob er dort schreiben darf, und nennt bei Nein die zwei Wege (als Administrator starten ODER Ziel ins eigene Profil legen) - statt irgendwo tief "Zugriff verweigert" zu produzieren. 2. DAS LOG. tray.py schrieb worker.log NEBEN das Programm. Unter Program Files darf ein normaler Benutzer das nicht - der Worker waere beim Starten gescheitert, und zwar still. Das Log liegt jetzt in %LOCALAPPDATA%\Rippy Worker\worker.log, also da, wo veraenderliche Daten hingehoeren. Rueckfall auf das Programmverzeichnis bleibt fuer Installationen ins eigene Profil. 3. DER AUTOSTART. Bei einer Installation unter Programme ist es eine Installation FUER DIE MASCHINE - der Autostart geht deshalb in den Autostart-Ordner aller Benutzer (CommonStartup). Das loest zugleich ein Rechte-Problem: erhoeht man ueber ein FREMDES Administratorkonto, waere GetFolderPath("Startup") der Ordner dieses Admins, also der falsche. Bei einem Ziel im eigenen Profil bleibt es persoenlich. uninstall.ps1 raeumt beide Orte ab. ## Geprueft - Leerzeichen im Pfad: die erzeugte .bat mit cd /d "%~dp0", PATH-Erweiterung und relativem Aufruf laeuft aus "C:\...\Rippy Test Ordner" korrekt durch. - Alle drei .ps1 ASCII-rein und fehlerfrei geparst. - RippyWorkerSetup.exe neu gebaut (52736 -> 57344 Bytes, Version 1.0.1.0). UI: Der Copy-Paste-Befehl fuer den CLI-Weg sagt jetzt, dass PowerShell als Administrator laufen muss, und nennt -InstallDir als Ausweg ohne Adminrechte. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-25 22:20:50 +02:00
Hitonabi	6a17af2118	feat(transcode,ui): Kompression je Disc-Typ abwaehlbar + Wizard rechnet mit der CPU ... Loest die offene Frage aus dem Savepoint ("UHD gar nicht komprimieren?") und nimmt dem Wizard die Falle, in die er bisher fuehrte. ## Kompression je Disc-Typ abwaehlbar Bisher gab es nur den globalen Schalter transcodeEnabled: alles komprimieren oder nichts. Wer 4K verlustfrei behalten und DVDs trotzdem schrumpfen wollte, hatte keine Moeglichkeit - obwohl genau das die vernuenftige Einstellung fuer diese Maschine ist (4K-HEVC = gemessene 28-55 h je Film ohne AVX2). Jetzt kann das Preset eines Disc-Typs auf den Reservewert "keine" stehen, dann bleibt die verlustfreie Datei aus dem Rip stehen. Neue reine Funktion komprimieren_fuer(disc_type, einstellungen); der globale Schalter schlaegt weiter alles. preset_fuer() ueberspringt den Reservewert bewusst und gibt ihn NIE als Preset-Namen zurueck - sonst bekaeme HandBrake `--preset keine` und wuerde scheitern. Wer ueber "Neu komprimieren" ausdruecklich doch komprimieren will, bekommt so ein brauchbares Preset statt eines Fehlers. Der Reservewert kollidiert mit keinem echten Namen: gegengeprueft gegen alle 90 Presets aus `HandBrakeCLI --preset-list` im Worker-Image. Bei der Gelegenheit auch die fuenf im UI angebotenen Namen geprueft - alle echt. ## Der Wizard empfiehlt nach GEMESSENER Rechenleistung Vorher stand H.265 als Standard drin. Auf einer CPU ohne AVX2 sind das ein bis zwei Tage pro 4K-Film - genau der Lauf, der am 25.07.2026 abgebrochen werden musste. Der Wizard hatte die Zahlen sogar schon vorliegen (/capabilities meldet cpu_simd und cpu_kerne), nur benutzt hat er sie nicht. Jetzt: schwache CPU -> 4K wird nicht komprimiert, Blu-ray/DVD gehen auf H.264 (schneller als H.265). Starke CPU oder Hardware-Encoder -> H.265 durchgehend. Der Wizard schreibt dabei ALLE vier Preset-Felder, nicht nur das allgemeine - vorher fiel 4K auf ein 1080p-Preset zurueck und die Aufloesung war weg. Gewarnt wird nur, wenn es belegt ist: schwacheEncoderCpu() verlangt mindestens einen Worker mit BEKANNTER SIMD-Stufe und keinen mit Hardware-Encoder. Ein Windows-Worker meldet "unbekannt" (dort gibt es kein /proc/cpuinfo) - dann wird geschwiegen statt falsch gewarnt. Auf Windows gegengeprueft: 16 Kerne und CPU-Modell kommen korrekt durch, encoders ist ohne HandBrake leer. ## Weitere Wizard-Haerten - Kasten "Was Rippy gerade sieht": Laufwerk, Worker (mit Kernen/SIMD), freier Platz. Jede Zeile hat bei Problemen eine HANDLUNGSANWEISUNG statt nur eines Kreuzes - kein Laufwerk, kein Worker und wenig Platz sind die drei Faelle, in denen man vorher ratlos dastand. - Laedt alle drei Quellen parallel (Promise.allSettled) und wiederholt im 5-s-Takt: beim ersten Start laeuft der Worker noch hoch, vorher stand dort dauerhaft "Noch kein Worker gemeldet" ohne Aussicht. - API-Keys sind SICHTBAR statt als Punkte: das sind kopierte Keys, keine Passwoerter, und einen Tippfehler sieht man in Punkten nicht. - Keys werden direkt nach dem Speichern geprueft (/metadata/status). Ein falsch kopierter Key faellt sofort auf, statt erst beim ersten Rip als "Unknown Disc" - mit der Wahl "Key korrigieren" oder "Trotzdem fertigstellen". ## Einstellungen -> Verarbeitung Alle drei Preset-Auswahlen bekommen "Nicht komprimieren", und beim 4K-Feld erscheint die AVX2-Warnung mit der gemessenen Zahl - aber nur, wenn die Maschine sie wirklich braucht. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-25 21:48:31 +02:00
Hitonabi	8394de6926	fix(transcode): "Abbrechen" wirkt sofort statt erst beim naechsten Prozent ... Fund des Commanders am laufenden Akira-Job (Nachtrag im vorigen Savepoint): Job stand auf 'canceling', HandBrake lief weiter. Gemessen 3,4 Minuten zwischen Anforderung (18:30:17) und Bestaetigung (18:33:38) - bei langsamerem Fortschritt entsprechend mehr. Ursache genau wie dort beschrieben: Der Abbruch wurde nur in datei_fortschritt geprueft, und diese Closure stieg oben sofort wieder aus, wenn sich die Prozentzahl nicht geaendert hatte ("if gesamt == letzter[0]: return"). Bei einem Prozent je halber Stunde hing der Abbruch also an einem Ereignis, das eine halbe Stunde lang nicht eintrat. run_handbrake bekommt jetzt einen eigenen abbruch_cb neben progress_cb - dasselbe Muster, das run_makemkv schon fuer log_cb benutzt, und aus demselben Grund: der Fortschritts-Kanal verwirft Aufrufe. Er wird bei JEDER Ausgabezeile aufgerufen und im Worker auf 5 s gedrosselt. Nebeneffekt, der genauso wichtig ist: Er greift auch waehrend des Scan-Durchlaufs, der ueberhaupt keine Encode-Prozente liefert. Dort war ein Abbruch vorher grundsaetzlich unmoeglich - und seit die Prozent-Regex den Scan korrekt ignoriert, waere das sonst sogar schlimmer geworden. Die Leseschleife ist als _handbrake_schleife() herausgezogen, damit die Reihenfolge (Abbruch VOR Fortschritt) ohne echtes HandBrake pruefbar ist. Der Test belegt: zwei Scan-Zeilen genuegen fuer den Abbruch, es muss NICHT auf eine Encode-Zeile gewartet werden. Savepoint nachgezogen: Der Encode laeuft nicht mehr, ein Deploy ist gefahrlos moeglich, und die alte "SOFORT ENTSCHEIDEN"-Passage (Platte laeuft voll, wenn der Job fertig wird) ist damit gegenstandslos. Neu darin: die drei Wege fuer UHD, und die Warnung, dass eine /proc-Suche nach "HandBrake" die eigene Shell mittrifft - zwei Fehlalarme in dieser Sitzung. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-25 21:10:03 +02:00
Hitonabi	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
Hitonabi	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
Hitonabi	e0cb7b3ddc	feat(worker): Zombie-Erkennung - Jobs, an denen niemand arbeitet ... Nach einem Absturz oder Rebuild blieb ein Job auf 'transcoding' stehen, obwohl weder ein Prozess lief noch etwas in den Queues stand. Folge: keine Anzeige, kein Download - und der Knopf "Neu komprimieren" fehlte, weil _kann_neu_komprimieren (api/main.py) status=='failed' verlangt. Der Job war unerreichbar, obwohl die Rohdateien vollstaendig dalagen. zombies.py haelt beim Worker-Start die Jobs in 'ripping'/'transcoding'/ 'canceling' gegen Celerys active/reserved/scheduled und setzt sie ehrlich auf 'failed', wenn niemand daran arbeitet. Drei Sicherungen, weil ein falsch getoeteter Job teurer ist als eine stehengebliebene Leiche: - nur beim Start (da ist "es lief nichts" eindeutig; ein periodischer Lauf koennte einen Job erwischen, der legitim in der Warteschlange wartet) - 120 s Gnadenfrist (Celery stellt unbestaetigte Aufgaben erneut zu) - Vollzaehligkeit: antworten weniger Knoten als laut Herzschlag online sind, wird NICHTS gewertet - sonst waere der laufende Job eines beschaeftigten Remote-Workers eine falsche Leiche Die Job-ID wird per Textsuche ueber die Inspektions-Antwort gefunden, nicht per Position: sie steht bei rip_disc an zweiter, bei transcode_files an erster Stelle, und Celery liefert args je nach Version als Liste oder Text. 13 Tests ohne Postgres/Redis, darunter "laufender Job wird nicht angetastet" und "schweigender Worker verhindert jedes Urteil". Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-25 21:04:19 +02:00
Hitonabi	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
Hitonabi	c065967f4d	fix(ui,transcode): Dialog-Falle, Arbeitsverzeichnis waehlbar, Original-Aufheben entschaerft ... Drei Befunde aus dem ersten echten UHD-Durchlauf (Akira). Der Rip und die Kompression liefen sauber durch - danach hat "Original behalten" die Platte vollgeschrieben und den fertigen Job als fehlgeschlagen markiert. 1. ORIGINAL-AUFHEBEN DARF DEN JOB NICHT MEHR TOETEN (tasks.py) Vorher stand dort ein nacktes shutil.move(raw_dir, ziel). Arbeits- verzeichnis (/app/temp, Docker-Volume) und Ziel (/app/media, Bind-Mount) sind VERSCHIEDENE Dateisysteme - os.rename scheitert mit EXDEV, shutil.move faellt auf Kopieren zurueck. Ergebnis am 25.07.: 74-GB-Vollkopie auf dieselbe Platte, Abbruch bei 41 GB mit ENOSPC, Platte 100 % voll, Worker- Container startete nicht mehr ("failed to mount: no space left on device"), und der Job galt als FEHLGESCHLAGEN - obwohl die komprimierte Datei (4,8 GB) fertig und in Ordnung war. Der Nutzer sah nur eine leere Queue. Jetzt: _original_aufheben() prueft erst, ob ueberhaupt kopiert werden muss (gleiches Dateisystem -> reines Umhaengen), prueft sonst den freien Platz VORHER, faengt jeden OSError ab, raeumt eine halbe Kopie weg und meldet das als WARNUNG. Der Job bleibt erfolgreich, die Roh-Datei bleibt liegen. Zwei Tests decken beide Wege ab. 2. ARBEITSVERZEICHNIS IST JETZT WAEHLBAR (Settings.tsx) Es war ein freies Textfeld - man musste den Container-Pfad (/app/media/...) KENNEN, um eine Netzwerk-Freigabe zu treffen. Genau daran ist es gescheitert, weshalb der 74-GB-Rohschnitt ueberhaupt erst auf der VM-Platte landete. Jetzt eine Auswahl aus /storage-targets (dieselbe Liste wie bei den Speicherzielen), inklusive Kennzeichnung als Netzwerk-Freigabe und freiem Platz je Ziel. 3. DIALOGE KLEBTEN IM PANEL (ui/Modal.tsx) "Rippen starten" im Laufwerke-Tab oeffnete den Dialog INNERHALB des Bereichs, teils abgeschnitten. Ursache: .glass-panel in index.css setzt backdrop-filter: blur(16px), und ein Element mit backdrop-filter wird zum Bezugsrahmen fuer position: fixed seiner Nachfahren - das Modal war damit an der Card ausgerichtet statt am Fenster. Modal rendert jetzt per createPortal an document.body. Behebt es fuer ALLE Dialoge auf einmal. Aufgeraeumt: die abgebrochene 41-GB-Teilkopie unter "/app/media/movies/Akira (1988)/original/" geloescht (nachweislich unvollstaendig - 41 GB gegen 79,6 GB Quelle, Quelle intakt). Platte wieder bei 78 %, Container laufen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-25 19:48:10 +02:00
Hitonabi	e84afc1718	feat(transcode): ein HandBrake-Preset je Disc-Typ statt eines fuer alles ... Rueckfrage des Commanders beim ersten echten UHD-Rip: "merkt Rippy, dass es eine UHD ist, und nimmt direkt das 4K-Preset?" Antwort war nein. Die Kompression fragte den Disc-Typ ueberhaupt nicht: preset = einstellungen.get("transcodePreset") or DEFAULT_HB_PRESET Live eingestellt war "HQ 1080p30 Surround". Der gerade laufende Akira-Rip waere also verlustfrei in 4K gerippt und danach auf 1080p heruntergerechnet worden - und mit keepOriginal=False waere der 4K-Rohschnitt danach geloescht worden. Umgekehrt wurde eine DVD auf 1080p hochskaliert, was nichts bringt. - preset_fuer(disc_type, einstellungen) in ripping.py, pure und getestet. Reihenfolge: Preset des Disc-Typs -> allgemeines transcodePreset -> DEFAULT_HB_PRESET. Bestandsinstallationen aendern ihr Verhalten NICHT, solange die neuen Felder nicht gespeichert sind. - Drei Einstellungen: transcodePresetDvd / transcodePresetBluray / transcodePresetUhd. transcodePreset bleibt als Rueckfall bestehen. - transcode_files holt den Disc-Typ aus dem Job-Datensatz und schreibt ihn mit ins Log ("Disc-Typ 'uhd', Preset '...'"). - UI: drei Auswahlfelder statt einem, mit Klartext dazu, warum eine 4K-UHD auf ein 2160p-Preset gehoert. Preset-Namen stammen aus "HandBrakeCLI --preset-list" im Worker-Image (HandBrake 1.6.1) - nicht aus dem Kopf (AGENTS Regel D): H.265 MKV 2160p60 4K, HQ 2160p60 4K HEVC Surround, Super HQ 2160p60 4K HEVC Surround, H.265 MKV 1080p30, HQ 1080p30 Surround, Super HQ 1080p30 Surround, H.265 MKV 576p25, H.265 MKV 480p30, HQ 576p25 Surround. Sofortmassnahme am laufenden Job (auf Ansage des Commanders): keepOriginal auf True gesetzt - nur dieses eine Feld, gegengeprueft dass kein anderer Schluessel veraendert wurde. Damit ueberlebt der 4K-Rohschnitt die Kompression. ACHTUNG - Deploy bewusst NICHT ausgefuehrt: docker compose up -d --build wuerde den Worker-Container neu erstellen und den laufenden Akira-Rip abbrechen. Erst nach Abschluss des Jobs deployen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-25 11:38:52 +02:00
Hitonabi	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
Hitonabi	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
Hitonabi	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
Hitonabi	404a002d5c	Windows-Worker: Tray-Symbol + rueckstandsfreie Deinstallation ... - tray.py (nur nativer Windows-Worker; Docker unberuehrt): pystray+Pillow- Tray neben der Uhr — Status, Worker starten/stoppen, Rippy oeffnen, Log anzeigen, Beenden (stoppt den Worker mit). Celery laeuft als Kind-Prozess ohne Konsolenfenster (CREATE_NO_WINDOW), Log in worker.log. - install.ps1 erzeugt jetzt start-tray.bat (pythonw, empfohlen), start-worker.bat (Konsole/Debug) und uninstall.ps1: stoppt alle Prozesse aus dem Ordner, loescht die Autostart-Aufgabe, meldet den Worker per DELETE /workers/{name} in Rippy ab und entfernt den Ordner komplett. -Autostart registriert die Tray-Variante (onlogon). - UI-Beschreibung + Anleitung entsprechend ergaenzt. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 15:44:29 +02:00
Hitonabi	76b4286ad3	Windows-Worker: Pfad-Mapping fuer echte Transcodes + leere-Titel-Meldung + E2E-Beweis dokumentiert ... - pfad_lokal (tasks.py, mit Tests): RIPPY_PATH_MAP uebersetzt Container-Pfade (/app/temp, /app/media) auf Netzlaufwerke des nativen Workers — ohne Mapping unveraendert (Docker-Worker). - Rip-Dialog: 'done' mit 0 Titeln bekommt Klartext (Disc vermutlich nicht entschluesselbar) statt leerer Tabelle. - SAVEPOINT: E2E-Beweis des nativen Windows-Workers dokumentiert (test-windows-nativ online, HandBrake 1.9.2, echte LAN-IP). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 15:29:56 +02:00
Hitonabi	3a4eb25392	Track-Auswahl-Tabelle, nativer Windows-Worker (via UI angeboten), Anleitungs-Tab ... Volle Titel-Auswahl vor dem Rip (Etappe-12-Rest): - worker.tasks.scan_tracks: makemkvcon info -> Titel-Liste (Dauer/Groesse/ Kapitel, apdefs-Attr 8/9/11) in die settings-Tabelle 'tracks:<device>'; API: POST /devices/{n}/scan-tracks + GET /devices/{n}/tracks (Polling). - Rip-Dialog: 'Disc scannen' -> Tabelle mit Checkboxen, Vorauswahl ab 5 min, Groessen-Summe; gewaehlte Titel als meta.titles in den Job. - rip_titel_auswahl: ein makemkvcon-Aufruf je Titel (mkv kann nur einen Titel oder all), Fortschritt anteilig. Parser-Tests dabei. Nativer Windows-Worker OHNE Docker (Commander-Wunsch): - Die Rippy-Instanz versorgt sich selbst: GET /worker-setup/windows liefert install.ps1, /worker-setup/paket den Worker-Code als Zip (api-Dockerfile kopiert docker/worker/*.py als worker_dist/ ins Image). - install.ps1: Python-Check, venv + requirements, HandBrakeCLI 1.9.2 vom offiziellen GitHub-Release (URL per HEAD verifiziert), start-worker.bat mit celery -Q transcode --pool=solo (Celery-Doku: Windows nur solo), optional -Autostart via schtasks onlogon. - tasks.py laedt jetzt auch ohne fcntl (Import-Guard) — rip_disc ist auf solchen Workern hart verriegelt (Klartext-Fehler statt Crash). - Einstellungen -> Worker: Varianten-Umschalter Linux(Docker)/Windows(nativ) mit passenden Copy-Paste-Befehlen. Anleitungs-Tab: Rippy erklaert sich selbst (Disc-Weg, Serien, NAS, Media-Server, Benachrichtigungen, Key, Worker, Downloads, FAQ). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 15:18:08 +02:00
Hitonabi	325d95af6f	build(worker): lokale MakeMKV-Tarballs (vendor/) schlagen den Download ... Cloudflare drosselt BuildKit-Downloads von makemkv.com hartnaeckig (24.07. viermal, auch MIT --retry-all-errors, waehrend dieselben URLs ausserhalb des Builds laden). Dauerhafter Ausweg statt Mirror-Hack: Tarballs einmal nach docker/worker/vendor/ legen (untracked, .gitignore) — der Build nutzt sie dann direkt und faellt sonst auf curl+Retry zurueck. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 14:26:24 +02:00
Hitonabi	8eb5653848	Restefeger: Auth komplett raus, Serien-Flow + Episoden-Matching, Jellyfin-Refresh, Duplikat-Warnung, echtes Nur-Hauptfilm ... AUTH ENTFERNT (Commander-Entscheid 24.07., KONZEPT §10): /token- und /api-keys-Endpoints, auth.py, test_auth.py, passlib/bcrypt/PyJWT/ python-multipart, JWT_SECRET_KEY-Pflicht. Heimnetz-only, das UI hatte nie einen Login — die Auth-Oberflaeche war Placebo und die passlib/bcrypt- Falle brach die Ampel. Rate-Limit pro IP bleibt. Schnellstart laeuft jetzt ganz ohne .env-Pflichtwerte. Serien-Flow (Etappe-12-Kern, ARM-Wunde #395): - Rip-Dialog: Serienname + Staffel -> Ablage <Serie>/Season NN (jellyfin.org/docs Naming-Schema); tvshow.nfo + poster.jpg im Serien-Ordner, bei Staffel 2 nicht ueberschrieben. - Episoden-Matching per Laufzeitabgleich: HandBrakeCLI --scan ('+ duration:', handbrake.fr/docs) je MKV gegen TMDB-Staffel-Laufzeiten (GET /metadata/tv/{id}/season/{n}; tv-season-details-API). Ordnungserhaltend; komplette Staffel auf einer Disc klappt auch bei uniformen Anime-Laufzeiten (Sequenz-Stufe). Umbenannt wird NUR bei eindeutiger Zuordnung — sonst ehrliches Log. Mit Tests. Weitere Punkte: - Jellyfin/Emby-Bibliotheks-Refresh nach jedem fertigen Rip (POST /Library/Refresh, X-Emby-Token lt. jellyfin.org/docs) — URL/Key + Test-Knopf in Einstellungen -> Ripping. - Duplikat-Warnung: Disc-Fingerabdruck (jetzt Teil des Prescan-Ergebnisses + der Job-Metadaten) gegen die Historie; Karte zeigt 'bereits gerippt', Vollautomatik ueberspringt Duplikate. - 'Nur Hauptfilm' ECHT: makemkvcon info -> TINFO-Attr-9-Laufzeiten (usage.txt) -> laengster Titel -> mkv dev:X <nr>. Vorher wirkungsloses Setting; pro Rip im Dialog uebersteuerbar. Mit Tests. - OMDb-Treffer eingedeutscht via TMDB /find (external_source=imdb_id, de-DE; find-by-id-API). - Dashboard: Speicherplatz-Anzeige (amber < 60 GB) + CSV-Export (GET /jobs/export, Semikolon+BOM fuer deutsches Excel). - Metadaten-Seite entfernt (Abnahme durch Commander-Auftrag) inkl. Placebo-Endpoints /metadata/lookup (scannte Dummy-Device) und /metadata/confirm (schrieb nie gelesenen Cache-Key). - Doppel-Jahr-Fix: 'X (2009) (2009)' in Log und Ordnernamen. - Remote-Worker-Blocker: redis (6379) + postgres (5432) waren NIE veroeffentlicht — kein Remote-Worker konnte sich je verbinden. Ports jetzt offen (Heimnetz-Kompromiss, kommentiert) + API_URL fuer Worker. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 14:22:19 +02:00
Hitonabi	e7a7d5fdb4	build(worker): MakeMKV-Download mit Retry + dokumentierter Lokal-Mirror-Ausweg ... Cloudflare drosselte am 24.07. wiederholt GENAU die BuildKit-Downloads (ausserhalb des Builds gingen dieselben URLs mit 200 durch) — drei Deploy-Anlaeufe starben an curl exit 22. Zwei Gegenmittel: - curl --retry 5 --retry-delay 15 --retry-all-errors im Download-RUN (curl-Doku; --retry-all-errors wiederholt auch bei 4xx/5xx) - Lokal-Mirror-Rezept im Kommentar: Tarballs von Hand laden, per nginx:alpine servieren, MAKEMKV_URL_BASE aufs LAN zeigen — so wurde der 1.18.4-Build auf der VM letztlich gebaut. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 13:54:37 +02:00
Hitonabi	c9270d08e1	MakeMKV 1.18.4 + UHD-Fehler-Ursachen im Klartext (Laufwerk ist geflasht — Disc-Key war das Problem) ... Diagnose auf der VM (Summer-Wars-UHD, MKB v82): - 'Using LibreDrive mode (v06.3)' — der BU40N-Crossflash IST erledigt, das Laufwerk liest UHD. Der Fehlschlag kam von 'The volume key is unknown for this disc': die Disc ist neuer als MakeMKVs Schluessel-Datenbank — mit 1.17.7 UND der aktuellsten 1.18.4 bewiesen (beide Versionen live gegen die Disc getestet). Konsequenzen: - MakeMKV-Pin von 1.17.7 auf 1.18.4 gehoben: der 1.18er Scan-Haenger (Forum t=38128) wird ueberall mit --noscan umgangen (info-Lauf mit 1.18.4 auf der BU40N sauber durchgelaufen), die Flash-Faehigkeit von 1.17.7 wird nicht mehr gebraucht. Aktuelle Version = aktuellste AACS-Key-DB. URL-Base -> /download (dort liegt nur die aktuelle). - run_makemkv reicht KRITISCHE Meldungen (volume key unknown, Key abgelaufen, too old version) in den Fehlertext durch — vorher stand da nur die nichtssagende letzte Zeile 'Failed to open disc'. - UHD-Klartext in tasks.py unterscheidet jetzt die zwei Faelle: volume-key-unknown (MakeMKV/Disc-Alter, AACS-Dump aus /root/.MakeMKV/ im MakeMKV-Forum einreichen) vs. Failed-to-open ohne LibreDrive (Firmware-Hinweis). - SAVEPOINT: Flash-Status korrigiert (war als offen dokumentiert). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 13:44:42 +02:00
Hitonabi	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
Hitonabi	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
Hitonabi	6517644d1f	Dashboard-Korrektur-Popup, Worker-Tab mit Live-Ping, Herzschlag, Anzeige-Fixes ... Commander-Wuensche (23.07. Nacht): - "Nicht korrekt?!"-Knopf direkt an der Disc-Karte: Korrektur-Suche als Popup (MetadataKorrektur) — kein Seitenwechsel mehr noetig; Wahl gilt per Disc-Fingerabdruck weiter 30 Tage - Einstellungen -> Worker: verbundene Encoding-Maschinen mit ECHTER Erreichbarkeit (Celery-Ping + minuetlicher Herzschlag/last_seen), Encoder-Badges, Copy-Paste-Anbindung fuer neue Maschinen (Linux/Docker + Docker Desktop; SSH-Ein-Klick als Ausbaustufe) - JSX-0-Falle gefixt: {0 && ...} renderte nackte "0" unter GENRE/LAUFZEIT - ruff.toml: Regelsatz gepinnt — lokal aktualisierte Ruff-Version zog ploetzlich Stilregeln und faerbte den Baum rot; Ampel und lokal urteilen jetzt identisch Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 08:18:44 +02:00
Hitonabi	07be54e62a	Jikan/MAL-Quelle + Job-Titel + Abbrechen-Knopf + Dark-Hover + Ordner-Verwaltung ... Commander-Befunde (Screenshots 23.07. abends): - Jikan (MyAnimeList, kostenlos OHNE Key) als Anime-Quelle vor OMDb — waehlt per Titel-Aehnlichkeit (SequenceMatcher, Schwelle 0.55) statt blind Treffer 1; damit trifft "Evangelion 2.22" den exakten Film - Job-Titel: POST /jobs uebernimmt den erkannten Disc-Titel aus dem DISC_CACHE — Schluss mit "Unbekannt" in der Queue - Kooperativer Job-Abbruch: POST /jobs/{id}/cancel setzt canceling, der Worker prueft das Flag bei jedem Fortschritts-Update und killt den Encoder-Prozess sauber (RipAbbruch); UI-Knopf "Abbrechen" fuer laufende, Status-Badge "Wird abgebrochen" - Dark-Mode: Job-Zeilen-Hover war hart hell (hover:bg-slate-50) - Speicherziele: lokaler Ordner-Browser mit "Ordner anlegen" (GET /browse + POST /browse/mkdir, nur unter /app/media) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-23 21:22:57 +02:00
Hitonabi	7652afe955	Deploy-Befunde gefixt: Disc-Typ-Verlust, giftiger Prescan-Cache, caps-Import ... - Pre-Scan verlor den erkannten Typ (BDs hiessen immer "DVD"): scan() reicht disc_type jetzt in die Zweige durch - GIFTIG: Cache-Key nur aus Geraetepfad — die naechste Disc im selben Laufwerk haette die Metadaten der vorherigen geerbt. Key enthaelt jetzt einen Disc-Fingerabdruck (Label|Groesse) - Worker-Faehigkeiten: import caps auf Modulebene — im worker_ready-Signal war /app nicht mehr im sys.path (ModuleNotFoundError im Deploy-Log) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-23 20:54:14 +02:00
Hitonabi	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
Hitonabi	dfef585ec8	Speicherziel-Wahl: Rip-Ziel pro Job frei waehlbar (Etappe 16 / Task 16) ... - POST /jobs nimmt target_dir (validiert unter /app/media, .. fliegt raus) - GET /storage-targets: Verzeichnisse unter /app/media inkl. Mount-Flag und freiem Platz — NFS/SMB-Shares unter /srv/rippy/media erscheinen dank rslave-Bind automatisch - jobs.target_dir (Mini-Migration via ADD COLUMN IF NOT EXISTS) - Worker: rip_disc(target_dir) mit eigener Validierung; CD/Video/ Transcode-Pfade legen im gewaehlten Ziel ab - UI: "Rippen starten" oeffnet den Ziel-Dialog (Filme/Serien/Musik oder eigener Pfad); Modal-Bugfix: customPath wurde still ignoriert Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-23 16:20:36 +02:00
Hitonabi	2474b683e2	Transcode-Stufe: HandBrake komprimiert NACH dem MakeMKV-Rip + --noscan-Fix ... Commander-Entscheid 23.07.: 40-GB-Rohdateien sind kein brauchbares Endprodukt. Architektur bleibt zweistufig, weil HandBrake AACS nicht lesen kann: MakeMKV rippt verlustfrei nach /app/temp/raw, HandBrake macht daraus x265 auf Arbeitsgroesse in /app/media, Roh-Verzeichnis wird erst NACH komplettem Erfolg geloescht (keepOriginal behaelt es). - Worker: handbrake-cli im Image, run_handbrake + _komprimiere, Job-Status "transcoding", Settings aus Postgres (transcodeEnabled/ Preset/keepOriginal), Fortschritt je Datei aggregiert - makemkvcon: --noscan im Kommando verankert — der Geraete-Scan haengt (1.18.4) bzw. crasht (1.17.7) im Container, mit --noscan + dev:-Pfad laeuft es (Befund 23.07., DRV-Zeile beweist Laufwerks-Erkennung) - UI: Settings-Tab "Verarbeitung" (Toggle/Preset/Original behalten), Status-Badge "Komprimieren", LiveLog erkennt transcoding als aktiv - KONZEPT/ROADMAP entsprechend aktualisiert; Tests fuer HandBrake-Cmd (arbeitet auf DATEI, nie am Geraet) und Progress-Regex Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-23 15:56:37 +02:00
Hitonabi	009898efae	MakeMKV auf 1.17.7 gepinnt — 1.18.x haengt unter Linux beim Laufwerks-Scan ... Bei uns reproduziert (100% CPU, keine Ausgabe, auch mit sg-Knoten), im MakeMKV-Forum vielfach bestaetigt (t=38128, t=38239, t=38249); Community- Workaround ist 1.17.7. Bonus: exakt die Version, die spaeter die Firmware flashen kann. MAKEMKV_URL_BASE als Build-Arg, weil makemkv.com gerade per Cloudflare-525 down ist (Wayback-Snapshot als Ausweichquelle); sha256 der Tarballs wird im Build-Log festgehalten. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-23 15:39:56 +02:00
Hitonabi	4aa237541f	Fix: makemkvcon landete in /usr statt /usr/local — COPY nahm es nie mit ... Deploy-Befund 23.07.: Image frisch gebaut, GPL-Teile da, aber makemkvcon fehlte — makemkv-bin installiert ohne PREFIX nach /usr, die Final-Stage kopiert nur /usr/local. Jetzt PREFIX=/usr/local + test -x als Build-Beweis. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-23 15:14:14 +02:00
Hitonabi	780d114fe4	Etappe 10: Worker rippt wirklich — MakeMKV 1.18.4 + ioctl-Disc-Erkennung ... Vorher: Dockerfile unbaubar (makepkg ist ein Arch-Paket, existiert in Debian nicht) und KEIN einziges Ripping-Tool im Image — jeder Rip endete sofort. Disc-Erkennung via `file -L` konnte auf Block-Devices strukturell nie etwas erkennen; ihr Test mockte sich die Ausgabe passend. - makemkv-oss/bin 1.18.4 multi-stage (bookworm-gepinnt), EULA via tmp/eula_accepted, Beta-Key aus MAKEMKV_APP_KEY (entrypoint.sh) - makemkvcon-Aufruf + PRGV-Parsing laut makemkv.com/developers/usage.txt (AGENTS Regel D), HandBrake raus aus dem Ripp-Pfad (KONZEPT: lossless=Muss) - detection.py: CDROM_DISC_STATUS + BLKGETSIZE64 (cd/dvd/bluray), pure classify() mit ehrlichen Tests - tasks.py: rip_disc als einziger Celery-Task, schreibt Status/Fortschritt nach Postgres (db.py), Ausgabe auf /app/media (Volume) statt totem /output Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-23 15:02:13 +02:00
Hitonabi	3e88c328db	fix(worker): remove pyudev (needs libudev-dev, not in slim image)	2026-07-23 12:27:21 +02:00