5 Commits

Author	SHA1	Message	Date
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	ee123f2a90	fix(install): Paketbefehl je Distribution statt stur apt ... Commander-Frage: "Was wenn der Unterbau nicht Debian ist?" Berechtigt - bei fehlendem Compose nannte install.sh stur `sudo apt install docker-compose-plugin`. Auf Arch, Fedora oder openSUSE ist das ein Befehl, den es nicht gibt. Erkannt wird ueber das VORHANDENE Paketwerkzeug (apt-get/dnf/yum/pacman/zypper/ apk), nicht ueber /etc/os-release: Ein Derivat kann sich anders nennen als sein Unterbau, sein Paketwerkzeug liegt aber im PATH. Findet sich keines, wird nichts behauptet. Auf der Rippy-VM gegengeprueft (Ubuntu 26.04 -> apt), unter Git Bash gegengeprueft (kein Treffer -> keine Behauptung). Dazu steht IMMER der Weg da, der auf jeder Distribution funktioniert: get.docker.com bringt das Compose-Plugin mit. Paketnamen wandern, dieses Skript nicht. README stellt jetzt oben klar, dass die Distribution gleichgueltig ist - Rippy bringt MakeMKV, HandBrake und abcde in seinen eigenen Containern mit, vom Host braucht es nur Docker und einen Kernel, der das Laufwerk sieht. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 12:59:42 +02:00
Hitonabi	b0205c42c9	refactor(install): erst ALLES pruefen, dann erst aendern ... Commander-Einwand: "Warum macht das install script den pre-check nicht selbst vor der Installation?" Zu Recht - es tat es nur halb. VORHER war Pruefen und Aendern verschraenkt: 1 Voraussetzungen pruefen (bricht ab) 2 Laufwerk pruefen (warnt) 3 Verzeichnisse AENDERT 4 Mount AENDERT 5 .env AENDERT 6 Bauen AENDERT Nur die harten Voraussetzungen liefen vorab. Verzeichnisse wurden angelegt, bevor klar war, ob der Rest durchlaeuft - scheiterte etwas in der Mitte, blieb ein halb eingerichteter Rechner zurueck. Und --nur-pruefen war als if-Zweig durch FUENF Schritte gefaedelt: so etwas laeuft zwangslaeufig aus dem Ruder, weil jede neue Aktion daran denken muesste. JETZT zwei klar getrennte Phasen: Phase 1 PRUEFEN - fuenf Pruefungen, aendert NICHTS Weiche - Probleme -> Abbruch mit Liste, nichts angefasst Phase 2 EINRICHTEN - Verzeichnisse, Mount, .env, bauen, starten Es gibt damit GENAU EINEN Pruef-Pfad, den beide Modi benutzen: --nur-pruefen heisst schlicht "nach Phase 1 aufhoeren". Die Pruefung kann nicht mehr etwas anderes behaupten als die Installation tut. Die Weiche unterscheidet PROBLEME (verhindern die Installation) von HINWEISEN (halten nicht auf) und fasst am Ende beides als Liste zusammen - vorher musste man die Ausgabe rueckwaerts lesen, um zu wissen, ob es gereicht hat. Neu mitgeprueft, weil es jetzt an einer Stelle passt: - Ist der Elternpfad der Verzeichnisse ueberhaupt beschreibbar? (Vorher waere das erst beim mkdir aufgefallen - mitten in der Aenderungsphase.) - Freier Plattenplatz mit Schwelle 60 GB, samt Hinweis auf die Groessen (Blu-ray roh ~40 GB, 4K-UHD bis 100 GB). - Ist ueberhaupt .env.example da, also stehen wir im Rippy-Repo? - Was in die .env geschrieben WUERDE, steht jetzt in Phase 1 als Ansage. Auf der VM gegengeprueft: aus /tmp gestartet meldet es korrekt "kein Rippy-Repo" und bricht ab, ohne etwas anzufassen; aus dem Repo heraus laeuft die Pruefung sauber durch ("Alles in Ordnung, keine Einschraenkungen"). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-25 22:42:31 +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	ca91e5b693	feat(install): ein Befehl statt Checkliste - install.sh nimmt die Handarbeit ab ... Commander-Rueckmeldung: "Das Docker Deployment ist mir zu kompliziert." Zu Recht - die Installation war eine Checkliste aus sechs Schritten, von denen zwei nur mit Fachwissen zu schaffen waren. ## Neu: sudo ./install.sh Nimmt genau die Schritte ab, an denen man scheitern konnte: 1. Prueft Voraussetzungen (Linux, Docker, Compose) und nennt bei jedem Mangel den Installationsbefehl. 2. FINDET DAS LAUFWERK SELBST. Das war der schlimmste Punkt: MakeMKV braucht ZWEI Geraeteknoten, und die sg-Nummer ist je Host anders. Das Skript gleicht sie ueber die SCSI-Adresse in /sys ab statt zu raten. Auf der VM gegengeprueft: sr0 -> 3:0:0:0, sg1 -> 3:0:0:0, also dasselbe Geraet - korrekt als /dev/sr0 + /dev/sg1 erkannt. 3. Legt Ablage- und MakeMKV-Verzeichnis an. 4. Richtet die Mount-Propagation ein UND macht sie per systemd-.mount-Unit neustart-fest. Vorher stand in der README nur "reboot-fest persistieren" - ohne zu sagen wie; nach einem Reboot scheiterte das Einhaengen von NAS-Freigaben aus dem UI stillschweigend. 5. Schreibt die .env, ueberschreibt aber NIE einen bestehenden Wert. 6. Baut und startet, und nennt bei Fehlschlag die drei haeufigsten Ursachen mit Diagnosebefehl. Wiederholbar (mehrfach ausfuehren aendert nichts kaputt) und damit auch der Update-Weg: git pull && sudo ./install.sh ## Zwei Fallgruben, die beim Testen auffielen - beide meine eigenen - --nur-pruefen verlangte root und brach ab. Ein Pruef-Modus, der nichts aendert, darf daran nicht scheitern - sonst kann man vor der Installation nicht nachsehen, ob alles passt. Behoben. - .env.example hatte OPTICAL_SG=/dev/sg1 UNKOMMENTIERT vorbelegt. Damit haette der Installer den erkannten Wert nicht eingetragen ("steht schon drin") und auf jedem fremden Host still eine kaputte Konfiguration hinterlassen - genau das, was er verhindern soll. Beide Geraetezeilen sind jetzt auskommentiert; Compose hat ohnehin Vorgaben. Dazu eine Gegenprobe im Skript: zeigt ein wirksamer Wert auf ein Geraet, das es hier nicht gibt (".env von einem anderen Rechner"), wird das benannt statt kryptisch von Docker gemeldet. ## README neu aufgebaut Vorher 293 Zeilen, in denen der Schnellstart zwischen lsscsi, sg-Knoten, USB-Passthrough und mount --make-rshared begraben war. Jetzt: Installation in zwei Zeilen oben, dann eine Tabelle "Wenn etwas nicht geht" mit den vier Faellen, die praktisch alles abdecken. Alles Technische steht darunter in aufklappbaren Abschnitten - inklusive der Handarbeits-Variante fuer die, die sie wollen. NEU und ausdruecklich gewuenscht: Abschnitt "Rippy schneller machen" mit dem VM-CPU-Typ. Erklaert, warum Virtualisierer eine generische CPU ohne AVX2 geben, was das kostet (gemessene 28-55 h je 4K-Film), die genauen Schritte in Proxmox (herunterfahren - Hardware/Processors/Type auf 'host' - starten, bzw. qm set <vmid> --cpu host), warum ein Neustart von innen NICHT genuegt, und wie man nachprueft: Rippy zeigt die Vektorbefehle seit v3.14 selbst an. Dazu der Nachteil (keine Live-Migration auf andere CPUs) und die Alternative x86-64-v3 fuer Cluster. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-25 21:59:23 +02:00