docs(savepoint): v3.17 - neun Punkte zu, vier Bestandsfehler dazu
Ampel / ampel (push) Successful in 27s
Ampel / ampel (push) Successful in 27s
Der Savepoint trennt wie immer gemessen von vermutet - und stellt zwei Behauptungen aus v3.16 richtig, die sich als falsch erwiesen haben: 1. "Die Namen der Hardware-Presets sind auf der Rippy-VM nicht ermittelbar." Falsch - `--preset-list` nennt sie vollstaendig, auch ohne Hardware-Encoder. Der vermeintliche Blocker fuer Punkt 1 existierte nicht. 2. "Rohschnitt intakt -> 'Neu komprimieren' genuegt." Falsch - can_retry war false, den Knopf gab es nicht. AGENTS.md bekommt zwei neue Lehren aus dieser Sitzung: Hintergrund-Schleifen muessen ihre Fehler melden (ein stiller except hat eine Stunde gekostet), und Netz-Pfade nie ungebremst anfassen - os.path.isdir haengt auf einem toten CIFS im Kernel und laesst sich aus Python nicht abbrechen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
@@ -55,7 +55,7 @@ Bibliotheks-APIs: `--help`/Doku prüfen und die Fundstelle im Commit nennen.
|
||||
- Kein Proxmox-LXC-Nesting-Workaround — das Projekt lebt bewusst in normalem Docker.
|
||||
- Kein ARM-Fork — Rippy ist ein Eigenbau von Grund auf.
|
||||
|
||||
## Aktueller Stand (25.07.2026)
|
||||
## Aktueller Stand (26.07.2026)
|
||||
|
||||
- ✅ **E2E bewiesen (v3.1):** BD-50 komplett durch die Kette (43 GB → 4,8 GB)
|
||||
- ✅ **Etappe 13 (v3.2):** Universal-Komfort-Runde — Media-Server-Integration,
|
||||
@@ -73,6 +73,11 @@ Bibliotheks-APIs: `--help`/Doku prüfen und die Fundstelle im Commit nennen.
|
||||
- ✅ **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
|
||||
- ✅ **Etappe 21 (v3.17):** Der Blocker externes Encoden ist zu —
|
||||
`RIPPY_PATH_MAP` leitet Rippy aus seinen eigenen Mounts ab, der Installer holt
|
||||
es selbst; Presets kommen vom Worker statt aus dem Quelltext; Dashboard ohne
|
||||
Placebos, mit Restzeit. Dazu vier Bestandsfehler, alle live gemessen (u. a.
|
||||
„Neu komprimieren" ging nie, und `os.path.isdir` hing im Kernel)
|
||||
- 📝 **Details immer in SAVEPOINT.md** — diese Sektion nennt nur die Etappe
|
||||
|
||||
## Was diese Sitzungen wiederholt gekostet hat
|
||||
@@ -87,3 +92,19 @@ Jedes Mal hätte eine Messung von unter einer Minute gereicht.
|
||||
**Und die Umkehrung gilt genauso:** gleiches `st_dev` heißt NICHT gleicher
|
||||
Mount. Wo eine Eigenschaft ausprobierbar ist, probiere sie aus, statt sie
|
||||
vorherzusagen.
|
||||
|
||||
**Ein Hintergrund-Prozess, der still scheitert, ist schlimmer als einer, der
|
||||
laut scheitert** (26.07.2026). Ein `except Exception: pass` in einer
|
||||
Vorrats-Schleife hat eine Stunde gekostet: Der Vorrat blieb leer, die Funktion
|
||||
lief direkt aufgerufen einwandfrei, und der Grund stand nirgends. Gefunden erst
|
||||
über die Thread-Zustände (`/proc/<pid>/task/*/stat`, Zustand `D` = im Kernel
|
||||
blockiert). Jede Hintergrund-Schleife MELDET ihren Fehler, und wer einen Vorrat
|
||||
anlegt, macht sein Alter abfragbar (`GET /health/vorraete`) — sonst ist am
|
||||
Endpunkt selbst nichts zu sehen.
|
||||
|
||||
**Netz-Pfade nie ungebremst anfassen.** `os.path.isdir`/`open` auf einem toten
|
||||
CIFS-Mount blockieren im Kernel und lassen sich aus Python NICHT abbrechen. Ein
|
||||
Kind-Prozess lässt sich abbrechen: `timeout N ls -d <pfad>` (Muster in
|
||||
`mounts.ist_erreichbar` und `rohdaten.verzeichnis_da`). Und „konnte nicht
|
||||
nachsehen" ist etwas anderes als „ist nicht da" — beides zu vermischen erzeugt
|
||||
falsche Aussagen im UI.
|
||||
|
||||
Reference in New Issue
Block a user