rippy/docker/worker/Dockerfile

# Worker-Image: MakeMKV (verlustfrei, Etappe 10) + abcde/cdparanoia (CD→FLAC).
#
# Multi-Stage: makemkv-oss wird aus Quellen gebaut (GPL-Teil), makemkv-bin ist
# das proprietäre Binärpaket (EULA wird per tmp/eula_accepted akzeptiert —
# Standard-Mechanismus des Makefiles für nicht-interaktive Builds).
# Beide Stages sind auf bookworm gepinnt, damit die libavcodec-Version passt.
#
# Vorher stand hier `makepkg` (ein Arch-Linux-Werkzeug, existiert in Debian
# nicht) — das Image war seit dem 23.07. gar nicht mehr baubar. Und es fehlte
# schlicht JEDES Ripping-Werkzeug: weder HandBrake noch abcde noch MakeMKV
# waren installiert.

FROM python:3.12-slim-bookworm AS makemkv-build

# Zurück auf die AKTUELLE Version (24.07.2026): 1.17.7 war wegen des
# 1.18er-Laufwerks-Scan-Hängers (Forum t=38128) und der Flash-Fähigkeit
# gepinnt. Beides erledigt: der Scan wird überall mit --noscan umgangen
# (info-Lauf mit 1.18.4 auf der BU40N sauber durchgelaufen, 24.07.), und
# das Laufwerk ist geflasht (LibreDrive v06.3 bestätigt).
# Richtigstellung 25.07.2026: Hier stand, die aktuelle Version zähle, weil sie
# "die neueste AACS-Schlüssel-Datenbank mitbringt". Das ist widerlegt — MakeMKV
# bringt gar keine Disc-Schlüssel mit, und der Online-Kanal liefert nichts mehr
# (Messungen im Modul-Kopf von makemkv_daten.py). Aktuell bleiben lohnt sich
# trotzdem: Laufwerks-Unterstützung und Fehlerbehebungen. Schlüssel für neue
# UHD-Pressungen kommen ausschließlich aus der KEYDB.cfg im Datenverzeichnis.
# MAKEMKV_URL_BASE ist übersteuerbar (Build-Arg): /download hat nur die
# aktuelle Version, /download/old die älteren. Wenn Cloudflare BuildKit-
# Downloads drosselt (24.07.: außerhalb des Builds ging alles, im Build
# konsequent HTTP-Fehler), Tarballs von Hand laden und lokal servieren:
#   mkdir ~/makemkv-mirror && curl -o … && docker run -d --name makemkv-mirror \
#     -p 8099:80 -v ~/makemkv-mirror:/usr/share/nginx/html:ro nginx:alpine
#   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 \
    pkg-config \
    ca-certificates \
    curl \
    libssl-dev \
    libexpat1-dev \
    libavcodec-dev \
    zlib1g-dev \
    && rm -rf /var/lib/apt/lists/*

WORKDIR /build

# 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 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 \
        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 \
    && make -j"$(nproc)" \
    && make install

# PREFIX explizit: makemkv-bin installiert sonst nach /usr — und das COPY der
# Final-Stage nimmt nur /usr/local mit (Deploy 23.07.: makemkvcon fehlte im Image).
# Das abschließende test -x lässt den Build laut scheitern statt still lückenhaft.
RUN cd "makemkv-bin-${MAKEMKV_VERSION}" \
    && mkdir -p tmp \
    && touch tmp/eula_accepted \
    && make PREFIX=/usr/local \
    && make install PREFIX=/usr/local \
    && test -x /usr/local/bin/makemkvcon


FROM python:3.12-slim-bookworm

# handbrake-cli: Kompressions-Stufe NACH dem verlustfreien MakeMKV-Rip
# (Commander-Entscheid 23.07.: 40-GB-Rohdateien sind nicht arbeitsfähig).
RUN apt-get update && apt-get install -y --no-install-recommends \
    libssl3 \
    libexpat1 \
    zlib1g \
    libavcodec59 \
    abcde \
    cdparanoia \
    cd-discid \
    flac \
    handbrake-cli \
    && rm -rf /var/lib/apt/lists/*

COPY --from=makemkv-build /usr/local /usr/local
RUN ldconfig

# Version fürs UI sichtbar machen (Einstellungen → System): makemkvcon hat
# keinen --version-Schalter, also kommt die Wahrheit aus dem Build selbst.
ARG MAKEMKV_VERSION=1.18.4
ENV MAKEMKV_VERSION=${MAKEMKV_VERSION}

WORKDIR /app

COPY docker/worker/requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY docker/worker/ .

# Gemeinsamer Kern (Etappe V2-0): liegt im Repo unter src/rippy, im Image
# neben den Worker-Modulen. Celery startet mit /app als Arbeitsverzeichnis,
# damit findet "import rippy" das Paket ohne PYTHONPATH.
COPY src/rippy ./rippy

RUN chmod +x /app/entrypoint.sh

ENTRYPOINT ["/app/entrypoint.sh"]
# Der lokale Worker bedient BEIDE Queues (rip + transcode). Ein optionaler
# Remote-GPU-Worker startet dasselbe Image nur mit "-Q transcode".
CMD ["celery", "-A", "celery_app", "worker", "--loglevel=info", "-Q", "celery,transcode"]