Ampel / ampel (push) Failing after 48s
WAS: Der Ablauf ist aus tasks.py heraus (ablauf.py, ohne Celery), die
LocalQueue wird bedient, ein Laeufer arbeitet Auftraege im selben Prozess
ab, und Rippy meldet sich mit gemessenen Faehigkeiten selbst als Arbeiter.
WARUM: "Rippy fuer Windows soll standalone funktionieren" (Commander). Bis
hierher konnte die Windows-App alles ANZEIGEN und nichts TUN — ein Rip waere
eingereiht worden und fuer immer liegengeblieben, weil niemand ihn holt.
DIE TRENNUNG: rip_disc hing an GENAU DREI Celery-Stellen in 234 Zeilen —
self.update_state, _transcode_queue, transcode_files.apply_async. Alle drei
sind Fragen der ZUSTELLUNG, nicht des Ablaufs. Sie sind jetzt Rueckrufe:
tasks.py reicht die Celery-Fassung herein, standalone.py die lokale. OHNE
Rueckruf komprimiert derselbe Prozess weiter — genau das, was ein
Ein-Prozess-Rippy braucht. Der Ablauf selbst ist Zeile fuer Zeile derselbe;
der Docker-Betrieb merkt vom Umbau nichts (Task-Namen, Argumente, Queues
unveraendert).
EINE ZUSTELL-STELLE statt drei: celery_client.abschicken() bedient alle
Auftragsarten. Vorher rief jede Stelle send_task selbst auf — der
Standalone-Betrieb haette an drei Stellen umgebogen werden muessen, beim
naechsten Auftragstyp an einer vierten.
WEITERER BLOCKER GEFUNDEN: ablauf.py holte detect_disc_type fest aus dem
LINUX-Treiber, in einem try/except. Unter Windows waere es damit IMMER None
gewesen und Rippen "hart verriegelt" — Rippy haette alles angezeigt und
nichts gerippt, ohne dass irgendwo ein Fehler stuende. Jetzt fragt es den
Treiber-Port.
WERKZEUGE: ripping.py und caps.py suchten nur im PATH. Auf dem Commander-PC
gemessen, vorher/nachher:
vorher check_makemkv_installed() -> False (obwohl installiert)
erkenne_encoder() -> nur CPU
nachher MakeMKV 1.18.4 C:\Program Files (x86)\MakeMKV\makemkvcon64.exe
HandBrake 1.11.2 ueber die API geholt, in 2,7 s
Encoder cpu-x264, cpu-x265, cpu-av1, VCE, VCE-AV1
107 Presets, Ryzen 7 9700X, 16 Kerne, avx512f
VCE ist die Hardwarebeschleunigung der Radeon — die hat Rippy auf diesem
Rechner vorher nie gesehen, weil es HandBrake gar nicht fand.
NEUE ROUTEN: GET /system/werkzeuge (was liegt wo, in welcher Fassung, gibt
es Neueres) und POST /system/werkzeuge/{name}/holen. HandBrake kommt
vollautomatisch von GitHub. MakeMKV wird NICHT mitgeliefert — Rippy laedt
die offizielle Datei und startet sie (Black-Box-Trennung, KONZEPT.md § 6).
makemkv.com antwortete beim Bauen mit HTTP 525; das wird im Klartext
gemeldet, und eine selbst geholte Datei bleibt moeglich.
HERZSCHLAG: /capabilities las die workers-Tabelle, die bisher nur der
Celery-Herzschlag fuellte. Im Standalone-Betrieb stand dort "0 Worker" und
die Encoder-Auswahl im UI blieb LEER — auf einem Rechner, der alles kann.
Jetzt meldet sich der Prozess selbst, mit dem, was caps.py MISST.
GEMESSEN, aus der fertigen EXE (29,0 MB):
bereit nach 1 s, keine Fehler im Log
Werkzeuge: beide gefunden, mit Version und Pfad
Worker: 1 (TobisNicerPC), 5 Encoder, 107 Presets
Die ganze Kette ist als Test festgehalten (test_kette.py): zustellen ->
einreihen -> Laeufer -> ablauf -> Job endet in einem EHRLICHEN Zustand.
Ohne Laufwerk geprueft, und das ist der wichtigere Fall: Ein Rip auf ein
totes Geraet muss zuegig scheitern, nicht auf "pending" haengenbleiben.
GEMESSEN: ruff sauber, 512 Tests gruen + 15 uebersprungen (vorher 489).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
102 lines
3.8 KiB
Python
102 lines
3.8 KiB
Python
"""Celery-Adapter: dieselben Task-Namen wie bisher, der Ablauf liegt in ablauf.py.
|
|
|
|
## Was sich geaendert hat (V2-4, 28.08.2026) — und was NICHT
|
|
|
|
Nicht geaendert: die Task-Namen (`worker.tasks.rip_disc`,
|
|
`worker.tasks.transcode_files`, `worker.tasks.scan_tracks`,
|
|
`worker.tasks.ping_worker`), die Argumente, die Queues, das Verhalten. Ein
|
|
laufender Docker-Betrieb merkt von diesem Umbau nichts — und ein bereits
|
|
installierter Windows-Worker aus v1 auch nicht.
|
|
|
|
Geaendert: Der ABLAUF steht nicht mehr hier. Diese Datei importierte auf
|
|
Modulebene `celery_app`, und damit war der gesamte Rip-Vorgang an einen
|
|
Broker gebunden. Im nativen Windows-Betrieb — der bewusst keinen hat — war
|
|
er ueberhaupt nicht ladbar.
|
|
|
|
Uebrig bleibt hier genau das, was WIRKLICH Celery ist: die Task-Huellen und
|
|
die Wahl der Ziel-Queue.
|
|
|
|
## Die zwei Rueckrufe
|
|
|
|
`ablauf.rippen()` weiss nicht, wer zuhoert. Diese Datei reicht ihm die
|
|
Celery-Fassung herein:
|
|
|
|
melde -> self.update_state(...) wie bisher
|
|
weiterreichen -> transcode_files.apply_async(queue=...)
|
|
|
|
Der Standalone-Laeufer reicht stattdessen seine eigenen herein — oder gar
|
|
keine, dann komprimiert `ablauf` gleich selbst.
|
|
"""
|
|
|
|
import os
|
|
|
|
import ablauf
|
|
from celery_app import celery_app
|
|
|
|
# Namen, die andere Module bisher aus tasks.py geholt haben. Sie liegen jetzt
|
|
# in ablauf.py; hier stehen sie weiter zur Verfuegung, damit kein Aufrufer
|
|
# angefasst werden muss.
|
|
RIP_FERTIG = ablauf.RIP_FERTIG
|
|
API_URL = ablauf.API_URL
|
|
pfad_lokal = ablauf.pfad_lokal
|
|
unter_wurzel = ablauf.unter_wurzel
|
|
erster_vorhandener_ordner = ablauf.erster_vorhandener_ordner
|
|
|
|
|
|
def _transcode_queue(node: str):
|
|
"""Ziel-Queue für die Kompression (siehe celery_client.transcode_queue):
|
|
gewählter Worker via worker_direct, wenn online — sonst geteilte Queue."""
|
|
if not node:
|
|
return "transcode"
|
|
try:
|
|
from celery.utils import worker_direct
|
|
antworten = celery_app.control.ping(timeout=1.0) or []
|
|
online = {k for antwort in antworten for k in antwort.keys()}
|
|
if node in online:
|
|
return worker_direct(node)
|
|
except Exception:
|
|
pass
|
|
return "transcode"
|
|
|
|
|
|
@celery_app.task(bind=True, name="worker.tasks.rip_disc")
|
|
def rip_disc(self, device_path: str, job_id: str, target_dir: str = None):
|
|
"""Rippt die Disc. Der Ablauf steht in ablauf.rippen()."""
|
|
|
|
def melde(zustand: dict) -> None:
|
|
self.update_state(state="PROGRESS", meta=zustand)
|
|
|
|
def weiterreichen(job: str, raw_dir: str, final_dir: str, knoten: str) -> None:
|
|
# Die Kompression als eigener Task — an den im Rip-Dialog GEWÄHLTEN
|
|
# Worker (worker_direct), sonst an die geteilte transcode-Queue
|
|
# (irgendein freier Worker, inkl. Remote-GPU).
|
|
ziel_queue = _transcode_queue(knoten)
|
|
if knoten and ziel_queue != "transcode":
|
|
ablauf.db.add_log("info", "worker",
|
|
f"Job {job}: Kompression gezielt an {knoten}")
|
|
transcode_files.apply_async(args=[job, raw_dir, final_dir], queue=ziel_queue)
|
|
|
|
return ablauf.rippen(device_path, job_id, target_dir,
|
|
melde=melde, weiterreichen=weiterreichen)
|
|
|
|
|
|
@celery_app.task(bind=True, name="worker.tasks.transcode_files")
|
|
def transcode_files(self, job_id: str, raw_dir: str, final_dir: str):
|
|
"""Komprimiert die Rohdaten. Der Ablauf steht in ablauf.komprimieren()."""
|
|
return ablauf.komprimieren(job_id, raw_dir, final_dir)
|
|
|
|
|
|
@celery_app.task(name="worker.tasks.scan_tracks")
|
|
def scan_tracks(device_path: str):
|
|
return ablauf.scan_tracks(device_path)
|
|
|
|
|
|
@celery_app.task(name="worker.tasks.ping_worker")
|
|
def ping_worker():
|
|
return ablauf.ping_worker()
|
|
|
|
|
|
# Der Anzeigename dieses Knotens — wird vom Herzschlag in celery_app.py
|
|
# benutzt und stand bisher hier.
|
|
WORKER_NAME = os.getenv("WORKER_NAME", "")
|