Hitonabi
5778ac4645
Ampel / ampel (push) Successful in 29s
Zwei bewiesene Bug-Fixes:
- SMB-Mount 'Unable to apply new capability set': mount.cifs hebt
CAP_DAC_READ_SEARCH an, die in Dockers Default-Caps fehlt (auf der VM
reproduziert: Bounding-Set a82425fb ohne Bit 2; mit der Capability
verschwindet der Fehler). Fix: cap_add DAC_READ_SEARCH fuer den
api-Container.
- TMDB fiel still aus: Client konnte nur v4-Bearer-Tokens, der uebliche
32-Hex-v3-Key bekam 401 und die Suche lieferte nur OMDb. Jetzt beide
Key-Arten (ist_v4_token + api_key-Query-Param lt.
developer.themoviedb.org, mit Tests) — damit kommen auch die deutschen
Texte an (language=de-DE war ueberall schon gesetzt). Neu:
GET /metadata/status + 'Verbindung pruefen' in Einstellungen -> APIs
(Live-Check am Cache vorbei).
Features aus dem Commander-Feedback:
- 4K UHD als eigener Disc-Typ: classify >= 55 GiB (BD-66/BD-100; BD-50
bleibt bluray), beide detection.py + Tests, eigene Badge-Farbe in
Dashboard/Laufwerken, Prescan-Label '4K UHD'. UHD-Rip-Fehler 'Failed to
open disc' (Code 11) bekommt Klartext: LibreDrive-Firmware noetig.
- Vollautomatik (Setting autoRipStart): Disc erkannt -> Rip startet ohne
Popup in den Schnellwahl-Ordner (Serie->Serien, sonst Filme, CD->Musik).
- Job-Verwaltung: 'Neu komprimieren' nur noch mit can_retry (Rohdaten
liegen wirklich da), DELETE /jobs/{id} + 'Erledigte aufraeumen'
(Dateien bleiben immer), 'Alle herunterladen' im Job-Detail
(gestaffelte Einzel-Downloads statt Server-Zip von 40-GB-Dateien).
- Worker zuordenbar: WORKER_NAME-Env als stabiler Anzeigename (fixt auch
die Offline-Leichen nach Rebuilds), info.hostname/ip gemeldet,
Online-Abgleich ueber hostname, DELETE /workers/{name} + Papierkorb im
UI, Quelle-Anzeige an der Disc-Karte ('Quelle: TMDB - 99 % sicher').
- Ripping-Tab nach Medium gegliedert (Video/Audio-CD/Allgemein) +
Untertitel-Klartext (--all-audio/--all-subtitles bleiben komplett),
CD -> Musik-Vorauswahl im Ziel-Dialog, Ordner-Verwaltung beschriftet
und standardmaessig eingeklappt.
- Docs: SAVEPOINT v3.3, ROADMAP Etappe 14 + Ideen (nativer
Windows-Worker, deutsche OMDb-Texte via TMDB-Find), README.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
39 lines
1.7 KiB
YAML
39 lines
1.7 KiB
YAML
# Optionaler Remote-Transcode-Worker — für eine GPU-Maschine im Netz.
|
|
# (EXPERIMENTELL, 23.07.2026: VAAPI/NVENC-Presets folgen; aktuell nutzt der
|
|
# Worker dieselben HandBrake-CPU-Presets, bringt also v.a. stärkere CPUs.)
|
|
#
|
|
# Auf der GPU-Maschine:
|
|
# 1. Dieses Repo klonen (oder nur dieses File + Zugriff aufs Registry-Image)
|
|
# 2. Rohdaten-Freigabe der Rippy-Maschine mounten, z. B.:
|
|
# mount -t nfs <rippy-host>:/srv/rippy /mnt/rippy
|
|
# (die Rippy-VM muss /srv/rippy + das temp-Volume exportieren)
|
|
# 3. RIPPY_HOST unten setzen und starten:
|
|
# docker compose -f deploy/remote-transcode-worker.yml up -d --build
|
|
#
|
|
# Der Worker meldet seine Encoder-Fähigkeiten automatisch — er taucht danach
|
|
# unter Einstellungen → Verarbeitung auf. Er bedient NUR die transcode-Queue;
|
|
# gerippt wird weiterhin dort, wo das Laufwerk hängt.
|
|
|
|
services:
|
|
transcode-worker:
|
|
build:
|
|
context: ..
|
|
dockerfile: docker/worker/Dockerfile
|
|
command: ["celery", "-A", "celery_app", "worker", "--loglevel=info", "-Q", "transcode", "-n", "gpu-worker@%h"]
|
|
environment:
|
|
- REDIS_URL=redis://${RIPPY_HOST:?RIPPY_HOST setzen}:6379/0
|
|
- DATABASE_URL=postgresql://rippy:rippy@${RIPPY_HOST}:5432/rippy
|
|
- RIP_OUTPUT_DIR=/app/media
|
|
- RAW_DIR=/app/temp/raw
|
|
# Anzeigename in Einstellungen → Worker — z. B. den Maschinennamen
|
|
# setzen: WORKER_NAME=gaming-pc docker compose -f … up -d
|
|
- WORKER_NAME=${WORKER_NAME:-transcode-worker}
|
|
volumes:
|
|
# Freigabe der Rippy-Maschine (siehe Kopf-Kommentar)
|
|
- /mnt/rippy/media:/app/media
|
|
- /mnt/rippy/temp:/app/temp
|
|
devices:
|
|
# GPU für Hardware-Encoding (AMD/Intel: /dev/dri; NVIDIA: nvidia-runtime)
|
|
- /dev/dri:/dev/dri
|
|
restart: unless-stopped
|