From b546c79b9e9de17b90f8a4a9fbd47941900b6aca Mon Sep 17 00:00:00 2001 From: Hitonabi Date: Sat, 25 Jul 2026 21:29:56 +0200 Subject: [PATCH] docs(savepoint): deployt und aufgeraeumt - Stand 19:30 mit Belegen Der Block behauptete "nichts ist deployt" und fuehrte Fragment wie Rohschnitt als offene Punkte. Beides ueberholt - genau solche stehen gebliebenen Zusagen waren das Thema dieser Sitzung. Nachgezogen mit Belegen statt Behauptungen: - a1aabd5 laeuft, alle 5 Container up - GET /capabilities antwortet cpu-x264/cpu-x265/cpu-av1 - KEIN Phantom-vaapi mehr, dazu QEMU Virtual CPU 2.5+, 4 Kerne, sse4_2 (AVX2-Warnung greift) - Zombie-Erkennung 19:26:09, exakt 120 s nach Start, geprueft=0 - 604 Disc-Schluessel haben den Rebuild ueberlebt - Fragment (67.633.152 B) und der verwaiste 75-GB-Rohschnitt geloescht, Platte 37 GB -> 111 GB frei Neuer Befund dabei, nicht gebaut: "Job aus der Liste entfernen" loescht bewusst keine Dateien - richtig so, macht die Rohdaten aber unerreichbar, weil beides nur ueber die Job-ID verbunden ist. Der Rohschnitt war danach im UI unsichtbar und "Neu komprimieren" unmoeglich. Das UI sollte beim Loeschen sagen, wie viel daneben liegen bleibt. Bei den vier toten Endpunkten steht jetzt, WARUM sie tot sind (jeder ein Ueberrest eines ersetzten Entwurfs) und dass /stream/jobs der unangenehmste ist: keine harmlose Leiche, sondern eine Endlosschleife je Verbindung. Co-Authored-By: Claude Opus 5 --- SAVEPOINT.md | 64 ++++++++++++++++++++++++++++++++++++++-------------- 1 file changed, 47 insertions(+), 17 deletions(-) diff --git a/SAVEPOINT.md b/SAVEPOINT.md index a1bd9de..2356cfd 100644 --- a/SAVEPOINT.md +++ b/SAVEPOINT.md @@ -2,10 +2,11 @@ ## Aktueller Stand: v3.14 — Durchsicht: vier Placebos und ein unwirksamer Schutz (25.07.2026, 18:40) -> Alles unten ist committet, die Ampel ist grün, **nichts ist deployt**. -> Der Akira-Encode wurde parallel zu dieser Sitzung um 18:31 abgebrochen -> (siehe Nachtrag im Block darunter) — **es läuft jetzt nichts mehr, ein -> Deploy ist gefahrlos möglich.** Zuerst lesen: „SOFORT ENTSCHEIDEN" unten. +> **Stand 19:30: alles committet, Ampel grün (`a1aabd5`), DEPLOYT und live +> gegengeprüft.** Der Akira-Encode wurde um 18:31 abgebrochen (Nachtrag im +> Block darunter), danach der Job aus der Liste gelöscht und die Rohdaten +> entsorgt. Es läuft nichts, die Platte hat **111 GB frei**. +> Was noch zu entscheiden ist, steht unten unter „NOCH OFFEN". ### DER WICHTIGSTE FUND: der Platten-Schutz aus `c065967` greift nicht @@ -161,17 +162,35 @@ Encode-Prozente liefert — dort war ein Abbruch vorher grundsätzlich unmöglic Die Leseschleife ist als `_handbrake_schleife()` herausgezogen, damit die Reihenfolge (Abbruch VOR Fortschritt) ohne echtes HandBrake testbar ist. -### SOFORT ENTSCHEIDEN +### ERLEDIGT UM 19:30 — deployt und live gegengeprüft -**1. Deployen — es läuft nichts, der Weg ist frei.** Nichts blockiert mehr, und -solange nicht deployt ist, gilt weiterhin der alte Code: unwirksamer -Platten-Schutz, Anzeige auf 99 %, Auswurf ohne Wirkung, träges „Abbrechen". +`a1aabd5` läuft auf der VM. Belege, nicht Behauptungen: -``` -ssh arcane@192.168.178.162 'cd ~/projects/rippy && git pull --ff-only && docker compose up -d --build' -``` +- **Container:** alle 5 up, api/postgres/redis `healthy`. +- **Die neue Auslese antwortet ehrlich** (`GET /capabilities`): + `cpu-x264, cpu-x265, cpu-av1` — **kein Phantom-`vaapi`** mehr, obwohl die + alte Fassung es bei vorhandenem `/dev/dri` gemeldet hätte. Dazu + `cpu_modell: QEMU Virtual CPU version 2.5+`, `cpu_kerne: 4`, + `cpu_simd: sse4_2` → die AVX2-Warnung im UI greift. +- **Zombie-Erkennung:** 19:26:09, exakt 120 s nach Worker-Start, + `{'geprueft': 0, 'aufgeraeumt': []}` — nachgesehen, nichts in Arbeit + gefunden, korrekt nichts angetastet. +- **604 Disc-Schlüssel** haben den Rebuild überlebt. +- **Aufgeräumt:** das unbrauchbare 4K-Fragment (67.633.152 B) gelöscht; der + Akira-Job wurde um 19:07 aus der Liste entfernt, wodurch der 75-GB-Rohschnitt + verwaiste (kein Job-Datensatz zeigte mehr darauf, im UI unsichtbar, + „Neu komprimieren" unmöglich) — auf Entscheid des Commanders gelöscht, samt + vier leerer Alt-Ordner. **Platte: 37 GB → 111 GB frei.** -**2. Die UHD-Strategie ist noch offen** (aus dem Nachtrag, unverändert gültig). +⚠️ **Merken für die Job-Verwaltung:** „Job aus der Liste entfernen" löscht +bewusst keine Dateien — das ist richtig, macht die Rohdaten aber unerreichbar, +weil beides nur über die Job-ID verbunden ist. Ein Rohschnitt ohne Job-Zeile +taucht nirgends mehr auf. Das UI sollte beim Löschen sagen, wie viel daneben +liegen bleibt. Nicht gebaut. + +### NOCH OFFEN + +**1. Die UHD-Strategie** (aus dem Nachtrag, unverändert gültig). Preset-je-Disc-Typ war richtig, reicht aber nicht: Software-HEVC in 4K ist auf dieser CPU keine Option. Drei Wege, keiner davon gebaut: - **UHD gar nicht komprimieren** — Roh-MKV behalten. Ehrlichste Variante, @@ -184,12 +203,23 @@ dieser CPU keine Option. Drei Wege, keiner davon gebaut: Faktor 2–4. Aus 28–55 h werden damit aber immer noch Stunden bis Tage; das allein löst 4K nicht, hilft aber jedem 1080p-Encode. -**3. Vier tote Endpunkte** — entfernen oder behalten (Tabelle oben). +**2. Vier tote Endpunkte** — entfernen oder behalten (Tabelle oben). Alle vier +sind Überreste eines ersetzten Entwurfs: `/jellyfin/format` (die Arbeit macht +seit v3.2 `medien.py` im Worker), `/prescan` (Metadaten-Seite ist seit v3.4 +weg; die `PreScan`-Klasse selbst wird sehr wohl gebraucht), `/stream/jobs` +(kein `EventSource` im UI — das Dashboard pollt `setInterval(…, 4000)`) und +`/worker-setup/windows-gui` (seit der `.exe` in v3.9 ohne Aufrufer; die Datei +steckt weiter in der `.exe`). **`/stream/jobs` ist der unangenehmste:** keine +harmlose Leiche, sondern eine Endlosschleife je Verbindung, die jeder erreichen +kann. Empfehlung: alle vier raus, plus `nfo_generator.py` und +`image_downloader.py` in der API (nutzt sonst nichts) — und `test_api_smoke.py` +prüft `/prescan` als verdrahtete Route, der Test muss also mit. -**4. Im Akira-Ordner liegt ein unbrauchbares 4K-Fragment** (die 1080p-Fassung -wurde beim Start auf 0 Bytes gekürzt). Der 75-GB-Rohschnitt ist unversehrt, -also ist nichts verloren — aber die Datei gehört weg, bevor jemand sie für ein -Ergebnis hält. +**3. Akira liegt jetzt gar nicht mehr vor.** Fragment und Rohschnitt sind +gelöscht (siehe oben). Wer den Film will, legt die Disc neu ein — der +Schlüsselspeicher steht (604 Schlüssel), der Rip dauert rund eine Stunde. Vor +dem nächsten UHD-Versuch aber Punkt 1 entscheiden, sonst läuft dasselbe +50-Stunden-Rennen wieder an. ---