Extras: owner kinds the scan files none for, the survivors of a removed extra, and an answer key that cannot see ExtraType #253

New issue

Open

opened 2026-10-11 13:48:19 +02:00 by Claude · 0 comments

Claude commented

2026-10-11 13:48:19 +02:00

Collaborator

What is left of #250 after extras were filed, listed and access-checked.

Not ported

Extras are filed for a Movie, MusicVideo, Video, Series, Season and BoxSet. Upstream's SearchesContainingFolderForExtras (BaseItem.cs ~782-787) also reaches music albums, artists and other kinds. The removal sweep leaves such rows alone in an upstream-written database, so nothing is lost, but the scan files none.
When an extra is removed, upstream's "extra set changed" copy re-hands the owner's ratings, genres and studios to the surviving extras; here a removal goes through the sweep, not the save that carries the copy.
A trailers or extras folder under a season or series is still filed by the show tree as a plain folder (or a season when it holds a video). What upstream does there was not established.
/Items/{id}/Intros stays empty; upstream has no intro rows to serve on the fixture.

Measurement

crates/ephyra-app/corpus/library-kinds.json has no extra_type, top_parent_id or unrated_type per item, so the key holds an extra to its type, name, owner, parent and mixed flag only. The generator should emit them; the key is regenerated, never edited.
reference/var/library-kinds/state is stale: it has two extras and lacks the tvshows trailer the key has, so the snapshot-backed extras test covers two rows. Regenerating the state fixes it.
The route, count and filter tests in crates/ephyra-http/tests/it/extras.rs were written against the new behaviour and not mutation-checked, and the has* filters are exercised through ids= only.
Rests on reading: an extra filed with its owner stays unrated until the owner's next refresh hands it the copy, as upstream's call order has it.

What is left of #250 after extras were filed, listed and access-checked. **Not ported** - Extras are filed for a Movie, MusicVideo, Video, Series, Season and BoxSet. Upstream's `SearchesContainingFolderForExtras` (`BaseItem.cs` ~782-787) also reaches music albums, artists and other kinds. The removal sweep leaves such rows alone in an upstream-written database, so nothing is lost, but the scan files none. - When an extra is removed, upstream's "extra set changed" copy re-hands the owner's ratings, genres and studios to the surviving extras; here a removal goes through the sweep, not the save that carries the copy. - A `trailers` or `extras` folder under a season or series is still filed by the show tree as a plain folder (or a season when it holds a video). What upstream does there was not established. - `/Items/{id}/Intros` stays empty; upstream has no intro rows to serve on the fixture. **Measurement** - `crates/ephyra-app/corpus/library-kinds.json` has no `extra_type`, `top_parent_id` or `unrated_type` per item, so the key holds an extra to its type, name, owner, parent and mixed flag only. The generator should emit them; the key is regenerated, never edited. - `reference/var/library-kinds/state` is stale: it has two extras and lacks the tvshows trailer the key has, so the snapshot-backed extras test covers two rows. Regenerating the state fixes it. - The route, count and filter tests in `crates/ephyra-http/tests/it/extras.rs` were written against the new behaviour and not mutation-checked, and the `has*` filters are exercised through `ids=` only. - Rests on reading: an extra filed with its owner stays unrated until the owner's next refresh hands it the copy, as upstream's call order has it.