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>
52 lines
2.5 KiB
Bash
52 lines
2.5 KiB
Bash
#!/bin/sh
|
|
# Bereitet MakeMKVs Datenverzeichnis vor, BEVOR der Worker startet.
|
|
#
|
|
# Wichtig (Befund 25.07.2026): Dieses Verzeichnis ist jetzt ein persistenter
|
|
# Mount vom Host (docker-compose.yml). Darin liegen KEYDB.cfg (die einzige
|
|
# heute funktionierende Schlüsselquelle für 4K-UHD), die AACS-Dumps
|
|
# fehlgeschlagener Discs und MakeMKVs settings.conf. Deshalb wird die
|
|
# settings.conf hier ERGÄNZT statt überschrieben — vorher hat dieses Skript
|
|
# sie bei jedem Start plattgemacht und dabei alles außer app_Key gelöscht.
|
|
#
|
|
# Ohne Beta-Key: DVD-Ripping geht immer, Blu-ray läuft im 30-Tage-Testmodus.
|
|
set -e
|
|
|
|
DATEN_DIR="${MAKEMKV_DATA_DIR:-/root/.MakeMKV}"
|
|
CONF="${DATEN_DIR}/settings.conf"
|
|
|
|
# Die ganze Vorbereitung ist BEST EFFORT und läuft deshalb in einer Subshell
|
|
# ohne set -e. Grund: Das Datenverzeichnis kommt jetzt vom Host und kann
|
|
# schreibgeschützt sein oder einer fremden UID gehören (Freigabe, root_squash).
|
|
# Vorher war das unmöglich — geschrieben wurde containerintern. Bräche der
|
|
# Start daran ab, ergäbe "restart: unless-stopped" eine Endlosschleife, in der
|
|
# auch reines DVD-Rippen tot wäre, obwohl das die Datei gar nicht braucht.
|
|
# Denselben Weg geht tasks.py: OSError wird zur Warnung, der Job läuft weiter.
|
|
if ! (
|
|
set +e
|
|
mkdir -p "${DATEN_DIR}" || exit 1
|
|
[ -f "${CONF}" ] || touch "${CONF}" || exit 1
|
|
|
|
# app_Key aus der Umgebung setzen: alte Zeile raus, neue ans Ende. Alles
|
|
# andere in der Datei bleibt stehen. (grep -v liefert Exit 1, wenn nichts
|
|
# übrig bleibt — das ist hier kein Fehler.)
|
|
if [ -n "${MAKEMKV_APP_KEY}" ]; then
|
|
grep -v '^app_Key' "${CONF}" > "${CONF}.neu" 2>/dev/null
|
|
printf 'app_Key = "%s"\n' "${MAKEMKV_APP_KEY}" >> "${CONF}.neu" || exit 1
|
|
mv "${CONF}.neu" "${CONF}" || exit 1
|
|
fi
|
|
|
|
# Web-Kontakt explizit einschalten. MakeMKV hat das per Default ohnehin an
|
|
# (Meldung 5074, am 25.07. im Worker verifiziert) — explizit steht es hier,
|
|
# damit die Einstellung nachvollziehbar ist und nicht versehentlich kippt.
|
|
# Quelle: forum.makemkv.com/forum/viewtopic.php?t=20364 (headless settings.conf)
|
|
grep -q '^app_UpdateEnable' "${CONF}" || printf 'app_UpdateEnable = "1"\n' >> "${CONF}" || exit 1
|
|
exit 0
|
|
); then
|
|
echo "WARNUNG: ${DATEN_DIR} ist nicht beschreibbar." >&2
|
|
echo " MakeMKV-Beta-Key und app_UpdateEnable wurden NICHT gesetzt." >&2
|
|
echo " Der Worker startet trotzdem. Prüfe Rechte und Eigentümer des" >&2
|
|
echo " Host-Verzeichnisses (Standard: /srv/rippy/makemkv)." >&2
|
|
fi
|
|
|
|
exec "$@"
|