docs: SAVEPOINT — Disc-Erkennung repariert, 5.1.1 gebaut
Ampel / ampel (push) Successful in 1m37s

Ampel gruen fuer 38a3a87, Paket-Smoke gruen, Setup liegt in dist-setup.
Offen bleibt allein der Release-Upload: der gespeicherte Gitea-Zugang ist
ein Passwort, kein API-Token (HTTP 401).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Hitonabi
2026-09-01 17:36:46 +02:00
co-authored by Claude Opus 5
parent 38a3a87f70
commit 4f943e2c4f
+116
View File
@@ -1,5 +1,121 @@
# SAVEPOINT — Rippy # 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) ## ÜBERGABE an die nächste Session (31.08.2026, Sessionende)
> Diese Session ist abgeschlossen und ihr Arbeitsordner > Diese Session ist abgeschlossen und ihr Arbeitsordner