Sync manually grabbed subtitles with alass #214
No Assignees
Notifications
Due Date
No due date set.
Reference: yolo/arr#214
Reference in New Issue
Block a user
#199 shipped the manual grab endpoint before the two things a grab has to do
to the bytes it fetched existed on the branch.
The conversion half is done —
srt_textincrates/arr-api/src/subtitles.rsnow calls
Fetched::to_srt(26bd25eonblitz/subtitles), so a providerserving VTT or ASS is converted rather than refused, and a format with no
parser fails before anything reaches the disk.
What remains is the sync half. A manually grabbed sidecar is still
recorded with
sync: "not_run". Once #194 lands, runalasson the fetchedsubtitle before the row is written, with the implausibility rules §15 states:
a shift beyond 60 seconds or lost cues keeps the unsynced original and flags
the file. #196 will call the same seam from the reconcile loop, so put it
somewhere both paths can reach rather than inline in the handler.
Depends on: #194, #199
Wire conversion and sync into the manual grabto Sync manually grabbed subtitles with alassImplemented the sync half of the manual grab:
POST /api/media-files/{id}/subtitles/grabnow runsalasson the fetched subtitle before the row is recorded, per §15's implausibility rules (a shift beyond 60s or lost cues keeps the unsynced original and flags the file).The seam lives in
arr-subs(Syncer::settle, newSyncState/Settledtypes), not inlined in the handler, so #196's reconcile loop can call the same function when it lands: it runsSyncer::sync, folds an accepted result into the content to write back, an implausible result into keeping the original with a warning logged, and — since alass has no health check yet (#200) — a spawn/timeout/non-zero failure degrades toNotRunwith a warning rather than failing the grab.AppStategained aSyncer(with_syncer, defaulting toalassonPATH); the daemon binary wires it fromconfig.alass_path, which already existed from #194 but was unused until now.Branch:
subtitles/214-grab-sync, based onblitz/subtitles.just ci: passed (642 tests).Findings
translate()(the/subtitles/translateendpoint) still records every machine translation withsync: "not_run". §15 says alass runs on "every fetched and every translated subtitle," but #214's issue body scoped this to the manual grab endpoint only ("A manually grabbed sidecar is still recorded with sync: not_run... run alass on the fetched subtitle"), so I left it out rather than widening scope. SameSyncer::settleseam applies there unchanged — it's a small follow-up.AppState::with_translation_backendsis never called inarr-daemon/src/main.rs. The daemon wiressubtitle_providersbut not translation backends, so/subtitles/translatecurrently 503s on every request in production regardless of compiled-in cargo features. Looks like a gap from #190/#191/#192, not something this issue touches.