9 Commits

Author	SHA1	Message	Date
Hitonabi	bfb13f44a5	fix(ui+api): das "Neuladen" war HTTP 429 - und "Neu" komprimierte immer ... Zwei Commander-Befunde, beide mit derselben Wurzel: Rippy hat sich selbst ausgebremst und dann geschwiegen. ## "Wenn der Worker installiert ist, wird dieser Bereich oft neu geladen" Gemessen statt geraten. Die Antworten von /jobs und /capabilities waren ueber zwanzig Sekunden byteweise identisch, alle Endpunkte antworteten unter 30 ms - es wurde also gar nichts neu geladen. Im nginx-Log standen dagegen 97 Antworten mit HTTP 429. Drei Fehler griffen ineinander: 1. Das Limit war zu klein fuer Rippy selbst: 100 Anfragen/min, waehrend ein offener Tab 111/min verursacht (Dashboard 75 + Log-Kasten 24 + Laufwerke 12) und der Windows-Tray weitere 12/min dazulegt. 2. Der nginx gab die Client-Adresse nicht weiter. Fuer die API kam damit ALLES von 172.19.0.6 - Browser, zweiter Tab und Tray teilten sich einen Eimer (812 von 876 Anfragen). Das erklaert die Kopplung an den Worker: tray.py fragt /api/jobs ueber Port 80, also durch denselben Proxy. 3. Ein abgewiesener Abruf leerte das UI. `catch(() => [])` heisst "es gibt keine Jobs" - richtig waere "ich weiss gerade nichts Neues". Fuer einen Takt stand "Keine Jobs", die Zaehler sprangen auf (0), vier Sekunden spaeter war alles zurueck. Behoben: X-Real-IP im nginx, Grenze auf 600/min mit vorgerechneter Herleitung, jeder Fehlschlag laesst den alten Stand stehen (null statt []), axios bekommt eine Zeitgrenze, und das Dashboard trennt schnelle Daten (Jobs/Laufwerke, 4 s) von langsamen (Hardware/Worker/Ablagen, 12 s) - 75/min werden zu 30/min. Ein greifendes Limit steht ab jetzt im Log, gedrosselt auf eine Meldung pro Client und Minute. ## "Hier gibt es den Button 'neu' aber WAS wird dann gemacht?" Immer die Komprimierung - auch bei einem Job, dessen RIP abgebrochen war. Am 26.07.2026 waeren aus 5,1 GB Bruchstueck (von rund 40 GB) brav ein Film geworden, der bei 12 % aufhoert. Die Phase war nach `status = "failed"` nicht mehr feststellbar, also wird sie jetzt vermerkt (rip_fertig in den Job-Metadaten: false beim Rip-Start, true bei der Uebergabe an die Kompression). Daraus folgt die Beschriftung: "Neu komprimieren", "Neu rippen" - oder bei Bestandsjobs ohne Vermerk ein Dialog, der beide Wege erklaert und die Groesse der Rohdaten als Entscheidungshilfe nennt. Geraten wird nicht. Fuer den Rip-Fall gibt es POST /jobs/{id}/retry-rip: neuer Job mit neuer ID (sonst laege das Bruchstueck im Roh-Verzeichnis des neuen Rips), Titel/Ablage/Sprachwahl uebernommen, mit ehrlicher Absage wenn keine Disc im Laufwerk liegt. 10 neue Tests (289 gruen), darunter eine Kopplungspruefung: der Name der Phasen-Marke muss in worker/tasks.py und api/phasen.py zusammenpassen - genau diese Sorte Auseinanderdriften hat die Zombie-Erkennung ein Release lang blind gemacht. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 16:49:10 +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	e0cb7b3ddc	feat(worker): Zombie-Erkennung - Jobs, an denen niemand arbeitet ... Nach einem Absturz oder Rebuild blieb ein Job auf 'transcoding' stehen, obwohl weder ein Prozess lief noch etwas in den Queues stand. Folge: keine Anzeige, kein Download - und der Knopf "Neu komprimieren" fehlte, weil _kann_neu_komprimieren (api/main.py) status=='failed' verlangt. Der Job war unerreichbar, obwohl die Rohdateien vollstaendig dalagen. zombies.py haelt beim Worker-Start die Jobs in 'ripping'/'transcoding'/ 'canceling' gegen Celerys active/reserved/scheduled und setzt sie ehrlich auf 'failed', wenn niemand daran arbeitet. Drei Sicherungen, weil ein falsch getoeteter Job teurer ist als eine stehengebliebene Leiche: - nur beim Start (da ist "es lief nichts" eindeutig; ein periodischer Lauf koennte einen Job erwischen, der legitim in der Warteschlange wartet) - 120 s Gnadenfrist (Celery stellt unbestaetigte Aufgaben erneut zu) - Vollzaehligkeit: antworten weniger Knoten als laut Herzschlag online sind, wird NICHTS gewertet - sonst waere der laufende Job eines beschaeftigten Remote-Workers eine falsche Leiche Die Job-ID wird per Textsuche ueber die Inspektions-Antwort gefunden, nicht per Position: sie steht bei rip_disc an zweiter, bei transcode_files an erster Stelle, und Celery liefert args je nach Version als Liste oder Text. 13 Tests ohne Postgres/Redis, darunter "laufender Job wird nicht angetastet" und "schweigender Worker verhindert jedes Urteil". Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-25 21:04:19 +02:00
Hitonabi	3a4eb25392	Track-Auswahl-Tabelle, nativer Windows-Worker (via UI angeboten), Anleitungs-Tab ... Volle Titel-Auswahl vor dem Rip (Etappe-12-Rest): - worker.tasks.scan_tracks: makemkvcon info -> Titel-Liste (Dauer/Groesse/ Kapitel, apdefs-Attr 8/9/11) in die settings-Tabelle 'tracks:<device>'; API: POST /devices/{n}/scan-tracks + GET /devices/{n}/tracks (Polling). - Rip-Dialog: 'Disc scannen' -> Tabelle mit Checkboxen, Vorauswahl ab 5 min, Groessen-Summe; gewaehlte Titel als meta.titles in den Job. - rip_titel_auswahl: ein makemkvcon-Aufruf je Titel (mkv kann nur einen Titel oder all), Fortschritt anteilig. Parser-Tests dabei. Nativer Windows-Worker OHNE Docker (Commander-Wunsch): - Die Rippy-Instanz versorgt sich selbst: GET /worker-setup/windows liefert install.ps1, /worker-setup/paket den Worker-Code als Zip (api-Dockerfile kopiert docker/worker/*.py als worker_dist/ ins Image). - install.ps1: Python-Check, venv + requirements, HandBrakeCLI 1.9.2 vom offiziellen GitHub-Release (URL per HEAD verifiziert), start-worker.bat mit celery -Q transcode --pool=solo (Celery-Doku: Windows nur solo), optional -Autostart via schtasks onlogon. - tasks.py laedt jetzt auch ohne fcntl (Import-Guard) — rip_disc ist auf solchen Workern hart verriegelt (Klartext-Fehler statt Crash). - Einstellungen -> Worker: Varianten-Umschalter Linux(Docker)/Windows(nativ) mit passenden Copy-Paste-Befehlen. Anleitungs-Tab: Rippy erklaert sich selbst (Disc-Weg, Serien, NAS, Media-Server, Benachrichtigungen, Key, Worker, Downloads, FAQ). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 15:18:08 +02:00
Hitonabi	e032a9df1c	feat(backend): Media-Server-Aufbereitung, echte Webhooks, SMB-Klartext, UHD-Arbeitsverzeichnis, MakeMKV-Key via UI ... - jobs.meta (Migration in beiden db.py): Disc-Metadaten wandern in den Job — Quelle fuer Job-Detail-Popup (GET /jobs/{id}/detail), Ordner-Benennung, NFO. - medien.py (Worker, mit Tests): Zielordner 'Titel (Jahr)' statt Job-UUID; movie.nfo/tvshow.nfo (Kodi-Schema, kodi.wiki/view/NFO_files) + poster.jpg fuer jellyfin/emby/kodi; plex nur Benennung; Kollision -> Job-ID-Suffix. - notify.py (identisch in API+Worker, mit Tests): Webhook bei Job-Ende — Discord ({content}, discord.com/developers), Slack ({text}, api.slack.com/messaging/webhooks), ntfy (Rohtext + ?title=, docs.ntfy.sh), generisches JSON. Vorher war das Setting ein Placebo: nichts sendete je. POST /notifications/test beweist die Anbindung sofort. - mounts.py: NT_STATUS-Fehler -> handelbarer Klartext (ACCESS_DENIED ohne Credentials = Gast-Abfrage verweigert), Timeout-Meldung, mount-Hinweis bei error(13). Mit Tests. - tasks.py: Platz-Check per Disc-Groesse (ioctl BLKGETSIZE64) VOR dem Rip; Arbeitsverzeichnis workDir (unter /app/media, z.B. NAS) statt fix /app/temp/raw — 4K-UHD-Rohdaten (bis 100 GB) sprengen sonst die VM-Platte; MakeMKV-Key aus UI-Settings (~/.MakeMKV/settings.conf, Format wie entrypoint.sh) gilt ab dem naechsten Rip ohne Rebuild. - caps.py: Werkzeug-Versionen (MakeMKV aus ENV MAKEMKV_VERSION im Image, makemkvcon hat keinen --version-Schalter lt. usage.txt; HandBrakeCLI --version lt. handbrake.fr/docs) + Key-Quelle; workers.info-Spalte. - /browse liefert jetzt auch DATEIEN (Name + Groesse) — der 'leere' bluray-Ordner war voll, der Browser zeigte nur Unterordner. - GET /system/info: Versionen, Plattenplatz, Key-/Webhook-Status. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 08:55:22 +02:00
Hitonabi	07be54e62a	Jikan/MAL-Quelle + Job-Titel + Abbrechen-Knopf + Dark-Hover + Ordner-Verwaltung ... Commander-Befunde (Screenshots 23.07. abends): - Jikan (MyAnimeList, kostenlos OHNE Key) als Anime-Quelle vor OMDb — waehlt per Titel-Aehnlichkeit (SequenceMatcher, Schwelle 0.55) statt blind Treffer 1; damit trifft "Evangelion 2.22" den exakten Film - Job-Titel: POST /jobs uebernimmt den erkannten Disc-Titel aus dem DISC_CACHE — Schluss mit "Unbekannt" in der Queue - Kooperativer Job-Abbruch: POST /jobs/{id}/cancel setzt canceling, der Worker prueft das Flag bei jedem Fortschritts-Update und killt den Encoder-Prozess sauber (RipAbbruch); UI-Knopf "Abbrechen" fuer laufende, Status-Badge "Wird abgebrochen" - Dark-Mode: Job-Zeilen-Hover war hart hell (hover:bg-slate-50) - Speicherziele: lokaler Ordner-Browser mit "Ordner anlegen" (GET /browse + POST /browse/mkdir, nur unter /app/media) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-23 21:22:57 +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
Hitonabi	2474b683e2	Transcode-Stufe: HandBrake komprimiert NACH dem MakeMKV-Rip + --noscan-Fix ... Commander-Entscheid 23.07.: 40-GB-Rohdateien sind kein brauchbares Endprodukt. Architektur bleibt zweistufig, weil HandBrake AACS nicht lesen kann: MakeMKV rippt verlustfrei nach /app/temp/raw, HandBrake macht daraus x265 auf Arbeitsgroesse in /app/media, Roh-Verzeichnis wird erst NACH komplettem Erfolg geloescht (keepOriginal behaelt es). - Worker: handbrake-cli im Image, run_handbrake + _komprimiere, Job-Status "transcoding", Settings aus Postgres (transcodeEnabled/ Preset/keepOriginal), Fortschritt je Datei aggregiert - makemkvcon: --noscan im Kommando verankert — der Geraete-Scan haengt (1.18.4) bzw. crasht (1.17.7) im Container, mit --noscan + dev:-Pfad laeuft es (Befund 23.07., DRV-Zeile beweist Laufwerks-Erkennung) - UI: Settings-Tab "Verarbeitung" (Toggle/Preset/Original behalten), Status-Badge "Komprimieren", LiveLog erkennt transcoding als aktiv - KONZEPT/ROADMAP entsprechend aktualisiert; Tests fuer HandBrake-Cmd (arbeitet auf DATEI, nie am Geraet) und Progress-Regex Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-23 15:56:37 +02:00
Hitonabi	780d114fe4	Etappe 10: Worker rippt wirklich — MakeMKV 1.18.4 + ioctl-Disc-Erkennung ... Vorher: Dockerfile unbaubar (makepkg ist ein Arch-Paket, existiert in Debian nicht) und KEIN einziges Ripping-Tool im Image — jeder Rip endete sofort. Disc-Erkennung via `file -L` konnte auf Block-Devices strukturell nie etwas erkennen; ihr Test mockte sich die Ausgabe passend. - makemkv-oss/bin 1.18.4 multi-stage (bookworm-gepinnt), EULA via tmp/eula_accepted, Beta-Key aus MAKEMKV_APP_KEY (entrypoint.sh) - makemkvcon-Aufruf + PRGV-Parsing laut makemkv.com/developers/usage.txt (AGENTS Regel D), HandBrake raus aus dem Ripp-Pfad (KONZEPT: lossless=Muss) - detection.py: CDROM_DISC_STATUS + BLKGETSIZE64 (cd/dvd/bluray), pure classify() mit ehrlichen Tests - tasks.py: rip_disc als einziger Celery-Task, schreibt Status/Fortschritt nach Postgres (db.py), Ausgabe auf /app/media (Volume) statt totem /output Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-23 15:02:13 +02:00