feat(api): extract an embedded track on demand #261

Merged
naps62-yolo merged 1 commits from issue/260-extract-on-demand into main 2026-08-26 12:08:42 +01:00
Owner

Closes #260.

The reconcile loop extracts an embedded text track only while it is already translating a gap, so on a file where nothing is missing no sidecar is ever written and the translate lane says "nothing to translate from" about a file carrying an English text track.

  • /subtitles/status joins the codec in from media_files.probed and lists the file's extractable text tracks. Image-format tracks are never listed (§15 does not OCR); forced ones are not either, since a language has exactly one sidecar and no filename segment marks a forced one.
  • POST /api/media-files/{id}/subtitles/extract writes one track out. It claims the language and the path the same way a grab does, so a language that already has a sidecar is a 409. alass is deliberately not run: the track already carries the video's own timings.
  • The panel's source picker carries two groups — what is on the file, and what is inside the video. Picking from the second writes it out and it becomes an ordinary source.

The daemon now passes its configured ffmpeg_path to the API. It never did, so the health lamp probed whatever PATH resolved; the extract lane runs the same binary.

Verified

just ci green. Exercised end to end against a local daemon with a real .mkv: picking the pt-PT track wrote … - [1080p][WEB-DL].pt-PT.srt beside the video with the Portuguese cues, and the lane repainted with it as a source.

Closes #260. The reconcile loop extracts an embedded text track only while it is already translating a gap, so on a file where nothing is missing no sidecar is ever written and the translate lane says "nothing to translate from" about a file carrying an English text track. - `/subtitles/status` joins the codec in from `media_files.probed` and lists the file's extractable text tracks. Image-format tracks are never listed (§15 does not OCR); forced ones are not either, since a language has exactly one sidecar and no filename segment marks a forced one. - `POST /api/media-files/{id}/subtitles/extract` writes one track out. It claims the language and the path the same way a grab does, so a language that already has a sidecar is a 409. `alass` is deliberately not run: the track already carries the video's own timings. - The panel's source picker carries two groups — what is on the file, and what is inside the video. Picking from the second writes it out and it becomes an ordinary source. The daemon now passes its configured `ffmpeg_path` to the API. It never did, so the health lamp probed whatever `PATH` resolved; the extract lane runs the same binary. <details> <summary>Verified</summary> `just ci` green. Exercised end to end against a local daemon with a real `.mkv`: picking the `pt-PT` track wrote `… - [1080p][WEB-DL].pt-PT.srt` beside the video with the Portuguese cues, and the lane repainted with it as a source. </details>
naps62-yolo added 1 commit 2026-08-26 10:35:26 +01:00
feat(api): extract an embedded track on demand
ci / web (pull_request) Successful in 51s
ci / rust (pull_request) Successful in 3m19s
e2e / e2e (pull_request) Failing after 3m36s
73f521ee17
The reconcile loop extracts only while it is already translating a gap,
so on a file where nothing is missing no sidecar is ever written and the
panel's translate lane reports "nothing to translate from" about a file
carrying an English text track. §15 treats a manual action as bypassing
the wanted set, not as depending on it.

The status endpoint now joins the codec in from `media_files.probed` and
lists the extractable text tracks; the panel offers them in the source
picker and writes one out when it is picked.

Refs #260

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
naps62-yolo merged commit adb61dda3b into main 2026-08-26 12:08:42 +01:00
naps62-yolo deleted branch issue/260-extract-on-demand 2026-08-26 12:08:42 +01:00
Sign in to join this conversation.