fix(build): der MakeMKV-Fallback der VM war seit Monaten tot - Kette jetzt dreistufig

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>
2026-07-25 22:50:54 +02:00
parent b0205c42c9
commit 29444805a8
5 changed files with 105 additions and 15 deletions
@@ -51,3 +51,23 @@ MAKEMKV_APP_KEY=
 #   docker compose build worker && docker compose up -d worker
 # (bei Cloudflare-Zicken vorher Tarballs nach docker/worker/vendor/ legen)
 #MAKEMKV_VERSION=1.18.4
+
+# ---------------------------------------------------------------------------
+# MakeMKV-Bezug beim Image-Bau (nur nötig, wenn der Download klemmt)
+# ---------------------------------------------------------------------------
+# Am 25.07.2026 nachgemessen, welche Quellen wirklich liefern:
+#   https://www.makemkv.com/download        HTTP 200  <- der Standard, funktioniert
+#   https://www.makemkv.com/download/old    HTTP 525  (Cloudflare)
+#   web.archive.org-Schnappschuss           HTTP 404
+# Normalerweise ist hier NICHTS einzutragen.
+#MAKEMKV_URL_BASE=https://www.makemkv.com/download
+#
+# Zweite Quelle, die bei Fehlschlag der ersten automatisch probiert wird.
+# Trage hier nur etwas ein, das du selbst geprüft hast — eine Adresse, die nicht
+# liefert, lässt die Konfiguration gesund aussehen und den Bau später scheitern.
+# Genau so lag es auf der Rippy-VM: dort stand eine 404-Adresse, und nur die
+# vendor-Tarballs retteten jeden Bau, ohne dass es jemandem auffiel.
+#MAKEMKV_URL_FALLBACK=http://192.168.178.10:8099
+#
+# Der zuverlässigste Weg bleibt ohne Netz: Tarballs von makemkv.com/download
+# laden und nach docker/worker/vendor/ legen — der Bau nimmt sie dann von dort.
@@ -65,7 +65,7 @@ Die vier Fälle, die praktisch alles abdecken:
 | Symptom | Ursache & Lösung |
 |---|---|
 | **„Kein optisches Laufwerk gefunden"** | In einer **VM**? Das Laufwerk muss per **USB-Passthrough** durchgereicht werden, nicht als emuliertes CD-ROM (`media=cdrom`) — das kann keine SCSI-Kommandos, MakeMKV sieht es nie. Proxmox: `qm set <vmid> -usb0 host=<hersteller>:<produkt>,usb3=1`. Auf echter Hardware: `ls /dev/sr*` prüfen. |
-| **Build bricht beim MakeMKV-Download ab** | Cloudflare drosselt manchmal. Tarballs von makemkv.com/download händisch nach `docker/worker/vendor/` legen, dann `sudo ./install.sh` erneut — der Build nimmt sie dann von dort. |
+| **Build bricht beim MakeMKV-Download ab** | Cloudflare drosselt manchmal. Der zuverlässige Weg: Tarballs von makemkv.com/download händisch nach `docker/worker/vendor/` legen, dann `sudo ./install.sh` erneut — der Build nimmt sie von dort und braucht kein Netz. Hast du eine eigene Quelle (Spiegel im LAN), trage sie als `MAKEMKV_URL_FALLBACK` in die `.env` ein; sie wird automatisch versucht, wenn makemkv.com nicht liefert. |
 | **Kompression läuft ewig** | Deine CPU kann kein AVX2. Rippy zeigt das jetzt selbst an (Einstellungen → System, „Vektorbefehle"). Siehe **[Rippy schneller machen](#rippy-schneller-machen)**. |
 | **4K-UHD: „The volume key is unknown"** | Erwartbar und **kein Fehler in Rippy**. Siehe **[4K-UHD](#4k-uhd)**. |

@@ -275,7 +275,8 @@ UI-Einstellungen überstimmen die Env-Variablen.
 | `WORKER_NAME` | Anzeigename des eingebauten Workers (Standard `rippy-hauptworker`) |
 | `MAKEMKV_APP_KEY` | MakeMKV-Beta-Key. Bequemer im UI unter Einstellungen → System — gilt ab dem nächsten Rip, ohne Rebuild |
 | `MAKEMKV_VERSION` | MakeMKV-Version für den Image-Build |
-| `MAKEMKV_URL_BASE` | alternative Download-Quelle für den Build |
+| `MAKEMKV_URL_BASE` | Download-Quelle für den Build. Normalerweise **nichts eintragen** — der Standard `makemkv.com/download` liefert (am 25.07.2026 mit HTTP 200 geprüft; `/download/old` gibt 525, ein web.archive.org-Schnappschuss 404) |
+| `MAKEMKV_URL_FALLBACK` | zweite Quelle, die bei Fehlschlag der ersten **automatisch** versucht wird. Leer = keine. Trage nur ein, was du selbst geprüft hast: eine Adresse, die nicht liefert, lässt die Konfiguration gesund aussehen und den Build später scheitern |
 | `MAKEMKV_DATA_HOST` | Host-Verzeichnis für MakeMKVs Daten (Standard `/srv/rippy/makemkv`) — Schlüsselspeicher, `KEYDB.cfg`, AACS-Dumps. Persistent, überlebt jeden Rebuild |
 | `OPTICAL_SR` / `OPTICAL_SG` | Geräteknoten des Laufwerks. **Findet `install.sh` selbst** |
 | `POSTGRES_PASSWORD` | DB-Passwort (Standard `rippy`) |
@@ -148,6 +148,34 @@ host`), **warum ein Neustart von innen nicht genügt**, und wie man nachprüft:
 Rippy zeigt die Vektorbefehle selbst an. Dazu der Nachteil (keine
 Live-Migration auf andere CPUs) und die Alternative `x86-64-v3` für Cluster.

+### Der MakeMKV-„Fallback" auf der VM war seit Monaten tot
+
+Beim Aufräumen der VM-`.env` aufgefallen und nachgemessen (25.07.2026):
+
+| Quelle | Antwort |
+|---|---|
+| `https://www.makemkv.com/download` (Repo-Standard) | **HTTP 200** |
+| `https://www.makemkv.com/download/old` | HTTP 525 (Cloudflare) |
+| web.archive.org-Schnappschuss **aus der VM-`.env`** | **HTTP 404** |
+
+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 — während die
+Konfiguration gesund aussieht. Genau diese Sorte Fehler ist bei einer Übergabe
+teuer.
+
+**Bereinigt** (Sicherung liegt als `.env.sicherung-vor-aufraeumen-20260725`):
+`MAKEMKV_URL_BASE` raus → es gilt der Standard, der liefert. `JWT_SECRET_KEY`
+raus → Überrest der in v3.4 ausgebauten Anmeldung, wirkungslos.
+
+**Gebaut — Rückfall dreistufig und ehrlich:** `vendor/`-Tarballs →
+`MAKEMKV_URL_BASE` → `MAKEMKV_URL_FALLBACK` (neu, wird automatisch versucht).
+Der Fallback ist **absichtlich leer vorbelegt**: Es gibt derzeit keine belegbare
+zweite Quelle, und eine einzutragen, die nicht liefert, wäre schlimmer als
+keine — siehe oben. Scheitert alles, nennt die Fehlermeldung jetzt die beiden
+Wege, die funktionieren (Tarballs nach `vendor/`, oder eigene Quelle als
+`MAKEMKV_URL_FALLBACK`), statt nur einen curl-Rückgabewert zu hinterlassen.
+
 ### NOCH OFFEN

 1. **Externe Worker im Praxistest** (Commander).
@@ -70,10 +70,17 @@ services:
      context: .
      dockerfile: docker/worker/Dockerfile
      args:
-        # Übersteuerbar via .env — makemkv.com ist zeitweise down (Cloudflare
-        # 525); dann Wayback-Snapshot als MAKEMKV_URL_BASE eintragen.
-        # /download = aktuelle Version, /download/old = ältere Versionen.
+        # Übersteuerbar via .env. /download = aktuelle Version,
+        # /download/old = ältere. Am 25.07.2026 nachgemessen: /download
+        # antwortet mit 200, /download/old mit 525 (Cloudflare), und ein
+        # web.archive.org-Schnappschuss mit 404 — deshalb steht hier der
+        # Standard, der wirklich liefert.
        MAKEMKV_URL_BASE: ${MAKEMKV_URL_BASE:-https://www.makemkv.com/download}
+        # Zweite Quelle, die bei Fehlschlag der ersten automatisch probiert wird
+        # (leer = keine). Bewusst ohne Vorbelegung: eine Adresse, die nicht
+        # liefert, lässt die Konfiguration gesund aussehen und den Build später
+        # scheitern. Der zuverlässige Weg bleibt docker/worker/vendor/.
+        MAKEMKV_URL_FALLBACK: ${MAKEMKV_URL_FALLBACK:-}
        # MakeMKV-Update OHNE Code-Änderung: neue Version in die .env,
        # Tarballs nach docker/worker/vendor/ legen (oder Download klappt),
        # dann docker compose build worker && docker compose up -d worker.
@@ -32,6 +32,19 @@ FROM python:3.12-slim-bookworm AS makemkv-build
 #   docker compose build --build-arg MAKEMKV_URL_BASE=http://<host-ip>:8099 worker
 ARG MAKEMKV_VERSION=1.18.4
 ARG MAKEMKV_URL_BASE=https://www.makemkv.com/download
+# Zweite Quelle, die bei einem Fehlschlag der ersten AUTOMATISCH probiert wird.
+# Absichtlich LEER: Am 25.07.2026 nachgemessen, welche Quellen wirklich liefern —
+#   https://www.makemkv.com/download          HTTP 200   (der Standard oben)
+#   https://www.makemkv.com/download/old      HTTP 525   (Cloudflare)
+#   web.archive.org-Schnappschuss             HTTP 404
+# Es gibt derzeit also keine belegbare zweite Quelle. Eine hier einzutragen, die
+# nicht liefert, wäre schlimmer als keine: der Build scheitert dann später und
+# die Konfiguration sieht trotzdem gesund aus — genau das war auf der Rippy-VM
+# der Fall (dort stand die 404-Adresse, und nur die vendor-Tarballs retteten
+# jeden Build, ohne dass es auffiel).
+# Wer eine eigene Quelle hat (Spiegel im LAN, eigener Webserver), traegt sie ein:
+#   docker compose build --build-arg MAKEMKV_URL_FALLBACK=http://<host>:8099 worker
+ARG MAKEMKV_URL_FALLBACK=

 RUN apt-get update && apt-get install -y --no-install-recommends \
    build-essential \
@@ -46,26 +59,47 @@ RUN apt-get update && apt-get install -y --no-install-recommends \

 WORKDIR /build

-# Download mit doppeltem Netz (Cloudflare drosselt BuildKit-Downloads
+# Download mit DREIFACHEM Netz (Cloudflare drosselt BuildKit-Downloads
 # hartnäckig — 24.07. viermal, auch MIT --retry-all-errors):
 # 1. Liegen die Tarballs lokal in docker/worker/vendor/ (untracked), werden
 #    SIE genutzt — einmal von Hand hinlegen, nie wieder Download-Roulette.
 # 2. Sonst curl mit Retries gegen MAKEMKV_URL_BASE.
+# 3. Scheitert das, wird MAKEMKV_URL_FALLBACK versucht, falls gesetzt.
+# Und wenn alles scheitert, sagt die Meldung, welche Wege es gibt — statt nur
+# einen curl-Rückgabewert zu hinterlassen.
 COPY docker/worker/vendor/ ./vendor/
-RUN if [ -s "vendor/makemkv-oss-${MAKEMKV_VERSION}.tar.gz" ] \
+RUN set -e; \
+    hole() { \
+        ziel="$1"; datei="$2"; \
+        if curl -fsSL --retry 5 --retry-delay 15 --retry-all-errors \
+                -o "$ziel" "${MAKEMKV_URL_BASE}/${datei}"; then \
+            return 0; \
+        fi; \
+        if [ -n "${MAKEMKV_URL_FALLBACK}" ]; then \
+            echo "Erste Quelle lieferte nicht — versuche MAKEMKV_URL_FALLBACK"; \
+            curl -fsSL --retry 3 --retry-delay 10 --retry-all-errors \
+                -o "$ziel" "${MAKEMKV_URL_FALLBACK}/${datei}" && return 0; \
+        fi; \
+        echo "FEHLER: ${datei} war von keiner Quelle zu holen." >&2; \
+        echo "  Geprueft: ${MAKEMKV_URL_BASE}${MAKEMKV_URL_FALLBACK:+ und ${MAKEMKV_URL_FALLBACK}}" >&2; \
+        echo "  Sicherster Weg: Tarballs von makemkv.com/download herunterladen" >&2; \
+        echo "  und nach docker/worker/vendor/ legen, dann erneut bauen." >&2; \
+        echo "  Alternativ eine eigene Quelle angeben:" >&2; \
+        echo "  docker compose build --build-arg MAKEMKV_URL_FALLBACK=http://<host>:8099 worker" >&2; \
+        return 1; \
+    }; \
+    if [ -s "vendor/makemkv-oss-${MAKEMKV_VERSION}.tar.gz" ] \
       && [ -s "vendor/makemkv-bin-${MAKEMKV_VERSION}.tar.gz" ]; then \
        echo "Nutze lokale Tarballs aus vendor/"; \
        cp "vendor/makemkv-oss-${MAKEMKV_VERSION}.tar.gz" oss.tar.gz; \
        cp "vendor/makemkv-bin-${MAKEMKV_VERSION}.tar.gz" bin.tar.gz; \
    else \
-        curl -fsSL --retry 5 --retry-delay 15 --retry-all-errors \
-            -o oss.tar.gz "${MAKEMKV_URL_BASE}/makemkv-oss-${MAKEMKV_VERSION}.tar.gz" \
-        && curl -fsSL --retry 5 --retry-delay 15 --retry-all-errors \
-            -o bin.tar.gz "${MAKEMKV_URL_BASE}/makemkv-bin-${MAKEMKV_VERSION}.tar.gz"; \
-    fi \
-    && sha256sum oss.tar.gz bin.tar.gz \
-    && tar xzf oss.tar.gz \
-    && tar xzf bin.tar.gz
+        hole oss.tar.gz "makemkv-oss-${MAKEMKV_VERSION}.tar.gz"; \
+        hole bin.tar.gz "makemkv-bin-${MAKEMKV_VERSION}.tar.gz"; \
+    fi; \
+    sha256sum oss.tar.gz bin.tar.gz; \
+    tar xzf oss.tar.gz; \
+    tar xzf bin.tar.gz

 RUN cd "makemkv-oss-${MAKEMKV_VERSION}" \
    && ./configure --disable-gui --prefix=/usr/local \