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

One cue over the 60s bound rejects the whole sync #273

New Issue
Open
opened 2026-08-31 10:43:05 +01:00 by naps62-yolo · 0 comments
naps62-yolo commented 2026-08-31 10:43:05 +01:00
Owner
Copy Link
Copy Source

Two real grabs on consecutive Rick and Morty episodes were both rejected, both barely over the bound:

S01E01  reason=cue 216 moved 65.7s
S02E06  reason=cue 31 moved 63.9s

plausible (crates/arr-subs/src/sync.rs) uses find_map, so the first cue whose start moves more than MAX_SHIFT rejects the entire file regardless of what the other cues did:

input.iter().zip(output).enumerate().find_map(|(index, (before, after))| {
    let shift = after.start.abs_diff(before.start);
    (shift > MAX_SHIFT).then_some(Rejection::Shifted { index, shift })
})

alass aligns in segments rather than applying one global offset, so a single cue can move far more than the rest of the file. If that is what happened here, the rule is measuring the wrong thing: the question §15 wants answered is whether the subtitle as a whole was moved somewhere implausible, not whether any one cue was.

Two things are unverified and worth checking before changing anything:

  • Whether the other cues in these files moved by a small amount (a split artifact) or by a similar ~64s (a genuine global shift arr is right to refuse).
  • Whether these subtitles are timed for a different cut, in which case both rejections are correct and only the reporting is unhelpful.

The subtitle is kept either way, so this is not data loss — but the gap stays open in the queue with no indication of which of the two cases it is.

Found while verifying #272.

Two real grabs on consecutive Rick and Morty episodes were both rejected, both barely over the bound: ``` S01E01 reason=cue 216 moved 65.7s S02E06 reason=cue 31 moved 63.9s ``` `plausible` (crates/arr-subs/src/sync.rs) uses `find_map`, so the first cue whose start moves more than `MAX_SHIFT` rejects the entire file regardless of what the other cues did: ```rust input.iter().zip(output).enumerate().find_map(|(index, (before, after))| { let shift = after.start.abs_diff(before.start); (shift > MAX_SHIFT).then_some(Rejection::Shifted { index, shift }) }) ``` alass aligns in segments rather than applying one global offset, so a single cue can move far more than the rest of the file. If that is what happened here, the rule is measuring the wrong thing: the question §15 wants answered is whether the subtitle as a whole was moved somewhere implausible, not whether any one cue was. Two things are unverified and worth checking before changing anything: - Whether the other cues in these files moved by a small amount (a split artifact) or by a similar ~64s (a genuine global shift arr is right to refuse). - Whether these subtitles are timed for a different cut, in which case both rejections are correct and only the reporting is unhelpful. The subtitle is kept either way, so this is not data loss — but the gap stays open in the queue with no indication of which of the two cases it is. Found while verifying #272.
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
Milestone
No items
No Milestone
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#273
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?