diff --git a/SAVEPOINT.md b/SAVEPOINT.md
index 0c396d6..5ca3224 100644
--- a/SAVEPOINT.md
+++ b/SAVEPOINT.md
@@ -1,5 +1,121 @@
 # SAVEPOINT — Rippy
 
+## Disc-Erkennung repariert — Version 5.1.1 (01.09.2026)
+
+> Der Commander legte **Disc 2 von „Spartacus: Gods of the Arena"** ein,
+> Rippy meldete den **Film „Spartacus" von 1960**. Er schlug vor, Discs
+> künftig über ihre EAN/Barcode-Nummer zu erkennen. Die Messung zeigte:
+> Das braucht es nicht — **die Disc trug die richtige Antwort die ganze
+> Zeit selbst mit sich, Rippy las nur eine Zeile davon.**
+
+### Warum der Barcode nicht die Antwort war
+
+Der Barcode steht auf der HÜLLE, nicht auf der Scheibe. Ein Laufwerk
+liest die Scheibe. Für DVD und Blu-ray gibt es keinen Weg an die EAN.
+(Ausnahme, notiert und nicht gebaut: Audio-CDs tragen im Subchannel eine
+Media Catalog Number — das IST der UPC/EAN. Als Auffangnetz für
+unbekannte MusicBrainz-Kennungen später denkbar; TMDb und OMDb können
+ohnehin keine Barcode-Suche, dafür bräuchte es eine Produktdatenbank als
+Zwischenstufe mit fraglicher Abdeckung deutscher Editionen.)
+
+### Was tatsächlich kaputt war (Laufwerk G:, `SPARTACUS_GOTA_D2`, UDF, 33 759 100 928 B)
+
+Rippy las korrekt `Spartacus: Gods Of The Arena - Disc 2` und baute
+daraus Suchvarianten — der Doppelpunkt-Vorspann stand auf **Platz 2**:
+
+```
+[0] Spartacus: Gods Of The Arena - Disc 2
+[1] Spartacus                              <- hier war Schluss
+...
+[5] Spartacus: Gods Of The Arena           <- der richtige, nie gefragt
+```
+
+TMDb hat einen Film, der wörtlich „Spartacus" heißt → wörtlicher
+Treffer → **0,95** → fertig. Der Fix vom 30.08. (`Reihenfolge JE
+KANDIDAT`) griff nicht, weil er die Kandidaten-LISTE nicht anfasste; der
+damalige Test benutzte einen geschönten Titel (ohne Doppelpunkt, ohne
+`- Disc 2`) und lief deshalb grün.
+
+### Die vier Ursachen (`38a3a87`, Ampel GRÜN, 225 Tests)
+
+1. **Die Sicherheit maß die ART des Treffers, nie die QUALITÄT der
+   Frage.** Neu: `abdeckung()` + `MINDEST_ABDECKUNG` (0,5) — wer mehr
+   als die Hälfte des Titels wegwerfen musste, bekommt höchstens einen
+   Vorschlag (0,60) und das UI fragt nach. Maßstab ist der Titel OHNE
+   Verpackungs-Zusatz.
+2. **Verpackungs-Zusätze galten als Wortmüll.** Neu:
+   `discZusatzAbtrennen()` trennt `- Disc 2` / `_D2` / `S1` ab UND merkt
+   sie. Vier Fallen sind mit Tests abgesichert: `Rocky 2` (nackte Zahl),
+   `Kill Bill Teil 2` (Teil/Part sind Titel-Wörter), `Ocean's 11`
+   (Apostroph-Wortgrenze — die Ein-Buchstaben-Formen `d`/`s` verlangen
+   deshalb einen Trenner davor), `Pulp Fiction`.
+3. **Der Titelvergleich war zeichengenau.** Ein Volume-Label KANN keinen
+   Doppelpunkt tragen, TMDb schreibt ihn — der exakt richtige Treffer
+   fiel an einem Satzzeichen durch. Neu: `gleichBedeutend()`. Vergleicht
+   die Wort-FOLGE, nicht die Wort-MENGE (sonst wäre `New York, New York`
+   gleich `New York`).
+4. **Rippy öffnete das Inhaltsverzeichnis der Disc und las nur die erste
+   Zeile.** Neu: `inhaltAusBdmt()` liest auch `<di:titleName>`.
+   `EP 1`/`EP 2` beweisen die Serie, `DUB GER 1`/`101 LOGO`/`104 GER FSK`
+   nicht (`istFolgenName` ist bewusst eng). Ab zwei Folgen ist „Serie"
+   BEWIESEN — dann sind die Film-Zweige der Kaskade AUS.
+
+Disc-Nummer, Staffel und Folgenzahl stehen jetzt auch im Fenster
+(Kachel neben der Erkennung) und überleben eine eigene Titelwahl.
+
+### Der Beweis an der echten Disc
+
+Neu: `test/messung.disc-erkennung.test.ts` (nur Windows, nur auf
+Verlangen — `RIPPY_MESSUNG_DISC=G npx vitest run …`):
+
+```
+Titel "Spartacus: Gods Of The Arena - Disc 2" (Quelle: bdmt)
+Disc 2 | Staffel — | Folgen 2 | Serie bewiesen: true
+Inhalt: EP 1 | EP 2 | MM ITA | ILSM | DUB GER 1 | DUB GER 2 | DUB FRE 1
+        | DUB FRE 2 | DUB ITA | 101 LOGO | 102 DUTCH BREIN
+        | 103 DUTCH AGE | 104 GER FSK | 105 WARNINGS
+Varianten: "…- Disc 2" -> "…Arena" -> "Spartacus Gods…" -> … -> "Spartacus"
+```
+
+Deckt sich mit der Disc-Struktur: genau zwei große Ströme (`00047.m2ts`
+15,76 GB, `00048.m2ts` 14,89 GB), alles andere unter 200 MB.
+
+**Geänderter Bestandstest:** Der alte Spartacus-Test erwartete 0,80. Er
+erwartet jetzt 0,90 — durch den satzzeichen-toleranten Vergleich ist es
+ein WÖRTLICHER Serientreffer. Die Absicht bleibt, die Prüfung wird
+strenger.
+
+### Das Setup 5.1.1
+
+* `rippy-windows/dist-setup/RippySetup-5.1.1.exe`
+* Größe **131 526 527 Bytes**
+* SHA-256 `04CB1D302616FB67DE217AE26D50B567350177CAE9801C3FDC6FE9EA04C26F88`
+* sha512 (in `latest.yml`) `GiUmrSDr/c/fTai0pJhZEr5dZuy1pUyApcFnGO1x9Kv1aKBLFXTZch8VU7rSp1wvOhZh687DhOklE4v5MIo/Pg==`
+* Paket-Smoke GRÜN: `fenster=geladen kern=pid,node:24.18.1 datenbank=ok
+  leine=gesetzt pong=ok version=5.1.1`
+* `latest.yml` und `w0.yml` liegen daneben, beide auf 5.1.1
+
+### ⚠ OFFEN: Das Release ist NOCH NICHT hochgeladen
+
+Der Upload braucht Schreibrechte an der Gitea-API. Der gespeicherte
+Zugang (`git credential fill`, Host
+`git.tobisniceshomelab.ddnsfree.com`) ist ein **13-stelliges Passwort,
+kein API-Token** — Gitea antwortet darauf mit HTTP 401. Es fehlt ein
+Token aus *Einstellungen → Anwendungen → Zugangstoken* mit Recht
+`write:repository`.
+
+Release `aktuell` (ID 1, Ziel `worktree-windows-electron`) enthält noch
+5.1.0. `latest.yml` wurde dort bereits **2× abgerufen** — die
+installierte 5.1.0 fragt also nachweislich nach Updates, der Kanal lebt.
+
+**Zu tun:** `RippySetup-5.1.1.exe` + `.blockmap` hinzufügen, `latest.yml`
+und `w0.yml` ERSETZEN (Namenskollision → erst löschen). Die 5.1.0-EXE
+darf liegen bleiben, sie ist die Rückfallebene. Danach ist es der erste
+echte Selbst-Update-Beweis (§ 6.8) — und misst zugleich, ob Gitea 1.27
+das `releases/latest/download`-Muster bedient (§ 3.6 ⚠).
+
+---
+
 ## ÜBERGABE an die nächste Session (31.08.2026, Sessionende)
 
 > Diese Session ist abgeschlossen und ihr Arbeitsordner