Movie name cleaning diverges from upstream on punctuation #8
Loading…
Reference in a new issue
No description provided.
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?
268 of 284 movie names match upstream. The 16 that do not are all the name
cleaner being more aggressive about punctuation:
Note upstream keeps the year in
Nameexactly where its own parser failed toread one —
Star Trek Section 31 ()is upstream's output, empty parenthesesincluded. Matching upstream means reproducing that too.
Found by scanning
/mnt/media(285 movies, 289 shows, 74 music artists —~13 000 media files on a CIFS mount) with both this server and upstream
Jellyfin at the pinned commit, remote metadata and image fetchers disabled on
upstream so both were reading files only. Upstream was given the same mount
path so
MD5(UTF-16LE(path))agrees and rows compare directly.Fixed in
67805f3.The diagnosis in this issue was wrong. It is not a punctuation-cleaning
divergence — our
CLEAN_STRINGSis byte-identical to upstream's. Upstream namesa film after its folder, verbatim, wherever the folder holds it alone
(
MovieResolver.cs:491,movie.Name = Path.GetFileName(movie.ContainingFolderPath)),and we were always naming from the cleaned file. The folder says
I, Robot (2004); the file saysI Robot (2004) [imdbid-tt0343818] - [...].All 284 movie names now match upstream, up from 268.
Review found the first cut of the guard too loose, and three regressions in it,
all now fixed and pinned:
one does not cost it the folder's name — but it counts extras too when
deciding whether it is among siblings. Two predicates, not one.
all, so it does not name the film
CD 01orVIDEO_TSwas being named after the plumbingThat a disc rip is filed once per disc rather than once per release is unchanged
and is #26.