The deployed image ships §15 with translation compiled out and alass missing #257

Closed
opened 2026-08-25 22:45:40 +01:00 by naps62-yolo · 0 comments
Owner

The Subtitles milestone is deployed, and two parts of §15 are not actually
reachable in the running image.

1. Every translation backend is compiled out. Dockerfile builds with

RUN cargo build --release -p arr-daemon

and no --features. The four backends are default-off cargo features, so the
release image carries none of them. Production confirms it:

$ curl -s https://arr.n62.casa/api/settings/subtitles | jq .available_engines
[]

§15 makes translation the answer when no provider has a wanted language —
"arr translates immediately, there is no waiting window". With no backend
compiled in, that path cannot run, and /settings correctly shows "no
translation engine is compiled into this binary". just ci does not catch
this because lint and test both pass --all-features (#191, #192); the
Dockerfile is the only build that does not.

Which backends belong in the image is the decision here. translate-command
has no API-key cost and openai now points anywhere (#220), so those two are
the obvious floor.

2. alass is not installed. The runtime stage installs ffmpeg but not
alass:

RUN apt-get update \
    && apt-get install -y --no-install-recommends ffmpeg ca-certificates

Health says so:

"alass": { "status": "unreachable", "detail": "alass not found at alass" }

§15: "alass runs on every fetched and every translated subtitle. It is a
single small binary invoked like ffprobe, so it costs nothing at rest." It
is not in Debian, so this means fetching a release binary in the runtime
stage rather than an apt-get line.

Both are why /api/health currently reports degraded. The other two
degraded entries — opensubtitles credentials and podnapisi reachability — are
operator configuration and not this issue.

Found while merging the Subtitles milestone to main (425d154).

The Subtitles milestone is deployed, and two parts of §15 are not actually reachable in the running image. **1. Every translation backend is compiled out.** `Dockerfile` builds with ``` RUN cargo build --release -p arr-daemon ``` and no `--features`. The four backends are default-off cargo features, so the release image carries none of them. Production confirms it: ``` $ curl -s https://arr.n62.casa/api/settings/subtitles | jq .available_engines [] ``` §15 makes translation the answer when no provider has a wanted language — "arr translates immediately, there is no waiting window". With no backend compiled in, that path cannot run, and `/settings` correctly shows "no translation engine is compiled into this binary". `just ci` does not catch this because `lint` and `test` both pass `--all-features` (#191, #192); the Dockerfile is the only build that does not. Which backends belong in the image is the decision here. `translate-command` has no API-key cost and `openai` now points anywhere (#220), so those two are the obvious floor. **2. `alass` is not installed.** The runtime stage installs `ffmpeg` but not `alass`: ``` RUN apt-get update \ && apt-get install -y --no-install-recommends ffmpeg ca-certificates ``` Health says so: ``` "alass": { "status": "unreachable", "detail": "alass not found at alass" } ``` §15: "`alass` runs on every fetched and every translated subtitle. It is a single small binary invoked like `ffprobe`, so it costs nothing at rest." It is not in Debian, so this means fetching a release binary in the runtime stage rather than an `apt-get` line. Both are why `/api/health` currently reports `degraded`. The other two degraded entries — opensubtitles credentials and podnapisi reachability — are operator configuration and not this issue. Found while merging the Subtitles milestone to `main` (425d154).
naps62-yolo added the area/infradifficulty/moderatetype/bug labels 2026-08-25 22:45:46 +01:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: yolo/arr#257