diff --git a/.env.example b/.env.example index d01ca4a..40ba5bf 100644 --- a/.env.example +++ b/.env.example @@ -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. diff --git a/README.md b/README.md index c827557..3254cb2 100644 --- a/README.md +++ b/README.md @@ -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 -usb0 host=:,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`) | diff --git a/SAVEPOINT.md b/SAVEPOINT.md index 687157b..a793a3b 100644 --- a/SAVEPOINT.md +++ b/SAVEPOINT.md @@ -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). diff --git a/docker-compose.yml b/docker-compose.yml index 69d5bd3..7b80106 100644 --- a/docker-compose.yml +++ b/docker-compose.yml @@ -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. diff --git a/docker/worker/Dockerfile b/docker/worker/Dockerfile index 5356f6f..01319fd 100644 --- a/docker/worker/Dockerfile +++ b/docker/worker/Dockerfile @@ -32,6 +32,19 @@ FROM python:3.12-slim-bookworm AS makemkv-build # docker compose build --build-arg MAKEMKV_URL_BASE=http://: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://: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://: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 \