diff --git a/SAVEPOINT.md b/SAVEPOINT.md
index 7d539ee..f180bc5 100644
--- a/SAVEPOINT.md
+++ b/SAVEPOINT.md
@@ -29,6 +29,28 @@
 - **NAS:** `//192.168.178.62/rippy` auf `/srv/rippy/media/rippy` gemountet,
   erreichbar, **2311 GB frei**. Wird als Ablageziel gelistet.
 
+### NACHTRAG 18:35 — der 4K-Lauf wurde abgebrochen, zwei neue Befunde
+
+- **4K-HEVC ist auf dieser CPU nicht machbar.** Gemessen: von 18:02 bis 18:31
+  kam der Lauf von 0 auf **1 %** → hochgerechnet **~50 Stunden** für den Film.
+  Der Commander hat um 18:31 abgebrochen. **Konsequenz, die noch zu
+  entscheiden ist:** entweder UHD gar nicht komprimieren (Roh-MKV behalten,
+  `transcodeEnabled` für UHD aus), oder ein Hardware-Encoder (Remote-Worker
+  mit GPU, `nvenc`/`vaapi`), oder bewusst bei 1080p bleiben. Das eben
+  gebaute Preset-je-Disc-Typ ist damit richtig, aber allein nicht genug.
+- **Abbruch wirkt verzögert (FEHLER, nicht gebaut).** Job steht seit 18:31 auf
+  `canceling`, **HandBrake lief um 18:35 immer noch**. Ursache: Der Abbruch
+  wird nur in `datei_fortschritt` geprüft, und diese Closure läuft nur, wenn
+  sich die PROZENTZAHL ändert (`tasks.py`, `if gesamt == letzter[0]: return`).
+  Bei 1 % alle 30 Minuten heißt das: bis zu eine halbe Stunde, in der
+  „Abbrechen" für den Nutzer wirkungslos aussieht. Der Abbruch muss unabhängig
+  vom Fortschritt geprüft werden (z. B. zeitgesteuert beim Lesen der
+  HandBrake-Ausgabe).
+- **Die 1080p-Fassung ist weg.** HandBrake hat sie beim Start auf 0 Bytes
+  gekürzt; aktuell liegen dort ~64 MB 4K-Fragment. Der **75-GB-Rohschnitt ist
+  unversehrt** — es ist also nichts unwiederbringlich verloren, aber im
+  Akira-Ordner liegt gerade eine unbrauchbare Datei.
+
 ### WAS ALS NÄCHSTES ANSTEHT
 
 1. **Ausgang des 4K-Laufs prüfen.** Erwartung, die noch NICHT bewiesen ist: