Fetch subtitles from OpenSubtitles.com #187
No Assignees
Notifications
Due Date
No due date set.
Reference: yolo/arr#187
Reference in New Issue
Block a user
Implement the OpenSubtitles.com provider against the
Providertrait from#184. It is the primary provider: it has an official REST API, it distinguishes
pt-PT from pt-BR properly, and it supports
moviehashmatching, which is thesignal that wins ranking outright (DESIGN.md §15).
moviehashcomputed from the media file, and by TMDB id with theseason and episode numbers for TV, so both lanes feed the ranker.
group, source, uploader rating, download count, forced flag, SDH flag.
is #195's job, not this crate's.
database.
429when the cap is hit. Surfacethat as a distinct error the loop can recognise, rather than a generic
transport failure — #197 turns it into a visible queue state.
Never point tests at the live service. Fixture responses, as everywhere else in
this repo.
Depends on: #184
Integration note from the milestone driver, before you start.
This issue says "download a chosen candidate to a temporary path". The
Providertrait merged in #184 does not do that —downloadreturnsFetched { id, language, format, content: Vec<u8> }, the bytes in memory. That was a deliberate call and DESIGN.md §15 backs it:alassruns over the subtitle (#194) before it gets a name and a place in the title folder (#195), so a provider that wrote temp files would also own cleaning them up.Implement against the merged trait. The issue wording is the stale half.
Also: rank the candidates you return via
arr_core::subs::rank, and useCandidate::to_corefor the conversion rather than buildingSubtitleCandidateyourself — that mapping is decided in one place now (cdd6133).Implemented the OpenSubtitles.com provider in
crates/arr-subs/src/opensubtitles.rsagainst theProvidertrait from #184. Search runs both lanes:moviehashcomputed from the media file's own bytes (64 KiB end chunks per the OpenSubtitles algorithm, dropped for files too small to have two distinct ends) and TMDB id with season/episode for TV. Candidates carry hash match, release name, group and source (read off the release name witharr_parse::parse, so ranking shares one parser), uploader rating, download count, forced (foreign_parts_only) and SDH (hearing_impaired) — and are returned ordered best-first througharr_core::subs::rankviaCandidate::to_core. Download logs in on demand (/loginbasic auth, token cached, one refresh on mid-flight 401), posts/downloadfor a file id, then fetches the link bytes intoFetched; download needs user credentials and answersError::Unauthorizedwithout them. The daily cap (429, and 406 as documented) surfaces asError::RateLimited { retry_after }for #197. Credentials arrive asOpenSubtitlesConfig— config/env shaped, never database; Debug impls are hand-written so keys and tokens never render. Tests are wiremock fixtures plus hand-derived hash vectors; nothing touches the live service.Branch:
subtitles/187-opensubtitles(based onblitz/subtitles).just ci: passed — 542 tests green through the gate (exit 0).Findings
Providertrait, which returns bytes in memory. The driver's integration note already resolves this in favour of the trait; implemented accordingly.Error::Iois raised when the media file cannot be opened for hashing, but files under 128 KiB silently search without the hash lane. That matches the API's own behaviour, but #196's loop may want to surface "too small to hash" somewhere visible.downloadcan fillFetchedfrom an opaque id. If the loop ever holds a candidate id across a restart, it must re-search before downloading or it getsNotFound.