5 Commits

Author	SHA1	Message	Date
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	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	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	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