A film's crew is ordered differently than upstream orders it, and the check was relaxed around it #156

New issue

Closed

opened 2026-08-16 21:44:22 +02:00 by Claude · 1 comment

Claude commented

2026-08-16 21:44:22 +02:00

Collaborator

A film's crew comes out of this server in a different order than upstream's,
and the assertion that would have caught it was relaxed to land batch E.

crates/jellyfin-app/tests/scan_enriched.rs (crewed) and
crates/jellyfin-app/tests/tmdb.rs previously compared the people list
position by position, including ListOrder. They now sort the crew and drop
ListOrder, with the comment stating the fact plainly: the answer the pass
replays lists a film's producer before its director, and the row has them the
other way round.

ListOrder is upstream's ordering key for the People list
(upstream/Jellyfin.Server.Implementations/Item/PeopleRepository.cs:43,294), so
this is what a client shows under a film, in the order it shows it. The cast
half is still compared exactly, so the divergence is confined to permutations
within the crew's own slots — but it is a divergence from upstream, not a test
artifact, and the suite can no longer catch a regression in it.

This was filed rather than fixed because it wants the ordering question
answered rather than the assertion re-tightened: what decides a crew member's
ListOrder upstream, and whether crate::scan::people::add's filing order is
what disagrees.

How to know it is done

The two assertions compare the crew position by position again, ListOrder
included, against the answer key — and fail if the order is perturbed.

House rules

CLAUDE.md is the short version and these are the parts that bite: tests run
under cargo nextest; upstream's source is the checkout in upstream/ at the
pin (v12.0-rc5, 6d501ba4) and not the clone beside the repository;
generated files are regenerated rather than edited; a comment says what the code
does, not how it got there; and Dn references stay out of code and comments.

A test that cannot fail is not a check — this issue exists because one stopped
being able to.

A film's crew comes out of this server in a different order than upstream's, and the assertion that would have caught it was relaxed to land batch E. `crates/jellyfin-app/tests/scan_enriched.rs` (`crewed`) and `crates/jellyfin-app/tests/tmdb.rs` previously compared the people list position by position, including `ListOrder`. They now sort the crew and drop `ListOrder`, with the comment stating the fact plainly: the answer the pass replays lists a film's producer before its director, and the row has them the other way round. `ListOrder` is upstream's ordering key for the People list (`upstream/Jellyfin.Server.Implementations/Item/PeopleRepository.cs:43,294`), so this is what a client shows under a film, in the order it shows it. The cast half is still compared exactly, so the divergence is confined to permutations within the crew's own slots — but it is a divergence from upstream, not a test artifact, and the suite can no longer catch a regression in it. This was filed rather than fixed because it wants the ordering question answered rather than the assertion re-tightened: what decides a crew member's `ListOrder` upstream, and whether `crate::scan::people::add`'s filing order is what disagrees. ## How to know it is done The two assertions compare the crew position by position again, `ListOrder` included, against the answer key — and fail if the order is perturbed. ### House rules `CLAUDE.md` is the short version and these are the parts that bite: tests run under `cargo nextest`; upstream's source is the checkout in `upstream/` **at the pin** (`v12.0-rc5`, `6d501ba4`) and not the clone beside the repository; generated files are regenerated rather than edited; a comment says what the code does, not how it got there; and `Dn` references stay out of code and comments. A test that cannot fail is not a check — this issue exists because one stopped being able to.

Claude referenced this issue

2026-08-16 21:45:09 +02:00

A person has no biography, and a box set takes nothing from TMDb #107

Claude referenced this issue

2026-08-16 21:45:09 +02:00

OMDb is not written: no ratings, no critic scores, no episode fallback #108

Claude referenced this issue

2026-08-16 21:45:09 +02:00

Music metadata is entirely absent: MusicBrainz and AudioDb are both in the box upstream #109

Claude

2026-08-20 17:31:11 +02:00

closed this issue
added the
correctness

p2

providers
labels

Claude commented

2026-08-21 08:21:14 +02:00

Author

Collaborator

Closed by 898f22b, but not the way the issue asked — the assertion could not be re-tightened, because a crew's order is not a fact the two halves of the pair can agree on.

What decides a crew member's ListOrder upstream: its position in the list handed to PeopleRepository.UpdatePeople, which numbers distinctCredits 0 upward (PeopleRepository.cs:167-195). That list is the provider's append order: TmdbMovieProvider adds the cast sorted by order, then walks credits.crew in array order, keeping the (department, job) pairs TmdbUtils.WantedCrewKinds and _writerJobs name. Nothing between the provider and the row reorders it — PeopleHelper.AddPerson appends, MergePeople only fills fields, and MergeData assigns the list whole.

scan::people::add is not what disagrees. The port does the same thing, and its output for Alien is the recorded answer's array order, entry for entry.

What disagrees is TMDb. Its credits.crew array carries no stated ranking and comes back ordered differently between two answers about one film — 348 in de-DE and fr-FR puts Walter Hill first where en-US puts Ridley Scott. Upstream's fetch and the corpus recording are two separate calls, so the two halves can be handed two orders. Measured twice: the committed pair (snapshot of 2026-08-16) has Ridley Scott at ListOrder 9 and Gordon Carroll at 10 while its recording lists Carroll first; a pair provisioned and cut fresh today has them the other way round, again inverted against its own recording. Re-cutting both halves together does not settle it.

What landed instead:

the cast keeps its position-by-position comparison, SortOrder included — it carries order, the provider sorts on it, and both halves agree about it;
the crew is compared against the answer key on who is in it, with the reason stated where the comparison is rather than the wrong one that was there;
a new check, the_crew_is_filed_in_the_order_the_answer_listed_it in crates/ephyra-app/tests/tmdb.rs, holds the port to the order of the answer it replays — the one place the order is a fact. Verified to fail on a perturbed filing order;
crates/ephyra-app/corpus/README.md gains the note, beside its sibling about the two JPEG encodings image.tmdb.org serves.

Closed by `898f22b`, but not the way the issue asked — the assertion could not be re-tightened, because a crew's order is not a fact the two halves of the pair can agree on. **What decides a crew member's `ListOrder` upstream:** its position in the list handed to `PeopleRepository.UpdatePeople`, which numbers `distinctCredits` 0 upward (`PeopleRepository.cs:167-195`). That list is the provider's append order: `TmdbMovieProvider` adds the cast sorted by `order`, then walks `credits.crew` in array order, keeping the `(department, job)` pairs `TmdbUtils.WantedCrewKinds` and `_writerJobs` name. Nothing between the provider and the row reorders it — `PeopleHelper.AddPerson` appends, `MergePeople` only fills fields, and `MergeData` assigns the list whole. **`scan::people::add` is not what disagrees.** The port does the same thing, and its output for Alien is the recorded answer's array order, entry for entry. **What disagrees is TMDb.** Its `credits.crew` array carries no stated ranking and comes back ordered differently between two answers about one film — `348` in `de-DE` and `fr-FR` puts Walter Hill first where `en-US` puts Ridley Scott. Upstream's fetch and the corpus recording are two separate calls, so the two halves can be handed two orders. Measured twice: the committed pair (snapshot of 2026-08-16) has Ridley Scott at `ListOrder` 9 and Gordon Carroll at 10 while its recording lists Carroll first; a pair provisioned and cut fresh today has them the other way round, again inverted against its own recording. Re-cutting both halves together does not settle it. **What landed instead:** - the cast keeps its position-by-position comparison, `SortOrder` included — it carries `order`, the provider sorts on it, and both halves agree about it; - the crew is compared against the answer key on who is in it, with the reason stated where the comparison is rather than the wrong one that was there; - a new check, `the_crew_is_filed_in_the_order_the_answer_listed_it` in `crates/ephyra-app/tests/tmdb.rs`, holds the port to the order of the answer it replays — the one place the order is a fact. Verified to fail on a perturbed filing order; - `crates/ephyra-app/corpus/README.md` gains the note, beside its sibling about the two JPEG encodings `image.tmdb.org` serves.