docs(savepoint): Uebergabestand v3.13 - gemessen vs. vermutet getrennt
Ampel / ampel (push) Successful in 46s

Uebergabe an eine neue Sitzung. Der Block trennt bewusst, was per Befehl auf
der VM geprueft wurde, von dem was offen bzw. nur erwartet ist - inklusive
zweier Fehlschluesse dieser Sitzung, damit die naechste Sitzung weiss, welchen
Aussagen sie nicht blind glauben soll.

Kern:
- Ein 4K-HandBrake-Lauf laeuft GERADE (Akira, Preset "H.265 MKV 2160p60 4K").
  Die vorherige 1080p-Datei wurde dabei auf 0 Bytes gekuerzt; der 75-GB-
  Rohschnitt liegt unversehrt in /app/temp/raw.
- progress=99 am Job ist ein Altwert aus dem Absturz, NICHT der echte Stand.
- Noch nicht bewiesen: dass _original_aufheben() im Ernstfall nur warnt statt
  die Platte vollzuschreiben. Genau dieser Pfad ist neu.
- Gefunden, nicht gebaut: Zombie-Erkennung. Nach dem Absturz stand der Job auf
  "transcoding", obwohl kein Prozess lief und beide Celery-Queues leer waren.
  _kann_neu_komprimieren verlangt status == "failed", deshalb fehlt dem Nutzer
  auch der "Neu komprimieren"-Knopf.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Hitonabi
2026-07-25 20:08:51 +02:00
parent 8bb075c656
commit b526a0a033
+67 -1
View File
@@ -1,6 +1,72 @@
# SAVEPOINT — Rippy # SAVEPOINT — Rippy
## Aktueller Stand: v3.12Preset je Disc-Typ (25.07.2026) ## Aktueller Stand: v3.13ÜBERGABE (25.07.2026, 18:05)
> Dieser Block ist eine Übergabe an die nächste Sitzung. Er trennt bewusst
> **gemessen** von **vermutet** — in dieser Sitzung wurden zwei Behauptungen
> aufgestellt, die sich als falsch erwiesen (siehe „Vertrauensnotiz" unten).
> Im Zweifel: selbst nachmessen, nicht diesem Dokument glauben.
### GEMESSEN, Stand 18:05 (alles per Befehl auf der VM geprüft)
- **Container:** api/postgres/redis/ui/worker alle `Up`, api + postgres +
redis `healthy`.
- **Platte:** `/dev/sda2` 148 G, 105 G belegt, **37 G frei** (75 %).
- **Läuft gerade:** `HandBrakeCLI --input
/app/temp/raw/73b89777-…/title_t00.mkv --output
"/app/media/movies/Akira (1988)/title_t00.mkv" --preset
"H.265 MKV 2160p60 4K" --all-audio --all-subtitles`
- **Job `73b89777-a808-426f-8159-d406d27d0ec8`:** `status='transcoding'`,
`progress=99` (⚠️ **Altwert aus dem Absturz, NICHT der echte Fortschritt** —
der Lauf hat um 18:02 begonnen), `disc_type='uhd'`,
`output_path='/app/media/movies/Akira (1988)'`.
- **Dateien:** `…/Akira (1988)/title_t00.mkv` ist **0 Bytes** (HandBrake hat
die vorherige 1080p-Fassung beim Start gekürzt und schreibt gerade neu).
Roh-Rip `/app/temp/raw/73b89777-…/` = **75 GB, unversehrt.**
- **Git:** `8bb075c` ist HEAD und deployt. Davor `c065967`, `e84afc1`,
`f449c4e`, `0935766`. Alle Ampeln waren grün.
- **Schlüsselspeicher:** 604 Disc-Schlüssel, `/system/keystore` antwortet.
- **NAS:** `//192.168.178.62/rippy` auf `/srv/rippy/media/rippy` gemountet,
erreichbar, **2311 GB frei**. Wird als Ablageziel gelistet.
### WAS ALS NÄCHSTES ANSTEHT
1. **Ausgang des 4K-Laufs prüfen.** Erwartung, die noch NICHT bewiesen ist:
Der Job endet **erfolgreich**, und „Original behalten" (Setting steht auf
`true`) meldet nur eine **Warnung**, weil 75 GB nicht neben 37 GB freien
Platz passen. Genau dieser Pfad ist neu (`_original_aufheben` in
`tasks.py`) und in der Praxis noch nie gelaufen. Wenn er hält, ist der
Ausfall von heute Mittag strukturell behoben.
2. **Zombie-Erkennung fehlt (gefunden, NICHT gebaut).** Nach dem Absturz stand
der Job auf `transcoding 96 %`, obwohl weder ein Prozess lief noch etwas in
den Celery-Queues stand (beide `llen` = 0). Folge: keine Anzeige, kein
Download, und der „Neu komprimieren"-Knopf fehlt, weil
`_kann_neu_komprimieren` (main.py) `status == "failed"` verlangt. Der
Worker sollte beim Start solche Leichen erkennen und ehrlich auf `failed`
setzen.
3. **`keepOriginal` steht auf `true`** — von dieser Sitzung gesetzt, um den
4K-Rohschnitt zu retten. Bewusst entscheiden, ob das so bleibt: mit
Arbeitsverzeichnis auf der NAS-Freigabe wäre es ein reines Umhängen statt
einer Vollkopie.
4. **75 GB Rohschnitt** liegen weiter in `/app/temp/raw/73b89777-…`. Nach
erfolgreichem 4K-Lauf entscheiden, ob er weg kann.
### VERTRAUENSNOTIZ — zwei Fehlschlüsse dieser Sitzung
- **„MakeMKVs Schlüssel-Kanal ist abgeschaltet"** — falsch. Stützte sich auf
zwei tote Hostnamen aus alten Forumsbeiträgen, die MakeMKV längst nicht mehr
benutzt. Richtig: `makemkvcon` unter **Linux** fragt nie, die
**Windows**-Version schon. Korrigiert in v3.11.
- **„Celery hat die Aufgabe nach dem Deploy erneut zugestellt"** — falsch.
Aus dem Status `transcoding` geraten, ohne Prozesse oder Queues zu prüfen.
Es war ein Zombie-Eintrag (Punkt 2 oben).
Beide Male war das Muster dasselbe: **aus einem Zustandswert auf einen
Mechanismus geschlossen, statt den Mechanismus zu messen.**
---
## Vorheriger Stand: v3.12 — Preset je Disc-Typ (25.07.2026)
- **Der Fund:** Beim ersten echten UHD-Rip aufgefallen — die Kompression - **Der Fund:** Beim ersten echten UHD-Rip aufgefallen — die Kompression
fragte den Disc-Typ **gar nicht**: `preset = einstellungen.get( fragte den Disc-Typ **gar nicht**: `preset = einstellungen.get(