Bei uns reproduziert (100% CPU, keine Ausgabe, auch mit sg-Knoten), im
MakeMKV-Forum vielfach bestaetigt (t=38128, t=38239, t=38249); Community-
Workaround ist 1.17.7. Bonus: exakt die Version, die spaeter die Firmware
flashen kann. MAKEMKV_URL_BASE als Build-Arg, weil makemkv.com gerade
per Cloudflare-525 down ist (Wayback-Snapshot als Ausweichquelle);
sha256 der Tarballs wird im Build-Log festgehalten.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Deploy-Befund 23.07.: Image frisch gebaut, GPL-Teile da, aber makemkvcon
fehlte — makemkv-bin installiert ohne PREFIX nach /usr, die Final-Stage
kopiert nur /usr/local. Jetzt PREFIX=/usr/local + test -x als Build-Beweis.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Vorher: Dockerfile unbaubar (makepkg ist ein Arch-Paket, existiert in Debian
nicht) und KEIN einziges Ripping-Tool im Image — jeder Rip endete sofort.
Disc-Erkennung via `file -L` konnte auf Block-Devices strukturell nie etwas
erkennen; ihr Test mockte sich die Ausgabe passend.
- makemkv-oss/bin 1.18.4 multi-stage (bookworm-gepinnt), EULA via
tmp/eula_accepted, Beta-Key aus MAKEMKV_APP_KEY (entrypoint.sh)
- makemkvcon-Aufruf + PRGV-Parsing laut makemkv.com/developers/usage.txt
(AGENTS Regel D), HandBrake raus aus dem Ripp-Pfad (KONZEPT: lossless=Muss)
- detection.py: CDROM_DISC_STATUS + BLKGETSIZE64 (cd/dvd/bluray), pure
classify() mit ehrlichen Tests
- tasks.py: rip_disc als einziger Celery-Task, schreibt Status/Fortschritt
nach Postgres (db.py), Ausgabe auf /app/media (Volume) statt totem /output
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Echtes HandBrake schreibt "45.50 %" mit Leerzeichen - die alte Regex
hat aus echter Ausgabe NIE einen Fortschritt geparst. Der neue Test
mit realistischer Zeile hat es sofort gefangen.
- docker-compose.yml mit read_only: true, tmpfs, healthchecks
- API- und Worker-Dockerfiles mit minimalem Image
- requirements.txt für Python-Abhängigkeiten
Hitonabi