diff --git a/AGENTS.md b/AGENTS.md index 7ee3a54..67ddf42 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -70,6 +70,9 @@ Bibliotheks-APIs: `--help`/Doku prüfen und die Fundstelle im Commit nennen. (Fortschritt log, Auswurf tat nichts, „Alle Tracks" konnte nichts, Encoder wurden behauptet statt gemessen), Zombie-Erkennung gebaut, Pfad-Prüfung gehärtet, und der Platten-Schutz aus `c065967` als **unwirksam** entlarvt +- ✅ **Etappe 20 (v3.15):** Aufräum-Runde — `/capabilities` 1,010 s → 0,003 s + (Ping im Hintergrund), Kompression je Disc-Typ abwählbar (4K verlustfrei), + Wizard empfiehlt nach gemessener CPU, vier tote Routen entfernt - 📝 **Details immer in SAVEPOINT.md** — diese Sektion nennt nur die Etappe ## Was diese Sitzungen wiederholt gekostet hat diff --git a/SAVEPOINT.md b/SAVEPOINT.md index 2356cfd..c3abf48 100644 --- a/SAVEPOINT.md +++ b/SAVEPOINT.md @@ -1,6 +1,115 @@ # SAVEPOINT — Rippy -## Aktueller Stand: v3.14 — Durchsicht: vier Placebos und ein unwirksamer Schutz (25.07.2026, 18:40) +## Aktueller Stand: v3.15 — Aufräum-Runde: Tempo, tote Routen, 4K-Entscheidung (25.07.2026, 20:00) + +> **Deployt und live gegengeprüft.** Auftrag war „bau alles so um, dass es +> sauber ist" mit fünf Vorgaben: saubere Codebase, selbsterklärendes UI, +> externe Worker, kein Laggen, idiotensicher. Was noch offen ist, steht unten. + +### Das „Laggen" hatte genau eine Ursache — gemessen und behoben + +Über alle 15 Endpunkte gemessen, die das UI beim Laden braucht: + +| Endpunkt | vorher | nachher | +|---|---|---| +| `/capabilities` | **1,010 s** | **0,003 s** | +| `/system/updates` | 0,491 s | unverändert (hängt am Knopf) | +| `/metadata/status` | 0,412 s | unverändert (hängt am Knopf) | +| die anderen 12 | < 0,025 s | < 0,010 s | + +Nur `/capabilities` schlug beim **Seitenaufbau** zu — und fünf Stellen holen +ihn (Dashboard, Einstellungen, Worker-Tab, Wizard, Rip-Dialog). Jede Seite +zahlte eine Sekunde. Ursache ist kein Fehler, sondern das Wesen des +Celery-Pings: er sammelt Antworten bis zum Timeout und kann nicht früher +aufhören. Den Timeout zu kürzen würde Antworten langsamer Remote-Worker +verschlucken — also genau die Maschinen, um die es beim externen Encoding geht. +Jetzt pingt eine Hintergrund-Schleife im 5-s-Takt, der Endpunkt liest ab. Ist +der Vorrat älter als 30 s, wird einmal synchron gepingt: lieber langsam als +falsch („alles offline", obwohl alles läuft). Kompletter Dashboard-Aufbau: +**1,03 s → 0,028 s.** + +### 4K ist entschieden — Kompression je Disc-Typ abwählbar + +Die offene Frage aus v3.14 ist gebaut. Bisher gab es nur `transcodeEnabled`: +alles oder nichts. Jetzt kann das Preset eines Disc-Typs auf den Reservewert +`keine` stehen → die verlustfreie Datei bleibt stehen. Damit ist die sinnvolle +Einstellung für diese Maschine erstmals möglich: **4K verlustfrei behalten, +DVD und Blu-ray weiter schrumpfen.** + +`komprimieren_fuer()` ist die neue reine Funktion; `preset_fuer()` überspringt +den Reservewert bewusst und gibt ihn NIE als Preset-Namen zurück — sonst bekäme +HandBrake `--preset keine`. Gegengeprüft: keiner der 90 echten Presets aus +`--preset-list` heißt so, und die fünf im UI angebotenen Namen existieren alle. + +### Der Wizard läuft nicht mehr in die 4K-Falle + +Er hatte die Zahlen längst vorliegen (`/capabilities` meldet `cpu_simd` und +`cpu_kerne`) — benutzt hat er sie nicht und H.265 als Standard vorgeschlagen. +Auf einer CPU ohne AVX2 sind das ein bis zwei Tage pro 4K-Film. + +Jetzt entscheidet die **gemessene** Leistung: schwache CPU → 4K nicht +komprimieren, Blu-ray/DVD auf H.264. Stark oder Hardware-Encoder → H.265 +durchgehend. Und er schreibt **alle vier** Preset-Felder statt nur des +allgemeinen; vorher fiel 4K auf ein 1080p-Preset zurück. + +Dazu gehärtet: Kasten „Was Rippy gerade sieht" (Laufwerk, Worker mit +Kernen/SIMD, freier Platz) — jede Zeile mit **Handlungsanweisung** statt nur +einem Kreuz. Lädt parallel und wiederholt im 5-s-Takt, weil der Worker beim +ersten Start noch hochläuft. API-Keys sind sichtbar statt Punkte (kopierte +Keys, keine Passwörter — Tippfehler sieht man in Punkten nicht) und werden +direkt nach dem Speichern geprüft, mit der Wahl „Key korrigieren" oder +„Trotzdem fertigstellen". + +**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` (kein `/proc/cpuinfo`) +→ dann wird geschwiegen statt falsch gewarnt. + +### Vier tote Routen raus + +`POST /prescan`, `POST /jellyfin/format` (+ `nfo_generator.py` und +`image_downloader.py`, die sonst nichts nutzte), `GET /stream/jobs`, +`GET /worker-setup/windows-gui`. Jede ein Überrest eines ersetzten Entwurfs, +keine mit Aufrufer. `main.py`: 1726 → 1682 Zeilen, dazu 279 Zeilen in zwei +gelöschten Modulen. Tests halten beide Seiten fest: die vier müssen WEG +bleiben, die drei für die Worker-Installation (`/worker-setup/paket`, +`/windows`, `/windows-exe`) müssen DA sein. + +### Externe Worker — vorbereitet, vom Commander zu testen + +Auf **Windows gegengeprüft** (dieser PC): `cpu_kerne` 16 und CPU-Modell kommen +korrekt durch, `encoders` ist ohne installiertes HandBrake korrekt **leer**, +`cpu_simd` ehrlich `unbekannt` → keine falsche Warnung. Ein GPU-Worker braucht +ein HandBrake-Build mit `nvenc_*`/`qsv_*`; die neue Anzeige nennt die +ungefilterte HandBrake-Auskunft, damit das nachprüfbar ist. + +### ARM-Vergleich (Vorbild-Projekt) + +Fast alles, was ARM automatisch macht, macht Rippy schon — und meist +gründlicher: Metadaten aus drei Quellen statt nur OMDb, Episoden-Erkennung per +Laufzeitabgleich, Kompression auf eine eigene Queue routbar. Bezeichnend: +ARMs Auto-Auswurf war bei Rippy nur **behauptet** und ist erst in v3.14 echt +geworden. Zwei Lücken bleiben, beide **nicht gebaut, als Vorschlag**: +- **ISO-Sicherung** für Datenträger, die weder Film noch Audio-CD sind — daran + scheitert Rippy heute. +- **Mehrere Laufwerke gleichzeitig.** Rippy sieht sie (`/dev/sr[0-9]*`), ob + parallel gerippt wird, ist **unbewiesen** — mit einem Laufwerk nicht testbar. + +### NOCH OFFEN + +1. **Externe Worker im Praxistest** (Commander). +2. **ISO-Sicherung und Mehr-Laufwerk-Betrieb** — siehe ARM-Vergleich. +3. **„Job aus der Liste entfernen" sagt nicht, wie viel daneben liegen bleibt** + (v3.14). Der Rohschnitt verwaist dabei unsichtbar. +4. **Discord-Webhook und MakeMKV-Key liegen im Klartext** in der + settings-Tabelle. Für Heimnetz erwartbar, aber der Webhook ist eine echte + Zugangsberechtigung. +5. **Der VM-CPU-Typ steht auf `qemu64`.** `host` würde AVX2 freischalten und + jeden Software-Encode 2–4× beschleunigen. Ein VM-Neustart, nicht gemacht. + +--- + +## Vorheriger Stand: v3.14 — Durchsicht: vier Placebos und ein unwirksamer Schutz (25.07.2026, 18:40) > **Stand 19:30: alles committet, Ampel grün (`a1aabd5`), DEPLOYT und live > gegengeprüft.** Der Akira-Encode wurde um 18:31 abgebrochen (Nachtrag im