yolo/arr
3
0
Fork 0
Code Issues 12 Pull Requests Actions Packages Projects Releases Wiki Activity

Stop offering a forced subtitle grab #233

New Issue
Closed
opened 2026-08-25 08:36:54 +01:00 by naps62-yolo · 1 comment
naps62-yolo commented 2026-08-25 08:36:54 +01:00
Owner
Copy Link
Copy Source

POST /api/media-files/{id}/subtitles/grab still accepts forced: true and
writes the result to <video>.<lang>.srt — the same name a plain subtitle
uses. The flag, and the test
a_forced_grab_is_recorded_without_satisfying_the_language, predate the §15
amendment in ab001b5.

§15 now says a forced track never satisfies a want, gets no sidecar name of its
own, and that a language holds exactly one sidecar. So a forced manual grab
today either consumes the single slot that language has — leaving no room for
the real subtitle it was never meant to replace — or is refused by #222's new
invariant. Neither is a coherent thing to offer in an API.

Decide and make it one thing:

  • Remove the flag. Simplest, and matches §15: arr never goes looking for a
    forced track, and a manual grab of one has nowhere to put it. Ranking already
    rejects forced candidates, so the manual panel shows them in the rejected
    bucket with the rule that killed them — which is the honest answer.
  • Or give forced subtitles a real home, which means reopening the naming
    question §15 just closed. Not recommended; the operator settled it.

Whichever way, drop or rewrite the stale test, and make the manual panel agree
so a candidate the UI offers is one the API accepts.

Found while implementing #222.

Depends on: #203, #222

`POST /api/media-files/{id}/subtitles/grab` still accepts `forced: true` and writes the result to `<video>.<lang>.srt` — the same name a plain subtitle uses. The flag, and the test `a_forced_grab_is_recorded_without_satisfying_the_language`, predate the §15 amendment in ab001b5. §15 now says a forced track never satisfies a want, gets no sidecar name of its own, and that a language holds exactly one sidecar. So a forced manual grab today either consumes the single slot that language has — leaving no room for the real subtitle it was never meant to replace — or is refused by #222's new invariant. Neither is a coherent thing to offer in an API. Decide and make it one thing: - **Remove the flag.** Simplest, and matches §15: arr never goes looking for a forced track, and a manual grab of one has nowhere to put it. Ranking already rejects forced candidates, so the manual panel shows them in the rejected bucket with the rule that killed them — which is the honest answer. - **Or** give forced subtitles a real home, which means reopening the naming question §15 just closed. Not recommended; the operator settled it. Whichever way, drop or rewrite the stale test, and make the manual panel agree so a candidate the UI offers is one the API accepts. Found while implementing #222. Depends on: #203, #222
naps62-yolo added this to the Subtitles milestone 2026-08-25 08:36:54 +01:00
naps62-yolo added the area/apidifficulty/easytype/bugphase/9-subtitles labels 2026-08-25 08:36:54 +01:00
naps62-yolo commented 2026-08-25 08:45:32 +01:00
Author
Owner
Copy Link
Copy Source

Removed the forced flag from POST /api/media-files/{id}/subtitles/grab — the "Remove the flag" option from the issue. SubtitleGrabInput no longer has a forced field; the grab handler always writes a plain/SDH sidecar and always marks the language satisfied (the forced exception in finish is gone, since a forced candidate can never reach a grab any more). The manual panel already only renders a "grab" button on the eligible bucket, and ranking already rejects every forced candidate into the rejected bucket, so the frontend needed only the corresponding field dropped from the request body it sends — no UI logic change. Replaced the stale a_forced_grab_is_recorded_without_satisfying_the_language test with one asserting the grab body carries no forced key and the resulting subtitle is never forced.

Branch: subtitles/233-no-forced-grab.

just ci passed: 720/720 tests, clippy clean, check-tokens clean.

Findings

None outside this issue's scope.

Removed the `forced` flag from `POST /api/media-files/{id}/subtitles/grab` — the "Remove the flag" option from the issue. `SubtitleGrabInput` no longer has a `forced` field; the grab handler always writes a plain/SDH sidecar and always marks the language satisfied (the forced exception in `finish` is gone, since a forced candidate can never reach a grab any more). The manual panel already only renders a "grab" button on the eligible bucket, and ranking already rejects every forced candidate into the rejected bucket, so the frontend needed only the corresponding field dropped from the request body it sends — no UI logic change. Replaced the stale `a_forced_grab_is_recorded_without_satisfying_the_language` test with one asserting the grab body carries no `forced` key and the resulting subtitle is never forced. Branch: `subtitles/233-no-forced-grab`. `just ci` passed: 720/720 tests, clippy clean, `check-tokens` clean. ## Findings None outside this issue's scope.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/api
arr-api
 area/ci
CI and test harness
 area/compat
arr-compat
 area/core
arr-core
 area/daemon
arr-daemon
 area/db
arr-db
 area/dl
arr-dl
 area/indexer
arr-indexer
 area/infra
workspace and tooling
 area/meta
arr-meta
 area/parse
arr-parse
 area/probe
arr-probe
 area/subs
arr-subs crate: providers, extraction, translation, sync
 area/web
web/
 difficulty/easy
bounded, obvious approach, few files
 difficulty/hard
subtle correctness or cross-cutting
 difficulty/moderate
multiple files, judgement, an interface to design
 difficulty/trivial
one file, mechanical, no design decisions
 phase/1-skeleton
workspace, CI, config, database, empty API and SPA
 phase/2-logic
parsing and policy engine, pure, no network
 phase/3-sourcing
TMDB and Prowlarr, read-only
 phase/4-movies
movies end to end
 phase/5-ui
search, buckets, library views, queues
 phase/6-tv
seasons, episodes, tracking, derived status
 phase/7-people
owner tags and notifications
 phase/8-compat
Jellyseerr shim
 phase/9-subtitles
build order: subtitles, DESIGN.md §15
 type/bug
type/chore
type/feature
type/test
No Label area/api difficulty/easy phase/9-subtitles type/bug
Milestone
No items
No Milestone Subtitles
Projects
Clear projects
No project
Assignees
Clear assignees
hermes (Hermes (agent)) naps62 (Miguel Palhas) naps62-yolo (naps62-yolo (agent))
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: yolo/arr#233
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?