6 Commits

Author	SHA1	Message	Date
Hitonabi	aea26493db	feat(installer): der Windows-Installer holt die Freigabe jetzt selbst von Rippy ... DER BLOCKER aus dem SAVEPOINT v3.16 ist zu. Beide Installer (Kommandozeile und GUI) fragen GET /worker-setup/pfad-map, pruefen mit Test-Path, ob DIESER PC die Freigabe wirklich erreicht, und schreiben `set RIPPY_PATH_MAP=...` in start-tray.bat und start-worker.bat. Der Commander muss dafuer nichts ueber Container-Pfade wissen - das Feld bleibt leer, der Installer holt den Wert. Von Hand geht es trotzdem (Knopf "Von Rippy holen" bzw. -PfadMap), falls dieser PC die Freigabe anders erreicht. Ist nichts erreichbar, steht das als Klartext im Log samt dem haeufigsten Grund (fehlende Zugangsdaten - Freigabe einmal im Explorer oeffnen). Die Installation laeuft weiter: ein Worker, der sich meldet und ehrlich scheitert, ist besser als einer, der nicht existiert. Ein LEERES RIPPY_PATH_MAP wird bewusst nicht gesetzt - pfad_lokal() liest das als "kein Mapping", und die Fehlermeldung im Worker unterscheidet genau diese beiden Faelle. GUI: neues Feld samt Knopf, Fenster 560->648 px. Layout headless gerendert und angesehen (nichts ueberlappt, Umlaute korrekt), beide Dateien mit echtem PowerShell 5.1 auf Parser-Fehler geprueft, UTF-8-BOM erhalten. .exe neu gebaut. install.ps1 hatte durch ein Werkzeug LF statt CRLF bekommen - zurueckgedreht. remote-transcode-worker.yml richtiggestellt: Dort stand "mount -t nfs <rippy-host>:/srv/rippy" - das geht NICHT, auf der Rippy-Maschine laeuft kein NFS- und kein Samba-Server, sie ist selbst nur Client der NAS. Der Weg, der funktioniert: dieselbe Freigabe einhaengen, die auch Rippy nutzt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 12:58:23 +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	8f208ed0da	fix(worker-windows): Autostart brach die ganze Installation ab ... Beim Commander live aufgetreten: Der Installer meldete "FEHLER: FEHLER: Zugriff verweigert" samt dem Tipp, die IP koenne falsch sein - und das, NACHDEM Worker-Code, Abhaengigkeiten und HandBrake schon fertig waren. Die IP war also nie das Problem. URSACHE: schtasks /create mit /tn "RippyWorker" legt die Aufgabe im WURZELORDNER der Aufgabenplanung an, und das verlangt Administratorrechte. Der Installer laeuft normal ohne. schtasks schrieb "FEHLER: Zugriff verweigert." nach stderr, und weil im Skript $ErrorActionPreference = "Stop" steht, machte PowerShell daraus einen TERMINIERENDEN Fehler - der catch-Block riss damit die komplette Installation ab, obwohl nur der Autostart fehlte. Das doppelte "FEHLER: FEHLER:" war der Hinweis: der aeussere Handler setzt sein Praefix vor eine Meldung, die selbst schon mit "FEHLER:" begann, also aus schtasks kam. FIX, zwei Teile: 1. Autostart ueber den Autostart-ORDNER statt schtasks. Eine Verknuepfung in [Environment]::GetFolderPath("Startup") braucht NIE Adminrechte - und der Nutzer kann sie dort selbst sehen und loeschen. Auf diesem Windows-PC gegengeprueft: Verknuepfung angelegt (1047 Bytes) mit Admin=False. 2. Ein Fehlschlag beim Autostart ist jetzt eine WARNUNG in eigenem try/catch, kein Abbruch. Der Worker ist zu dem Zeitpunkt fertig und startbar, und der Text sagt das auch - plus den Handweg (shell:startup). In BEIDEN Installern (install-gui.ps1 und install.ps1, dort mit -Autostart) - der CLI-Weg hatte denselben Fehler. uninstall.ps1 raeumt jetzt die Verknuepfung weg UND versucht weiter schtasks /delete, damit aeltere Installationen sauber verschwinden. RippyWorkerSetup.exe neu gebaut (50688 -> 52736 Bytes): die GUI ist in der .exe eingebettet, ohne Rebuild wirkt der Fix beim Nutzer nicht. Nebenbei: build-exe.ps1 hatte zwei Gedankenstriche. Ausgelieferte .ps1 muessen reines ASCII sein (PowerShell 5.1 liest sie als ANSI) - jetzt sind alle drei Skripte ASCII-rein und parsen fehlerfrei. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-25 22:11:39 +02:00
Hitonabi	b1d9ece9b2	feat(installer): kein Konsolenfenster (.vbs-Starter) + Rippy-Icon im Installer-Fenster ... Commander-Wunsch: kein Konsolenfenster + Icon. - Starter ist jetzt eine .vbs (statt .bat): wscript startet PowerShell mit Fensterstil 0 = KOMPLETT versteckt, kein Konsolenfenster. Nur das WinForms-Installer-Fenster erscheint. Download-Datei: rippy-worker-setup.vbs (weiter CLIENT-seitig mit eingetragener LAN-IP erzeugt). - install-gui.ps1: Fenster-Icon = Rippy-Disc (zur Laufzeit gezeichnet, Indigo-Kreis + weisses Loch) — erscheint in Titelleiste + Taskleiste. (Die Datei selbst kann Windows-bedingt kein Icon tragen — nur .exe/.lnk.) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 19:03:19 +02:00
Hitonabi	4fb29d16cf	feat(worker): grafischer Windows-Installer (GUI statt CLI) ... Commander-Wunsch: die CLI-Installation ist grausam. Jetzt: - install-gui.ps1 (WinForms, ASCII-only): Fenster mit Feldern (Rippy-IP, Worker-Name, Autostart-Checkbox), Install-Knopf mit Live-Log, danach 'Worker starten'-Knopf. Gleiche Schritte wie der CLI-Installer (Worker-Code + HandBrake latest + venv + Tray/Start/Uninstall). Braucht nur Python 3.10+, keine externe GUI-Runtime. - API: GET /worker-setup/windows-gui serviert die GUI; Dockerfile kopiert sie ins worker_dist/. - UI (Worker-Tab, Windows): 'Grafischen Installer herunterladen (.bat)' als Haupt-Weg — die .bat wird CLIENT-seitig mit der eingetragenen LAN-IP erzeugt (Blob-Download), Doppelklick laedt+startet die GUI von Rippy. Der CLI-Befehl bleibt als Profi-Alternative. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 18:47:57 +02:00