From 21b1757aa46b43c136ee99476b77985224538402 Mon Sep 17 00:00:00 2001 From: Hitonabi Date: Sat, 29 Aug 2026 14:15:58 +0200 Subject: [PATCH] =?UTF-8?q?docs(savepoint):=20v4.0-rc6=20=E2=80=94=20leere?= =?UTF-8?q?r=20Bildschirm=20und=20zwei=20weitere=20Container-Wurzeln?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 5 --- SAVEPOINT.md | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 68 insertions(+), 1 deletion(-) diff --git a/SAVEPOINT.md b/SAVEPOINT.md index 1308118..863e359 100644 --- a/SAVEPOINT.md +++ b/SAVEPOINT.md @@ -1,6 +1,73 @@ # SAVEPOINT — Rippy -## Aktueller Stand: v4.0-rc5 — **Rippy rippt** (29.08.2026) +## Aktueller Stand: v4.0-rc6 — leerer Bildschirm behoben (29.08.2026) + +> **Dein Befund war zweimal richtig und einmal irreführend:** Der Bildschirm +> war wirklich leer — aber der Rip lief. Man sah ihn nur nie. + +### Der leere Hintergrund + +Nachgestellt auf einem Testdienst hier, nicht bei dir. Nach dem Klick auf +„Rippen starten" stand in der Browser-Konsole: + + TypeError: Cannot read properties of undefined (reading 'toUpperCase') + +Und währenddessen, direkt an der Schnittstelle gemessen: + + status: processing · progress: 12 + +**Er startet also sehr wohl.** Die Oberfläche war nur weg, bevor sie es zeigen +konnte. + +Die Ursache: Das Ereignis „Job angelegt" trug nur Status, Fortschritt, Titel +und Fehler — **keinen Typ**. Die Oberfläche fügt so einen halben Job in ihre +Liste ein, das Live-Log liest `job.type.toUpperCase()`, und React baut bei +einem Fehler im Zeichnen den **ganzen** Baum ab. Eine Fehlergrenze, die das +auffängt, gab es in diesem Projekt nirgends — deshalb leerer Bildschirm ohne +jede Meldung. + +Drei Reparaturen, weil es drei Fehler waren: + +1. **Das Ereignis trägt den Job** — Typ, Laufwerk und Startzeit fahren mit. + Sie ändern sich nie, kosten also kein zusätzliches Ereignis; ohne die + Startzeit stand in der Jobliste sekundenlang „Invalid Date". +2. **Die Oberfläche verträgt sein Fehlen.** Zeile 108 derselben Datei hatte + die Absicherung längst, Zeile 48 nicht. +3. **Eine Fehlergrenze.** Jetzt steht da, was los ist, die Navigation bleibt + bedienbar, und der Hinweis sagt das Wichtigste: *laufende Rips gehen + weiter*. + +Warum es niemand gefunden hat: Die Tests reichten der Vergleichsfunktion +immer ihre eigenen Wörterbücher herein — **die Kurzform selbst war nie +geprüft.** Jetzt bewacht ein Vertrag die Felder mechanisch. + +### Der zweite Fund: `F:\app\temp` + +Beim Aufräumen des Testlaufs fand ich 436 MB Rohdaten in einem Ordner namens +`app` auf dem Laufwerk, von dem Rippy gerade lief. Zwei weitere +Container-Wurzeln: + + RAW_DIR = /app/temp/raw + MEDIA_ROOT = /app/media + +Und schlimmer als der falsche Standard: Die Prüfung verwarf **auch eine +ausdrückliche Wahl**. `D:\Roh` liegt nicht unter `/app/media`, also fiel es +still zurück. + +**Damit kam der Arbeitsordner, den du gestern bestellt hast, unter Windows nie +an.** Der Dialog zeigte ihn, das Setzen ging, der Worker ignorierte ihn — ohne +ein Wort. Dasselbe galt fürs Ziel: Deine UNC-Freigabe liegt unter keiner +lokalen Wurzel, die fertige Datei wäre in `X:\app\media\bluray` gelandet. + +Jetzt kommen beide Wurzeln aus dem Betrieb. Im Container ändert sich nichts. + +### Aufgeräumt + +Ich habe für die Prüfung zweimal einen echten Rip auf deinem Laufwerk +gestartet und beide sofort abgebrochen. Die 436 MB Rohdaten und der Ordner +`F:\app` sind entfernt, die Testdienste beendet. + +## Letzter Stand davor: v4.0-rc5 — **Rippy rippt** (29.08.2026) > **Der erste bewiesene Rip unter Windows.** Dein Fehlerbericht enthielt drei > Fehler auf einmal — alle drei gefunden, behoben und an deinem Laufwerk