A [boxset] or [playlist] directory reaches every library kind, and we file neither #212

Closed
opened 2026-09-12 19:06:31 +02:00 by Claude · 1 comment
Collaborator

BoxSetResolver and PlaylistResolver run at First priority for every collection type, and we file neither. Not a gap in one library kind: both have no collection-type gate at all, so a film library has it today just as a mixed one does.

Upstream

  • upstream/Emby.Server.Implementations/Library/Resolvers/BoxSetResolver.cs — a directory whose name carries [boxset] is a BoxSet, and what is inside it is resolved under that.
  • upstream/Emby.Server.Implementations/Library/Resolvers/PlaylistResolver.cs — a directory carrying [playlist] is a Playlist; and its _musicPlaylistCollectionTypes literally contains null, so with no collection type the resolver also claims loose .m3u-family files.

What we do

/movies/Set [boxset]/b.mkv files one Movie named "Set [boxset]". /mixed/Mix [playlist]/… files a Movie named "Mix [playlist]". A loose .m3u reaches nothing.

The bracket suffix ending up in the name is the visible half: a user sees Set [boxset] in a library view where upstream shows a collection.

Reach

crates/ephyra-app/src/scan/tree/ picks a function per kind; neither resolver has a home in any of them, and both run before the ones that do. Kind::BoxSet already exists (collections are served — crates/ephyra-http/tests/collections.rs), so this is the scan filing rows the rest of the server can already read.

Verifying

cargo xtask reference gen-library-kinds (xtask/src/reference/kinds.rs) is the answer key. A [boxset] directory and a [playlist] directory in the movies tree, and a loose .m3u plus a [playlist] directory in the mixed one, settle both resolvers and the priority order in one run.

Found reviewing #208.

`BoxSetResolver` and `PlaylistResolver` run at **`First`** priority for *every* collection type, and we file neither. Not a gap in one library kind: both have no collection-type gate at all, so a film library has it today just as a mixed one does. ## Upstream - `upstream/Emby.Server.Implementations/Library/Resolvers/BoxSetResolver.cs` — a directory whose name carries `[boxset]` is a `BoxSet`, and what is inside it is resolved under that. - `upstream/Emby.Server.Implementations/Library/Resolvers/PlaylistResolver.cs` — a directory carrying `[playlist]` is a `Playlist`; and its `_musicPlaylistCollectionTypes` literally contains `null`, so with no collection type the resolver also claims loose `.m3u`-family **files**. ## What we do `/movies/Set [boxset]/b.mkv` files one `Movie` named `"Set [boxset]"`. `/mixed/Mix [playlist]/…` files a `Movie` named `"Mix [playlist]"`. A loose `.m3u` reaches nothing. The bracket suffix ending up *in the name* is the visible half: a user sees `Set [boxset]` in a library view where upstream shows a collection. ## Reach `crates/ephyra-app/src/scan/tree/` picks a function per kind; neither resolver has a home in any of them, and both run before the ones that do. `Kind::BoxSet` already exists (collections are served — `crates/ephyra-http/tests/collections.rs`), so this is the scan filing rows the rest of the server can already read. ## Verifying `cargo xtask reference gen-library-kinds` (`xtask/src/reference/kinds.rs`) is the answer key. A `[boxset]` directory and a `[playlist]` directory in the `movies` tree, and a loose `.m3u` plus a `[playlist]` directory in the `mixed` one, settle both resolvers and the priority order in one run. Found reviewing #208.
Author
Collaborator

Fixed in fe6b37c8, landed on main at 53ac9c6c.

A new claim in crates/ephyra-app/src/scan/tree/claimed.rs runs before every library kind's own walk, as upstream's BoxSetResolver and PlaylistResolver do at First priority. The answer key records what upstream files, and ours now matches it in all seven libraries:

  • Set [boxset] is a BoxSet named "Set" — the tag is stripped and the name trimmed — and what is inside keeps its own name rather than collapsing into the folder.
  • Mix [playlist] is a Playlist named "Mix", with nothing filed below it.
  • A loose .m3u is a Playlist, in a mixed folder, in the mixed and music libraries, and nothing at all in a film library.

Verified by regenerating cargo xtask reference gen-library-kinds, which gained a tvshows and a music library along with these cases, and by a native scan of the whole tree.

The row a scan files is still empty: a playlist gets no members and no blob. That half is filed as #230.

Fixed in `fe6b37c8`, landed on `main` at `53ac9c6c`. A new claim in `crates/ephyra-app/src/scan/tree/claimed.rs` runs before every library kind's own walk, as upstream's `BoxSetResolver` and `PlaylistResolver` do at `First` priority. The answer key records what upstream files, and ours now matches it in all seven libraries: - `Set [boxset]` is a `BoxSet` named "Set" — the tag is stripped and the name trimmed — and what is inside keeps its own name rather than collapsing into the folder. - `Mix [playlist]` is a `Playlist` named "Mix", with nothing filed below it. - A loose `.m3u` is a `Playlist`, in a mixed folder, in the mixed and music libraries, and nothing at all in a film library. Verified by regenerating `cargo xtask reference gen-library-kinds`, which gained a tvshows and a music library along with these cases, and by a native scan of the whole tree. The row a scan files is still empty: a playlist gets no members and no blob. That half is filed as #230.
Sign in to join this conversation.
No description provided.