diff --git a/SAVEPOINT.md b/SAVEPOINT.md
index 173b183..d4270a1 100644
--- a/SAVEPOINT.md
+++ b/SAVEPOINT.md
@@ -50,11 +50,37 @@ macht wie der Code, prüft nichts.**
 Schnappschuss nicht — und das Dashboard liest den Schnappschuss. Ein Test
 zählt jetzt die Aufrufe; bei zwei ist er rot.
 
-### Zwei Dinge, die offen bleiben
+### Nachtrag: die Wartezeit ist jetzt sichtbar
 
-**Die Disc-Erkennung dauert rund zwei Minuten** — `makemkvcon info` läuft in
-seine 120-Sekunden-Grenze. Kein Fehler, aber lange genug, dass es wie einer
-aussieht.
+> „das die disc erkennung noch läuft muss sichtbar sein"
+
+Die Erkennung dauert rund zwei Minuten (`makemkvcon info` läuft in seine
+120-Sekunden-Grenze; gemessen: Disc nach 119 s da). Zwei Minuten, in denen
+**nichts** zu sehen war — das sah aus wie ein leeres Laufwerk.
+
+Der Zustand war sogar schon da: Rippy merkt sich beim Start „läuft gerade".
+Nur ließ die Laufwerksliste so einen Eintrag komplett weg, damit keine
+halbfertige Disc-Karte erscheint. Richtig gedacht, falsch gelöst.
+
+Jetzt: eine Karte mit Spinner („Disc wird gelesen — Laufwerk G:") und eine
+eigene Zeile im Server-Status — ohne einen Titel zu behaupten, den es noch
+nicht gibt.
+
+**Der Haken dahinter:** Genau während der Erkennung hält makemkvcon das
+Laufwerk, `/devices` braucht dann **14 s** statt der 5 s Zeitgrenze. Der
+Schnappschuss meldete „konnte nicht nachsehen", und nach einem frischen Laden
+blieb der Bildschirm leer — ausgerechnet in der Phase, die sichtbar sein
+soll. Rippy antwortet dort jetzt ohne Laufwerkszugriff: letzter bekannter
+Stand plus die aktuelle Marke.
+
+### Beobachtung am Rande
+
+Beim Testen blieben zweimal **verwaiste `makemkvcon64`-Prozesse** aus
+abgebrochenen Läufen stehen. Solange die leben, blockieren sie **jeden**
+Laufwerkszugriff. Nicht angefasst — sag Bescheid, wenn Rippy die beim Start
+aufräumen soll.
+
+### Was offen bleibt
 
 **Dein MakeMKV 1.18.4 ist zu alt** für den aktuellen Beta-Key (unverändert
 seit rc5); makemkv.com antwortet weiter mit HTTP 525.