6 Commits

Author	SHA1	Message	Date
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	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	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	90b708302e	refactor(ui): Modals & Unterseiten auf Primitives & dark: umgestellt	2026-07-24 16:04:46 +02:00
Hitonabi	13c1ae6064	feat(ui): Toast-Feedback ueberall, Job-Detail-Popup, System-Tab, Wizard-Media-Server, Favicon, Footer ... - ToastContext: jede Aktion quittiert sichtbar ('Erfolgreich aktualisiert' ploppt oben rechts rein) — Refresh-Knoepfe drehen jetzt wirklich (Laufwerke, Logs, Worker, Speicherziele). - JobDetailModal: Klick auf Titel in 'Neueste Jobs' -> Poster, Jahr, Beschreibung, Genres, Ablagepfad, Fehler. - Logs: Filter-Pills um Warnung + Fehler ergaenzt (vorher nur Alle/Info/Erfolg). - Speicherziele: Benutzer/Passwort VOR dem 'Freigaben auflisten'-Knopf (Windows/NAS lehnen Gast-Abfragen ab — genau daher kam das NT_STATUS_ACCESS_DENIED), Hinweistext, Toasts beim Einhaengen/Entfernen. - Datei-Browser (Speicherziele + Rip-Ziel-Dialog) zeigt Dateien grau mit Groesse — Ordner wirkten faelschlich leer. - Einstellungen: neuer System-Tab (Werkzeug-Versionen je Worker, Key-Status, Plattenplatz, MakeMKV-Beta-Key-Feld), Media-Server-Wahl im Ripping-Tab, Arbeitsverzeichnis im Verarbeitung-Tab, Benachrichtigungs-Anleitung (Discord/ntfy/Slack) + 'Test senden'. - First-Run-Wizard: Media-Server-Schritt (Jellyfin/Emby/Kodi/Plex/Keins). - Favicon (Disc im Logo-Verlauf, public/favicon.svg — /vite.svg war 404) + Footer 'Created with (Herz) by LucyAI, Claude and KrBrZ'. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 08:55:42 +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