rippy

Hitonabi/rippy

Fork 0

Commit Graph

Author	SHA1	Message	Date
Hitonabi	87484d6863	feat(worker): der externe Worker wird erwachsen - Log in Rippy, Anzeige, Slots Ampel / ampel (push) Successful in 28s Details 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 Ampel / ampel (push) Successful in 28s Details 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 Ampel / ampel (push) Successful in 27s Details - 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

Author

SHA1

Message

Date

Hitonabi

87484d6863

feat(worker): der externe Worker wird erwachsen - Log in Rippy, Anzeige, Slots

Ampel / ampel (push) Successful in 28s

Details

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

Ampel / ampel (push) Successful in 28s

Details

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

Ampel / ampel (push) Successful in 27s

Details

- 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

3 Commits