Der Schalter, den es nicht gibt — und vierzehn weitere Funde aus demselben
Rundgang. Jeder mit der Messung, an der er haengt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Commander: „go"
Die Dateien hiessen `Track 01.flac`. Eine Musiksammlung ohne Titel ist eine
Sammlung von Nummern.
## Wie MusicBrainz eine CD wiedererkennt
Nicht am Namen (den kennt die CD nicht) und nicht an einer Kennung auf der
Disc (die gibt es nicht), sondern an der LAGE ihrer Spuren. Daraus wird ein
Fingerabdruck gerechnet — SHA-1 ueber die Versaetze, base64 mit eigenem
Alphabet (musicbrainz.org/doc/Disc_ID_Calculation).
## Belegt OHNE Audio-CD
MusicBrainz gibt zu jeder bekannten Kennung die Spurlage heraus, aus der sie
gerechnet wurde. Wer die Lage zurueckbekommt und daraus dieselbe Kennung
rechnet, hat die Rechnung belegt:
Spurlage „Back in Black" (abgefragt) -> 3KVSIWn_ewv9z0cCizmOJzDWtsQ-
MusicBrainz sagt dazu -> 3KVSIWn_ewv9z0cCizmOJzDWtsQ-
Und die ganze Kette am Stueck, mit echtem Encoder:
Ordner ACDC - Back in Black
Dateien 01 - Hells Bells.flac, 02 - Shoot to Thrill.flac, …
Tags TITLE/ARTIST/ALBUM/ALBUMARTIST/DATE/TRACKNUMBER
— mit metaflac aus der FERTIGEN Datei zurueckgelesen
## Zwei Fallen
**Der Vorlauf.** Die Kennung rechnet MIT den 150 Frames, das Lesen OHNE. Wer
das verwechselt, bekommt eine Kennung, die niemand kennt — und zwar ohne
Fehlermeldung, denn die Antwort ist dann schlicht „unbekannte Disc".
**`AC/DC`.** Als Ordnername haette der Schraegstrich unter Windows einen
Unterordner aufgemacht. Aufgefallen NUR, weil der Beweis den Namen ausgegeben
hat. Jetzt saeubert `sauberer_name` beides — Datei und Ordner.
## ⚠️ Mein Fehler dabei
Die Spurlage im Test hatte ich zuerst ERFUNDEN: Beim Beweis hatte ich nur
Spurzahl und Lead-Out ausgegeben und den Rest „passend" ergaenzt. Der Test
wurde prompt rot — zu Recht. Die Zahlen stehen jetzt so drin, wie MusicBrainz
sie herausgibt (erste Spur bei 182, nicht bei 150: diese Pressung hat einen
laengeren Vorlauf).
Ohne Treffer bleibt es bei `Track 01.flac`. Eine unbekannte Disc ist kein
Fehler, und ein Netzausfall darf keinen Rip umwerfen.
932 Tests gruen, ruff sauber.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Commander: „mach es"
Gemeint war die Lücke, die seit Wochen so im SAVEPOINT stand: **Audio-CDs
laufen unter Windows nicht.** `cdparanoia` und `abcde` sind Linux-Werkzeuge.
## Nicht abcde nachbauen — den Windows-Weg gehen
Eine Audio-CD hat kein Dateisystem. Die `Track01.cda`, die Windows zeigt,
sind 44 Byte grosse Platzhalter; die Musik liegt roh in 2352-Byte-Sektoren.
Windows bietet dafuer zwei Steuercodes an:
IOCTL_CDROM_READ_TOC Inhaltsverzeichnis (MSF je Spur, Audio/Daten)
IOCTL_CDROM_RAW_READ die Sektoren selbst
Gegengeprueft, dass die berechneten Codes den dokumentierten entsprechen:
0x24000 und 0x2403e.
Kodiert wird mit dem FLAC-Encoder vom offiziellen Xiph-Spiegel (1.5.0), den
Rippy beim Einrichten holt — wie MakeMKV. KEIN Pflichtwerkzeug: Ohne ihn
laeuft alles ausser Audio-CDs, und ein Fehlschlag darf das Einrichten nicht
truebe machen.
## Zwei Fallen, beide gemessen
**Die Leseadresse zaehlt in 2048er-Einheiten**, obwohl ein Audio-Sektor 2352
Bytes hat. Das ist dokumentiert und sieht falsch aus; mit 2352 liest man an
der falschen Stelle.
**`flac.exe` braucht `libFLAC.dll` daneben.** Mit nur der exe endete jeder
Aufruf mit 0xC0000135 — „DLL nicht gefunden" — und zwar ohne eine einzige
Zeile Ausgabe. Jetzt wird der ganze Win64-Ordner ausgepackt.
## Was geprueft ist
Ein Laufwerk und eine Audio-CD lassen sich in der Ampel nicht herstellen.
Deshalb steht alles Rechenbare in reinen Funktionen — MSF↔LBA, das Zerlegen
der TOC-Bytes, WAV-Kopf, Blockaufteilung, Dateinamen — und der Ablauf
bekommt Laufwerk und Encoder eingespritzt. 28 Tests dafuer.
Zusaetzlich mit dem ECHTEN Encoder gemessen: zwei Spuren erzeugten Tons
gerippt, und **FLAC bestaetigt seine eigenen Dateien** (`flac -t`, Code 0).
Am echten Laufwerk gegengeprueft, dass das Inhaltsverzeichnis gelesen wird —
die eingelegte Blu-ray meldet sich korrekt als DATEN-Track und wird nicht als
Musik behandelt.
Was noch fehlt: MusicBrainz-Tags. Die Dateien heissen `Track 01.flac`. Der
Weg dafuer steht (`tags_je_spur`), die Disc-Kennung fuer die Abfrage nicht.
915 Tests gruen, ruff sauber.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Stand vor dem Test des Commanders. Zwei Dinge stehen bewusst gross drin:
die seit V2-1 tote Metadaten-Suche (betrifft die VM genauso) und die
bekannte Luecke bei Audio-CDs unter Windows.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die drei Befunde des Commanders und was dahinter steckte, plus der teuerste
Fund des Tages: %ProgramFiles(x86)% wurde auf einer echten Maschine NIE
aufgeloest, weil der Test genau die Schreibweise einspritzte, die im Muster
stand. Er war gruener als die Wirklichkeit.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Nachgetragen: die 28 Linux-Fehler, der schwerste davon (der API-Container
waere auf der VM gar nicht hochgekommen), und die Lehre daraus — ein Test,
der nur auf einer Plattform greift, ist eine halbe Zusage.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der SAVEPOINT stand seit V2-3 still, waehrend elf Commits dazukamen.
Nachgetragen mit den gemessenen Zahlen: 562 gruen, RippySetup.exe 31,7 MB,
WebView2 151.0.4129.107, 5 Encoder auf diesem PC.
Zwei Dinge stehen bewusst gross drin, weil sie sonst verloren gehen:
* Der Dienst, der /api/health mit 200 beantwortete und / mit 404 -- und
warum ein %TEMP%-Verzeichnis kein Ort fuer eine Oberflaeche ist.
* Der Test, der den PC des Commanders getroffen hat. Ein Test, der Spuren
ausserhalb von tmp_path hinterlaesst, ist kein Test, sondern ein Eingriff.
Und was NICHT bewiesen ist, steht als solches da: Ein echter Rip unter
Windows ist nie gelaufen, die VM haengt elf Commits zurueck.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Vier Etappen gebaut und deployt, Polling ist weg (121 Anfragen/min je Tab
-> ~2 einmalige Abrufe), SSE-Strom live belegt.
Wichtig fuer die naechste Sitzung: Das optische Laufwerk haengt NICHT mehr
an der VM. Rippy laeuft als reine Komprimier-Maschine. Und der Vorfall,
der das aufgedeckt hat, ist dokumentiert — ein devices:-Eintrag in compose
ist eine Startbedingung, und die hat api, worker und ui stillgelegt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
WAS: Neuer Kopfeintrag mit dem gemessenen Zustand (b98dc5e, Ampel gruen,
290 Tests, 0 doppelte Module), den drei Commander-Entscheiden, der
gebauten Etappe V2-0 und dem naechsten Schritt.
WARUM: AGENTS-Workflow Punkt 5 — die naechste Sitzung faengt nicht bei
Null an. Besonders wichtig diesmal, weil der Deploy auf die VM bewusst
aussteht und beim ersten Deploy nach V2-0 zwei Dinge gezielt zu pruefen
sind (liegt /app/rippy in beiden Containern, enthaelt das Worker-Zip
den Ordner).
Dokumentiert ist ausserdem der Fehler, den der Umbau fast ausgeliefert
haette: ein "try/except ImportError" um den detection-Import in
tasks.py haette einen falschen Modulpfad STILL geschluckt und auf Linux
jeden Rip verweigert. Die Lehre steht dabei — bei einem Modul-Umzug
reicht grep auf Zeilenanfaenge nicht.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
40,9 GB Rip -> Auswurf -> Kompression auf dem Windows-PC -> 12,29 GB abgelegt,
Roh-Verzeichnis danach automatisch aufgeraeumt. Die Sprachwahl am ERGEBNIS
nachgeprueft (HandBrakeCLI --scan auf die abgelegte Datei): nur noch deutsche
Ton- und Untertitelspuren, kein Japanisch, keine unbenannten - vorher meldete
der Disc-Scan deu 4x, jpn 2x, und 4x.
Ein Fund aus dem Ergebnis, bewusst NICHT still repariert: Der Ton ist fuenfmal
MP3 2.0 mit 160 kbps. Das Preset "HQ 1080p30 Surround" schreibt laut
--preset-export zwei Regeln vor (av_aac stereo 160 / Surround 640); angewandt
wurde nur die erste, auf jede behaltene Spur. Der Surround-Ton eines Presets
namens "Surround" faellt damit still weg. Warum der Encoder MP3 statt av_aac
wurde, ist ungeklaert - Rippy uebergibt keinen Audio-Schalter. Als offener
Punkt notiert statt geraten; die Preset-Wahl ist eine Entscheidung des
Commanders.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Belegt: Auswurf im automatischen Weg (bisher nur der UI-Knopf), Phasen-Marke
springt bei der Uebergabe auf true, Sprachwahl kommt beim externen Encoder an
("Ton: deu, Untertitel: deu"), Mount-Wache heilt in 4,2 s.
Gefunden: Jeder erste Film in einer neuen Ablage war unerreichbar - die Pruefung
liess nur eine fehlende Ordner-Ebene durch, obwohl makedirs die ganze Kette
anlegt. Der Fehler wartete seit v3.17 darauf, dass jemand eine frische Ablage
benutzt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die "Substantial drift 7200 seconds"-Meldung kam nicht alle paar Sekunden,
sondern einmal pro Absender-Hostname (celery memoized nach hostname) - und der
Container-Hostname wechselt bei jedem Neubau. Die vier Meldungen im Log sind
genau vier Deploys.
Der Beweis, dass sie weg ist: Um 14:57:33 synchronisierte sich der Worker mit
celery@d160eb2f3afd, dem frischen Container nach dem Deploy. Ein NEUER Hostname
umgeht die Merk-Sperre, die Warnung haette also feuern muessen. Sie kam nicht.
Dazu gemessen: TZ=UTC wirkt auf Windows wirklich (time.timezone -3600 -> 0), und
die celery-Zeitstempel im lokalen Worker-Log stehen in UTC.
Ausserdem festgehalten: Der Windows-Worker laeuft auf gemischten Dateistaenden
(tasks.py 13:19, ripping.py 14:06, zombies.py 14:17) - die Sprachwahl ist
vollstaendig drin, meta_merken fehlt noch. Es fehlt eine Versionsanzeige, die
so etwas sichtbar macht, statt es nur beim Nachsehen auf dem PC zu finden.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
SAVEPOINT v3.20 mit den Messwerten: /jobs und /capabilities byteweise identisch
ueber zwanzig Sekunden (es lud also nichts neu), 97 Antworten mit HTTP 429 im
nginx-Log, 812 von 876 Anfragen scheinbar von einer IP, und die Rechnung, die
zeigt warum: ein offener Tab braucht 123 Anfragen/min, erlaubt waren 100.
Dazu drei neue Lehren in AGENTS.md:
- Ein verpasster Abruf ist keine Nachricht ueber die Welt (`catch(() => [])`).
- Eine eigene Schutzbremse gegen die eigene Last rechnen - und jedes Greifen
protokollieren, sonst ist sie unsichtbar.
- Eine geschluckte Warnung ist eine Falle (`|| echo` in einem 200-Zeilen-Log).
- Und: wenn der Commander eine Korrelation nennt, ist das eine Spur, auch wenn
seine vermutete Erklaerung daneben liegt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Savepoint haelt fest, was gemessen wurde und was nicht. Die wichtigste Lehre
steht auch in AGENTS.md: Bei "zu langsam" die DAUER je Schritt messbar machen
statt die plausibelste Ursache zu beheben. Meine erste Erklaerung fuer die 150 s
war falsch und machte es sogar langsamer (202 s); erst Zeitstempel im Log zeigten
die Stelle - ein os.makedirs, das drei Minuten im Kernel hing. Danach 8 s.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Stellt eine Aussage aus v3.17 richtig: Dort stand die Mount-Sache als "Ursache
liegt beim NAS, nicht gefunden". Gemessen liegt sie bei uns - die CIFS-Verbindung
lebt in der Netz-Namespace des api-Containers und stirbt mit ihm. Das NAS ist
unschuldig.
AGENTS.md bekommt die Lehre, die diesen Abend zweimal gekostet hat: Ein
Rueckgabewert ist kein Beweis, wo die Wirkung pruefbar ist. CDROMEJECT quittiert
Erfolg auf einem verriegelten Laufwerk, `mount` quittiert Erfolg auf einer
Verbindung, die Sekunden spaeter stirbt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Savepoint trennt wie immer gemessen von vermutet - und stellt zwei
Behauptungen aus v3.16 richtig, die sich als falsch erwiesen haben:
1. "Die Namen der Hardware-Presets sind auf der Rippy-VM nicht ermittelbar."
Falsch - `--preset-list` nennt sie vollstaendig, auch ohne Hardware-Encoder.
Der vermeintliche Blocker fuer Punkt 1 existierte nicht.
2. "Rohschnitt intakt -> 'Neu komprimieren' genuegt." Falsch - can_retry war
false, den Knopf gab es nicht.
AGENTS.md bekommt zwei neue Lehren aus dieser Sitzung: Hintergrund-Schleifen
muessen ihre Fehler melden (ein stiller except hat eine Stunde gekostet), und
Netz-Pfade nie ungebremst anfassen - os.path.isdir haengt auf einem toten CIFS
im Kernel und laesst sich aus Python nicht abbrechen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Rueckfrage des Commanders: "Was ist mit diesen ganzen Sachen?" - er wollte
wissen, ob seine Liste aus der ersten Selbst-Einrichtung vollstaendig erfasst
ist. Nachgeprueft: alle neun Punkte kommen im v3.16-Block vor.
Einer war aber nur IMPLIZIT zu finden: dass seine RX 9070 XT wirklich
encodieren soll, musste man aus zwei anderen Punkten erschliessen (Pfad-Mapping
und Preset-Namen). Genau so faellt etwas durch.
Jetzt steht seine Liste woertlich als Tabelle im Savepoint, jede Zeile mit
Stand und Verweis auf die Prioritaetenliste. Drei erledigt, eine Frage
beantwortet, fuenf offen.
Aufgeteilt wo noetig: Punkt 3 war eigentlich drei Forderungen - Vektorbefehle
auslesen (erledigt), das Beste empfehlen (offen), und Warnung von orange auf
gruen (erledigt, wirkt fuer seinen PC ab dem Deploy).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Diese Sitzung endete wegen vollem Kontext. Der Savepoint ist so geschrieben,
dass die naechste ohne Nachfragen weitermachen kann.
ZUSTAND, den man kennen MUSS: Repo fd1feaa mit gruener Ampel, aber die VM laeuft
noch 61c38a0 - die letzten zwei Commits sind NICHT deployt, und der
Windows-Worker des Commanders laeuft mit altem Code. Der 80-GB-Rohschnitt liegt
intakt auf der NAS, "Neu komprimieren" genuegt also, sobald der Blocker faellt.
DER KERNBEFUND aus dem fehlgeschlagenen Test-Rip, mit Messung statt Vermutung:
Das gezielte Routing funktionierte einwandfrei - sein PC nahm die Aufgabe an und
lehnte sie 182 ms spaeter ab. Drei Ursachen griffen ineinander, zwei sind
behoben, eine bleibt der Blocker (RIPPY_PATH_MAP wird von niemandem gesetzt).
Die offenen Punkte stehen nach Prioritaet, jeweils MIT dem Kontext, der zum
Weiterarbeiten fehlt: Format von pfad_lokal fuer Punkt 1, warum Punkt 2 nicht
ohne die Preset-Liste vom Worker geht (AGENTS Regel D - Namen erfinden hat das
Projekt zweimal teuer bezahlt), welcher Messpunkt sich fuer die ETA bewaehrt hat
(/proc/<pid>/fdinfo statt Fortschrittsanzeige), und welche Datei jeweils dran ist.
Dazu ein eigener Abschnitt "Fallen, die diese Sitzung gekostet haben" - deutsche
Anfuehrungszeichen in doppelt gequoteten Python-Strings (dreimal), Code in
f-String-Einsetzungen, docker exec ohne sh -c verschluckt Globs, /proc-Suche
trifft die eigene Shell, und pydantic-core springt lokal wiederholt zurueck.
Alles auch in den Memory-Notizen, damit es nicht wieder entdeckt werden muss.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Beim Aufraeumen der VM-.env aufgefallen und nachgemessen (25.07.2026):
https://www.makemkv.com/download HTTP 200 <- Repo-Standard
https://www.makemkv.com/download/old HTTP 525 (Cloudflare)
web.archive.org-Schnappschuss HTTP 404 <- stand in der VM-.env
Die VM zeigte also auf eine KAPUTTE Adresse. Aufgefallen ist es nie, weil dort
die vendor/-Tarballs liegen und der Download-Zweig gar nicht erreicht wird.
Nimm die Tarballs weg, und jeder Bau scheitert mit 404 - waehrend die
Konfiguration gesund aussieht. Genau diese Sorte Fehler ist bei einer Uebergabe
teuer, weil sie erst beim Fremden zuschlaegt.
## Bereinigt (auf Commander-Wunsch, Sicherung liegt auf der VM)
.env.sicherung-vor-aufraeumen-20260725 angelegt, dann:
- MAKEMKV_URL_BASE raus -> es gilt der Compose-Standard, der liefert.
Von Docker gegengeprueft: MAKEMKV_URL_BASE: https://www.makemkv.com/download
- JWT_SECRET_KEY raus -> Ueberrest der in v3.4 ausgebauten Anmeldung, wirkungslos.
## Fallbacks BEHALTEN, aber echt gemacht (Commander-Vorgabe)
Vorher war der "Fallback" eine Zeile, die man von Hand eintragen musste - und
die hier ins Leere zeigte. Jetzt eine automatische Kette:
1. vendor/-Tarballs (braucht kein Netz, zuverlaessigster Weg)
2. MAKEMKV_URL_BASE
3. MAKEMKV_URL_FALLBACK (NEU, wird automatisch versucht wenn 2 versagt)
Stufe 3 ist ABSICHTLICH leer vorbelegt. Es gibt derzeit keine belegbare zweite
Quelle (siehe Messung oben), und eine einzutragen, die nicht liefert, waere
schlimmer als keine - genau das lag auf der VM vor. Wer eine eigene Quelle hat
(Spiegel im LAN), traegt sie ein und sie wird automatisch genutzt.
Scheitert alles, nennt die Fehlermeldung jetzt die beiden Wege, die
FUNKTIONIEREN, statt nur einen curl-Rueckgabewert zu hinterlassen.
## Geprueft, beide Zweige
- vendor-Pfad: Bau durch, 828 MB
- Download-Pfad: im FREMDEN Klon ohne Tarballs gebaut - Bau durch, 777 MB,
makemkvcon liegt unter /usr/local/bin/. Die leere Fallback-Stufe wird
korrekt uebersprungen, "Erste Quelle lieferte nicht" erschien nicht.
docker compose config validiert. README und .env.example nennen die gemessenen
HTTP-Antworten, damit niemand wieder eine 404-Adresse als Fallback eintraegt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Block dokumentiert jetzt auch die letzte Runde: ein Befehl statt
Checkliste, README neu aufgebaut, VM-CPU-Anleitung drin.
Ehrlich als UNGETESTET markiert (neuer Punkt 6): install.sh ist nie als root
durchgelaufen. Auf dieser VM sind alle root-Schritte No-Ops - Verzeichnisse
liegen da, die Propagation ist schon shared - und sudo verlangt hier ein
Passwort. Bewiesen sind Laufwerkserkennung (SCSI-Abgleich gegen die echte
Hardware), die .env-Logik in drei Faellen und die Syntax. Das Anlegen der
Verzeichnisse, mount --make-rshared und die systemd-Unit laufen erst bei einer
echten Neuinstallation - das gehoert in die Uebergabe statt in eine
Erfolgsmeldung.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Fuenf Vorgaben, was daraus wurde:
Codebase sauber -> vier tote Routen + zwei Module weg (main.py 1726 -> 1682
Zeilen), Tests halten sie draussen
UI schnell -> /capabilities 1,010 s -> 0,003 s; Dashboard-Aufbau
1,03 s -> 0,028 s. Alle 15 Ladeendpunkte unter 10 ms
UI selbsterklaerend -> Wizard-Kasten "Was Rippy gerade sieht" mit
Handlungsanweisung je Problem, sichtbare Keys mit Pruefung
Idiotensicher -> Wizard empfiehlt nach GEMESSENER CPU statt H.265 blind;
4K-Falle ist damit zu
Externe Worker -> auf Windows gegengeprueft (Kerne/Modell korrekt, encoders
ohne HandBrake korrekt leer, SIMD ehrlich "unbekannt")
Dazu die offene 4K-Frage aus v3.14 beantwortet: Kompression ist je Disc-Typ
abwaehlbar, 4K kann verlustfrei bleiben waehrend DVD/Blu-ray weiter schrumpfen.
ARM-Vergleich drin: fast alles, was ARM automatisch macht, macht Rippy schon -
und meist gruendlicher. Zwei echte Luecken benannt und NICHT gebaut
(ISO-Sicherung fuer Datentraeger, mehrere Laufwerke gleichzeitig), weil das
Funktionen sind und keine Reparatur. Ehrlich dabei: ob Rippy parallel rippen
kann, ist unbewiesen - mit einem Laufwerk nicht testbar.
Offene Punkte stehen unter "NOCH OFFEN", darunter der VM-CPU-Typ (qemu64 statt
host - AVX2 waere ein VM-Neustart und 2-4x schneller).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Block behauptete "nichts ist deployt" und fuehrte Fragment wie
Rohschnitt als offene Punkte. Beides ueberholt - genau solche stehen
gebliebenen Zusagen waren das Thema dieser Sitzung.
Nachgezogen mit Belegen statt Behauptungen:
- a1aabd5 laeuft, alle 5 Container up
- GET /capabilities antwortet cpu-x264/cpu-x265/cpu-av1 - KEIN Phantom-vaapi
mehr, dazu QEMU Virtual CPU 2.5+, 4 Kerne, sse4_2 (AVX2-Warnung greift)
- Zombie-Erkennung 19:26:09, exakt 120 s nach Start, geprueft=0
- 604 Disc-Schluessel haben den Rebuild ueberlebt
- Fragment (67.633.152 B) und der verwaiste 75-GB-Rohschnitt geloescht,
Platte 37 GB -> 111 GB frei
Neuer Befund dabei, nicht gebaut: "Job aus der Liste entfernen" loescht
bewusst keine Dateien - richtig so, macht die Rohdaten aber unerreichbar,
weil beides nur ueber die Job-ID verbunden ist. Der Rohschnitt war danach im
UI unsichtbar und "Neu komprimieren" unmoeglich. Das UI sollte beim Loeschen
sagen, wie viel daneben liegen bleibt.
Bei den vier toten Endpunkten steht jetzt, WARUM sie tot sind (jeder ein
Ueberrest eines ersetzten Entwurfs) und dass /stream/jobs der unangenehmste
ist: keine harmlose Leiche, sondern eine Endlosschleife je Verbindung.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Fund des Commanders am laufenden Akira-Job (Nachtrag im vorigen Savepoint):
Job stand auf 'canceling', HandBrake lief weiter. Gemessen 3,4 Minuten
zwischen Anforderung (18:30:17) und Bestaetigung (18:33:38) - bei langsamerem
Fortschritt entsprechend mehr.
Ursache genau wie dort beschrieben: Der Abbruch wurde nur in
datei_fortschritt geprueft, und diese Closure stieg oben sofort wieder aus,
wenn sich die Prozentzahl nicht geaendert hatte ("if gesamt == letzter[0]:
return"). Bei einem Prozent je halber Stunde hing der Abbruch also an einem
Ereignis, das eine halbe Stunde lang nicht eintrat.
run_handbrake bekommt jetzt einen eigenen abbruch_cb neben progress_cb -
dasselbe Muster, das run_makemkv schon fuer log_cb benutzt, und aus
demselben Grund: der Fortschritts-Kanal verwirft Aufrufe. Er wird bei JEDER
Ausgabezeile aufgerufen und im Worker auf 5 s gedrosselt.
Nebeneffekt, der genauso wichtig ist: Er greift auch waehrend des
Scan-Durchlaufs, der ueberhaupt keine Encode-Prozente liefert. Dort war ein
Abbruch vorher grundsaetzlich unmoeglich - und seit die Prozent-Regex den
Scan korrekt ignoriert, waere das sonst sogar schlimmer geworden.
Die Leseschleife ist als _handbrake_schleife() herausgezogen, damit die
Reihenfolge (Abbruch VOR Fortschritt) ohne echtes HandBrake pruefbar ist.
Der Test belegt: zwei Scan-Zeilen genuegen fuer den Abbruch, es muss NICHT
auf eine Encode-Zeile gewartet werden.
Savepoint nachgezogen: Der Encode laeuft nicht mehr, ein Deploy ist
gefahrlos moeglich, und die alte "SOFORT ENTSCHEIDEN"-Passage (Platte
laeuft voll, wenn der Job fertig wird) ist damit gegenstandslos. Neu darin:
die drei Wege fuer UHD, und die Warnung, dass eine /proc-Suche nach
"HandBrake" die eigene Shell mittrifft - zwei Fehlalarme in dieser Sitzung.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
SAVEPOINT bekommt den Stand v3.14: der unwirksame Platten-Schutz zuerst
(wichtigster Fund), dann die gemessenen Werte, das Gebaute, die vier toten
Endpunkte als Entscheidungsvorlage - und ein Abschnitt "SOFORT ENTSCHEIDEN".
Der laufende Akira-Encode wird beim Fertigwerden mit dem DEPLOYTEN, alten
Code versuchen, 75 GB in 37 GB zu kopieren. keepOriginal steht auf true, und
den Wert hat die Aufgabe beim Start gelesen - jetzt umstellen aendert daran
nichts mehr. Der Savepoint nennt die drei Optionen mit Empfehlung.
Zwei Richtigstellungen an v3.13, beide durch Messung:
- "progress=99 ist ein Altwert aus dem Absturz" war falsch. Beide Startpfade
setzen auf 0; der Wert kam frisch vom Scan-Durchlauf. Ein Bug, kein Ueberrest.
- Die Erwartung, _original_aufheben werde nur warnen, war falsch - siehe
EXDEV-Fund im vorigen Commit.
Ehrlich als OFFEN markiert: Was die Platte am 25.07. mittags fuellte, ist
NICHT belegt. Es gibt keine Kopier-Reste, kein original-Verzeichnis und
keinen einzigen Log-Eintrag von _original_aufheben, das in beiden Zweigen
loggt. Der Mechanismus ist jetzt bewiesen, sein Zuschlagen an jenem Tag
nicht. Lieber offen lassen als eine dritte Vermutung aufstellen.
AGENTS bekommt Etappe 19 und einen neuen Abschnitt, der das wiederkehrende
Muster benennt: nicht aus einem Zustandswert auf einen Mechanismus
schliessen - vier belegte Faelle. Plus die Umkehrung, die diese Sitzung
gekostet hat: gleiches st_dev heisst NICHT gleicher Mount. Was ausprobierbar
ist, wird ausprobiert statt vorhergesagt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der im Uebergabestand als "laeuft" beschriebene 4K-Lauf wurde um 18:31 vom
Commander abgebrochen. Damit war die Aussage im Block darueber ueberholt -
nachgezogen, statt sie stehen zu lassen.
Zwei Befunde, beide gemessen:
1. 4K-HEVC ist auf dieser CPU nicht machbar: 18:02 bis 18:31 ergab 1 Prozent,
hochgerechnet rund 50 Stunden fuer den Film. Zu entscheiden: UHD gar nicht
komprimieren (Roh-MKV behalten), Hardware-Encoder (Remote-Worker mit GPU),
oder bewusst bei 1080p bleiben. Preset-je-Disc-Typ ist richtig, reicht
allein aber nicht.
2. Abbruch wirkt verzoegert (FEHLER, nicht behoben): Job steht seit 18:31 auf
"canceling", HandBrake lief um 18:35 immer noch. Der Abbruch wird nur in
datei_fortschritt geprueft, und die Closure laeuft nur bei geaenderter
Prozentzahl ("if gesamt == letzter[0]: return"). Bei 1 Prozent alle 30
Minuten sieht "Abbrechen" bis zu eine halbe Stunde lang wirkungslos aus.
Der Abbruch gehoert unabhaengig vom Fortschritt geprueft.
Ausserdem festgehalten: die 1080p-Fassung wurde von HandBrake beim Start auf
0 Bytes gekuerzt, im Akira-Ordner liegt derzeit ein unbrauchbares Fragment.
Der 75-GB-Rohschnitt ist unversehrt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Uebergabe an eine neue Sitzung. Der Block trennt bewusst, was per Befehl auf
der VM geprueft wurde, von dem was offen bzw. nur erwartet ist - inklusive
zweier Fehlschluesse dieser Sitzung, damit die naechste Sitzung weiss, welchen
Aussagen sie nicht blind glauben soll.
Kern:
- Ein 4K-HandBrake-Lauf laeuft GERADE (Akira, Preset "H.265 MKV 2160p60 4K").
Die vorherige 1080p-Datei wurde dabei auf 0 Bytes gekuerzt; der 75-GB-
Rohschnitt liegt unversehrt in /app/temp/raw.
- progress=99 am Job ist ein Altwert aus dem Absturz, NICHT der echte Stand.
- Noch nicht bewiesen: dass _original_aufheben() im Ernstfall nur warnt statt
die Platte vollzuschreiben. Genau dieser Pfad ist neu.
- Gefunden, nicht gebaut: Zombie-Erkennung. Nach dem Absturz stand der Job auf
"transcoding", obwohl kein Prozess lief und beide Celery-Queues leer waren.
_kann_neu_komprimieren verlangt status == "failed", deshalb fehlt dem Nutzer
auch der "Neu komprimieren"-Knopf.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Rueckfrage des Commanders beim ersten echten UHD-Rip: "merkt Rippy, dass es
eine UHD ist, und nimmt direkt das 4K-Preset?" Antwort war nein. Die
Kompression fragte den Disc-Typ ueberhaupt nicht:
preset = einstellungen.get("transcodePreset") or DEFAULT_HB_PRESET
Live eingestellt war "HQ 1080p30 Surround". Der gerade laufende Akira-Rip
waere also verlustfrei in 4K gerippt und danach auf 1080p heruntergerechnet
worden - und mit keepOriginal=False waere der 4K-Rohschnitt danach geloescht
worden. Umgekehrt wurde eine DVD auf 1080p hochskaliert, was nichts bringt.
- preset_fuer(disc_type, einstellungen) in ripping.py, pure und getestet.
Reihenfolge: Preset des Disc-Typs -> allgemeines transcodePreset ->
DEFAULT_HB_PRESET. Bestandsinstallationen aendern ihr Verhalten NICHT,
solange die neuen Felder nicht gespeichert sind.
- Drei Einstellungen: transcodePresetDvd / transcodePresetBluray /
transcodePresetUhd. transcodePreset bleibt als Rueckfall bestehen.
- transcode_files holt den Disc-Typ aus dem Job-Datensatz und schreibt ihn
mit ins Log ("Disc-Typ 'uhd', Preset '...'").
- UI: drei Auswahlfelder statt einem, mit Klartext dazu, warum eine 4K-UHD
auf ein 2160p-Preset gehoert.
Preset-Namen stammen aus "HandBrakeCLI --preset-list" im Worker-Image
(HandBrake 1.6.1) - nicht aus dem Kopf (AGENTS Regel D):
H.265 MKV 2160p60 4K, HQ 2160p60 4K HEVC Surround,
Super HQ 2160p60 4K HEVC Surround, H.265 MKV 1080p30, HQ 1080p30 Surround,
Super HQ 1080p30 Surround, H.265 MKV 576p25, H.265 MKV 480p30,
HQ 576p25 Surround.
Sofortmassnahme am laufenden Job (auf Ansage des Commanders): keepOriginal
auf True gesetzt - nur dieses eine Feld, gegengeprueft dass kein anderer
Schluessel veraendert wurde. Damit ueberlebt der 4K-Rohschnitt die
Kompression.
ACHTUNG - Deploy bewusst NICHT ausgefuehrt: docker compose up -d --build
wuerde den Worker-Container neu erstellen und den laufenden Akira-Rip
abbrechen. Erst nach Abschluss des Jobs deployen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Richtigstellung des Vortags-Befunds. Dort stand, MakeMKVs Schluessel-Kanal
sei abgeschaltet. Das war FALSCH: die Herleitung stuetzte sich auf zwei
Hostnamen aus alten Forumsbeitraegen (hkdata.fairuse.org,
hkdata.crabdance.com), die zwar wirklich nicht mehr aufloesen, von MakeMKV
aber laengst nicht mehr benutzt werden. Aufgedeckt durch den Einwand des
Commanders, unter Windows ginge es sofort.
Gegenprobe mit demselben Laufwerk und derselben Disc (Akira UHD, MKB v76):
Linux (Worker) Windows
Verbindungen KEINE EINZIGE 185.84.108.20:443
Meldung 3338 nie "Downloading latest HK"
_private_data.tar 2048 B, 0 Keys 6,4 MB, 604 Keys
Disc volume key unknown TCOUNT:5, geht auf
Gegengeprueft mit leerem UND gefuelltem Speicher, mit und ohne --noscan,
mit dev:/dev/sr0 und disc:0, mit geloeschter update.conf. Linux fragt nie.
Die Meldungsvorlage "Downloading latest %1 to %2 ..." steckt sehr wohl im
Linux-Binary - sie loest nur nicht aus. Gleiches Symptom im MakeMKV-Forum,
seit Jahren offen (t=25782, t=34022). Der Dienst lebt; der Worker erreicht
185.84.108.20:443 sogar problemlos.
BEWIESEN: Nach Uebernahme des Windows-Schluesselspeichers oeffnet
makemkvcon auf der VM die Akira-UHD - "Operation successfully completed",
TCOUNT:5, fuenf Titel, identisch zum Windows-Ergebnis. Erster belegter
UHD-Disc-Zugriff auf der Rippy-Maschine.
- makemkv_daten.py (beide Zwillinge): zaehle_schluessel,
private_data_pruefen, schluesselspeicher_status, private_data_schreiben.
Die Pruefung lehnt einen Speicher OHNE hkd_*.bin ab - sonst laedt jemand
den leeren Vorrat einer frischen Installation hoch, nichts aendert sich,
und niemand versteht warum. Modulkopf komplett neu, inkl. der
Fehldiagnose als Warnung fuer spaeter.
- API: GET/POST /system/keystore. Der Rohkoerper der Anfrage IST die Datei
(binaer - JSON/Base64 waere Ballast, Multipart kann die API nicht).
Groessengrenze 64 MB = client_max_body_size in nginx.conf.
- UI: neuer Block "Disc-Schluessel fuer 4K-UHD" UEBER dem KEYDB-Block, mit
Schluessel-Anzahl, Upload und Anleitung fuer den Windows-Weg. KEYDB.cfg
ist jetzt als Notnagel beschriftet. Worker-Plakette zeigt die Anzahl;
0 heisst sichtbar "4K-UHD scheitert".
- tasks.py: UHD-Fehlertext sagt den Windows-Weg an und nennt die Anzahl
bekannter Schluessel dieses Workers.
- caps.py meldet schluessel je Worker.
- Alle Falschaussagen korrigiert: UI (3), Anleitung (2), README (3),
KONZEPT §8 + §10, Worker-Dockerfile, makemkv_key.py (dort stand "Den
AACS-Schluessel zieht MakeMKV via LibreDrive ohnehin selbst aus dem
Laufwerk" - gilt fuer Blu-ray, NICHT fuer UHD).
- SAVEPOINT v3.11, ROADMAP Etappe 18 (Etappe 17 mit Nachtrag), AGENTS.
Offen: voller UHD-Rip inkl. Transcode-E2E; und ob sich der Abruf unter
Linux doch anstossen laesst.
Quellen (AGENTS Regel D):
- Linux laedt keine Hashed Keys, gleiches Symptom:
https://forum.makemkv.com/forum/viewtopic.php?t=25782https://forum.makemkv.com/forum/viewtopic.php?t=34022
- Schluessel als hkd_*.bin in _private_data.tar:
https://forum.makemkv.com/forum/viewtopic.php?t=32675
- Meldungsformat: https://www.makemkv.com/developers/usage.txt
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
4K-UHD scheiterte an "The volume key is unknown for this disc". Am 25.07.2026
im Worker-Container nachgemessen: Laufwerk und MakeMKV sind in Ordnung
(LibreDrive v06.3 / Meldung 1011, Disc wird gelesen, AACS-Dump geschrieben) -
MakeMKV versucht gar nicht erst, online einen Schluessel zu holen. Belege:
_private_data.tar enthaelt nur die Index-Datei und KEINE hkd_*.bin; auch mit
geloeschter update.conf (Meldung 5074 belegt den Web-Kontakt) und mit
app_UpdateEnable="1" kam keiner; hkdata.fairuse.org und hkdata.crabdance.com
loesen weltweit nicht mehr auf (NXDOMAIN gegen Fritz!Box, 8.8.8.8, 1.1.1.1).
Betroffen war Akira UHD (MKB v76, Pressung Dez. 2020) - also gerade KEINE
Neuerscheinung. Der bisherige Fehlertext ("Disc neuer als die
Schluessel-Datenbank, mit einem der naechsten Updates rippbar") war falsch.
Einziger heute funktionierender Weg ist eine vom Nutzer selbst mitgebrachte
KEYDB.cfg. Rippy liefert KEINE Schluessel mit, laedt keine herunter und
verteilt keine - es stellt nur den Platz bereit und zeigt an, was dort liegt.
- Datenverzeichnis persistent gemountet (MAKEMKV_DATA_HOST, Default
/srv/rippy/makemkv): KEYDB.cfg und AACS-Dumps ueberleben jeden Rebuild.
Vorher loeschte jeder "up -d --build" beides - inklusive des Dumps, auf den
die Fehlermeldung selbst verwies.
- entrypoint.sh und tasks.py schreiben settings.conf ergaenzend statt
zerstoerend. Der entrypoint bricht bei nicht beschreibbarem Verzeichnis
nicht mehr ab - mit "restart: unless-stopped" waere das ein Crashloop
gewesen, in dem auch reines DVD-Rippen tot ist.
- Neues Zwillings-Modul makemkv_daten.py (docker/api + docker/worker,
byteweise identisch; test_zwillinge_sind_byteweise_identisch wacht darueber
und wurde durch absichtliches Verstellen als wirksam nachgewiesen).
- API: GET/POST/DELETE /system/keydb, GET /system/aacs-dumps(/{dateiname}).
JSON-Body statt Multipart - python-multipart ist bewusst nicht installiert
und wuerde die API beim Import toeten. nginx client_max_body_size 64m,
sonst scheitert der Upload mit 413, bevor die API ihn sieht.
- UI (Einstellungen -> System): Status, Hochladen per Datei-Dialog, Entfernen,
Dump-Download, KEYDB-Plakette je Worker (nur wo das Verzeichnis wirklich
gemountet ist - ein Remote-Transcode-Worker truege sonst eine Warnung,
die ihn nichts angeht).
- parse_msg() + log_cb: MakeMKV-Meldungen landen im Rippy-Log (gedrosselt:
Code 1003 raus, keine Wiederholungen, max. 40 je Rip). Nebenbei behoben:
der alte Parser (split(",", 4)[3]) schnitt jede Meldung am ersten Komma ab.
- Fuenf Stellen richtiggestellt, die behaupteten, MakeMKV-Updates braechten
die neueste Disc-Schluessel-Datenbank mit (UI, Anleitung, README,
Worker-Dockerfile, makemkv_key.py).
NICHT bewiesen: ein erfolgreicher UHD-Rip - es lag keine KEYDB.cfg mit dem
Akira-Schluessel vor. Belegt sind der Befund und die neue Mechanik. So steht
es auch im SAVEPOINT und in der ROADMAP.
Quellen (AGENTS Regel D):
- Datenverzeichnis + Dateiname GROSS/case-sensitiv:
https://forum.makemkv.com/forum/viewtopic.php?t=30636
- hkd_*.bin in _private_data.tar:
https://forum.makemkv.com/forum/viewtopic.php?t=32675
- headless settings.conf / app_UpdateEnable:
https://forum.makemkv.com/forum/viewtopic.php?t=20364
- KEYDB.cfg-Zeilenformat (libaacs):
https://github.com/ShiftMediaProject/libaacs/blob/master/KEYDB.cfg
- MSG-/PRGV-Format: https://www.makemkv.com/developers/usage.txt
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Commander-Entscheid 24.07.: nur noch EIN Branch. Der stable-Zwischenbranch
war vestigial — die VM deployt ohnehin aus main (git pull), das Gruen-Gate
hat den Live-Deploy nie real gegated.
- ci.yml: Beförderungs-Schritt (push -> stable) entfernt; die Ampel prueft
nur noch (Ruff/pytest/Vite-Build), Rot heisst weiterhin: nicht deployen.
- deploy.sh: klont/resettet auf main statt stable.
- AGENTS §C, README (Entwicklung), DESIGN-2.0-Briefing: auf main-only
umgeschrieben. Design-2.0-Briefing als ERLEDIGT markiert.
- SAVEPOINT v3.6.
Branches stable / design-2.0 / kernumbau-2026-07-23 werden nach diesem
Push geloescht (Inhalte vollstaendig in main).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
