9 Commits

Include renames

Author	SHA1	Message	Date
HitonabiandClaude Opus 5	8e65411189	fix(windows): die Datenbank lag AUSSERHALB der Installation — daher fehlte ... der Ersteinrichtungs-Assistent Der Befund des Commanders: "Ausserdem fehlt der 1st run wizzard wenn man es installiert." Meine erste Reparatur (App.tsx las einen gescheiterten Abruf als "erledigt") war richtig, aber nicht die Ursache. Nachgemessen: Installation %LOCALAPPDATA%\Rippy wird deinstalliert Datenbank %ProgramData%\Rippy BLEIBT LIEGEN Eine "frische" Installation erbte damit die alte Datenbank samt `setup.done = true` -- der Assistent erschien nie wieder. Gegengeprueft: nach dem Aufraeumen meldet /api/setup wieder {"done": false}, und das Fenster zeigt "Willkommen bei Rippy". Der Grund fuer den alten Ort stand im Docstring: "Ein Programmordner ist unter Windows fuer einen DIENST nicht zuverlaessig beschreibbar." Das stimmte -- fuer den Windows-Dienst, den es nie gab. Rippy laeuft als der angemeldete Benutzer (Autostart unter HKCU). Jetzt liegt alles, was Rippy gehoert, in EINEM Ordner: Programm, UI, Werkzeuge, Protokoll, WebView2-Zwischenspeicher und die Datenbank. Dazu: * `datenbank_umziehen()` holt eine vorhandene Datenbank vom alten Ort ab -- wer Rippy schon benutzt hat, behaelt Jobs und Einstellungen. Gibt es am neuen Ort schon eine, bleibt sie unangetastet: Die BENUTZTE gewinnt. * `deinstallieren()` raeumt den alten Ort mit weg, und `alte_orte()` fasst nur einen Ordner an, der wirklich "Rippy" heisst. * Der Ersteinrichtungs-Assistent spricht nicht mehr von "Encoding-Worker", wenn es keine gibt -- dort steht jetzt "Kompression". Gegengeprueft: kein "docker", kein "Container", kein "Worker" mehr im Text. Ampel lokal: 709 gruen, ruff sauber. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 14:46:02 +02:00
HitonabiandClaude Opus 5	9230d0dd7a	fix(weitergabe): drei Luecken geschlossen, die einen Fremden gestolpert haetten ... Weitergabe nicht durch Lesen geprueft, sondern indem ich mich wie ein fremder Rechner verhalten habe: frischer `git clone` von Gitea in ein leeres Verzeichnis, dann `./install.sh --nur-pruefen`. Ergebnis: 2,6 MB, alles gruen, Laufwerk samt richtigem sg-Knoten ueber die SCSI-Adresse erkannt. Der Weg selbst traegt. Drei Luecken sind dabei aufgefallen: 1. IN BEISPIELBEFEHLEN STAND MEINE IP. `install.ps1` und `remote-transcode-worker.yml` nannten im Aufruf-Beispiel 192.168.178.162 - also genau die Zeile, die ein Fremder kopiert. Jetzt Platzhalter, beim Windows-Installer mit dem Hinweis, wo die richtige IP steht (und dass es NICHT die des eigenen PCs ist - der haeufigste Irrtum). 2. DER ASSISTENT FRAGTE DEN MAKEMKV-BETA-KEY NICHT. Er stand in der README, in der .env und in den Einstellungen - nur nicht dort, wo man beim Einrichten hinsieht. Ein Fremder installiert also, legt eine Blu-ray ein und bekommt spaeter einen Fehlschlag, ohne dass ihn jemand darauf hingewiesen haette. Das ist die wahrscheinlichste Stolperstelle einer frischen Installation. Jetzt fragt der Assistent ihn ab, mit dem Unterschied im Klartext: DVDs gehen ohne, Blu-ray braucht ihn - und er ist NICHT der Disc-Schluessel einer 4K-Disc. 3. Eine Docstring nannte meine NAS-IP als Beispiel - jetzt neutral (//NAS/rippy). Tests und Log-Beispiele behalten die echten Namen: Sie dokumentieren Messungen, und genau das ist ihr Wert. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 15:18:30 +02:00
HitonabiandClaude Opus 5	638edc6a9f	feat(ui): Presets vom Worker, Warnung vor unerreichbaren Pfaden, Browser weg ... Vier Commander-Punkte auf einmal, alle am selben Ort. Presets (Punkt 1 + 3b): Die drei Auswahllisten in Einstellungen kommen jetzt vom Worker statt aus dieser Datei, gefiltert auf die passende Aufloesung - die 4K-Liste bietet keine 1080p-Presets mehr als Normalfall an (genau dieser Griff rechnete in v3.12 eine 4K-UHD auf 1080p herunter; bewusstes Verkleinern steht jetzt in einer eigenen, benannten Gruppe). Knopf "Bestes waehlen" uebernimmt die Empfehlung fuer alle drei Disc-Typen, und unter jeder Liste steht, WARUM. Ein gespeicherter Wert, den der Worker nicht kennt, wird benannt statt verschluckt - so faellt eine falsche Bestandseinstellung ueberhaupt auf. Der Wizard entscheidet nicht mehr selbst, sondern nimmt dieselbe Empfehlung. Damit gibt es nur noch EINE Stelle mit dieser Logik, und die hat Tests. Warnung vor dem Start (Punkt 6 des Savepoints): Waehlt man einen externen Encoder, der Quelle oder Ziel nicht erreicht, steht das JETZT im Rip-Dialog - nicht erst nach einer Stunde Rip. Geprueft wird mit derselben Regel, die pfad_lokal() im Worker anwendet. Bei "Automatisch" wird genannt, welcher Worker die Aufgabe kaputtmachen koennte: die geteilte Queue nimmt den ersten freien. Datei-Browser (Punkt 7): "Warum wird hier der Datei Browser noch angezeigt - das ist doch quatsch." Er ist nicht wirklich redundant (nur ueber ihn geht ein freier Zielordner fuer EINEN Rip), aber er ueberschrieb die Schnellwahl stillschweigend. Jetzt eingeklappt - wer ihn aufklappt, entscheidet bewusst, und /browse wird erst dann geholt. Nebenbefund: browseFiles wurde geladen und NIE angezeigt, samt ungenutztem File-Icon - beides raus. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 12:58:53 +02:00
HitonabiandClaude Opus 5	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
HitonabiandClaude Opus 5	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
HitonabiandClaude Opus 5	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
HitonabiandClaude Fable 5	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
HitonabiandClaude Fable 5	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