Hitonabi
0935766f61
Ampel / ampel (push) Successful in 28s
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>
48 lines
2.3 KiB
Bash
48 lines
2.3 KiB
Bash
# Rippy-Umgebung — nach .env kopieren und Werte eintragen.
|
|
# Die .env liegt NUR auf der VM (gitignored), nie im Repo.
|
|
|
|
# PostgreSQL (intern). Default rippy; für eine exponierte Umgebung hier ein starkes
|
|
# Passwort setzen — Compose nutzt diesen Wert jetzt wirklich (DB + App-Verbindung).
|
|
POSTGRES_PASSWORD=rippy
|
|
|
|
# Optisches Laufwerk (Host-Geräteknoten) — je Rechner UNTERSCHIEDLICH!
|
|
# Der Worker braucht den SCSI-CD-ROM-Knoten (meist /dev/sr0) UND den passenden
|
|
# generischen sg-Knoten des Laufwerks. Die sg-Nummer variiert je Host — auf DIESER
|
|
# Maschine ermitteln: lsscsi -g (oder: ls -l /dev/sg*). Hier den HOST-Pfad des
|
|
# Blu-ray/DVD-Laufwerks eintragen; der Default passt für den Ursprungs-Host.
|
|
OPTICAL_SR=/dev/sr0
|
|
OPTICAL_SG=/dev/sg1
|
|
|
|
# (JWT/Auth wurde am 24.07.2026 komplett entfernt — Rippy ist Heimnetz-only,
|
|
# Commander-Entscheid, siehe KONZEPT.md Abschnitt 10. Härtung für exponierte
|
|
# Netze: siehe README, Abschnitt "Härtung für fremde/exponierte Netze".)
|
|
|
|
# Metadaten-APIs
|
|
# TMDB (empfohlen für Metadaten-Lookup; ohne Key startet Rippy trotzdem, Key auch
|
|
# später im UI setzbar): kostenlos auf themoviedb.org
|
|
TMDB_API_KEY=
|
|
# TVDb (optional, Serien-Fallback)
|
|
THETVDB_API_KEY=
|
|
# OMDb (optional, Fallback-Quelle): kostenloser Key auf omdbapi.com/apikey.aspx
|
|
OMDB_API_KEY=
|
|
|
|
# MakeMKV-Beta-Key (optional): DVDs gehen ohne, Blu-ray läuft 30 Tage im
|
|
# Testmodus. Aktueller Key: Forum-Thread "MakeMKV is free while in beta".
|
|
# Wechselt etwa monatlich — bei Blu-ray-Fehlern zuerst hier schauen.
|
|
# Bequemer: im UI unter Einstellungen → System eintragen (gilt ab dem
|
|
# nächsten Rip, ohne Neustart, und schlägt diesen Env-Wert).
|
|
MAKEMKV_APP_KEY=
|
|
|
|
# MakeMKV-Datenverzeichnis auf dem HOST (bleibt über Rebuilds hinweg erhalten).
|
|
# Hier hinein gehört die KEYDB.cfg für 4K-UHD-Discs; hier landen auch die
|
|
# AACS-Dumps fehlgeschlagener Discs. Beides ist ab Einstellungen → System
|
|
# im Browser erreichbar — dieser Pfad ist nur für den Fall, dass du die
|
|
# Dateien direkt auf der Maschine anfassen willst.
|
|
#MAKEMKV_DATA_HOST=/srv/rippy/makemkv
|
|
|
|
# MakeMKV-Version fürs Worker-Image (Einstellungen → System meldet Updates).
|
|
# Update: Version hier anheben, dann auf der Rippy-Maschine
|
|
# docker compose build worker && docker compose up -d worker
|
|
# (bei Cloudflare-Zicken vorher Tarballs nach docker/worker/vendor/ legen)
|
|
#MAKEMKV_VERSION=1.18.4
|