The library dialog is offered no metadata providers, so fetching cannot be turned on #170

New issue

Closed

opened 2026-08-21 12:05:28 +02:00 by Claude · 1 comment

Claude commented

2026-08-21 12:05:28 +02:00

Collaborator

There is no way to turn metadata fetching on from a client. The library dialog
renders its "Metadata downloaders", "Image fetchers" and "Metadata savers"
sections from /Libraries/AvailableOptions, and we answer every list empty:

{"LyricFetchers": [], "MediaSegmentProviders": [], "MetadataReaders": [],
 "MetadataSavers": [], "SubtitleFetchers": [], "TypeOptions": []}

crates/ephyra-http/src/routes/library/structure/reading.rs::available_options
returns LibraryOptionsResultDto::default() and reads nothing at all — not the
providers, not the requested content type, not isNewLibrary. Upstream's
LibraryController.GetLibraryOptionsInfo (Jellyfin.Api/Controllers/LibraryController.cs:864)
builds each list from the metadata plugins registered for the item types the
content type covers, which is what puts the checkboxes on the page.

The providers are here. crates/ephyra-app/src/metadata/ holds tmdb/,
omdb.rs (The Open Movie Database), musicbrainz.rs, audiodb.rs and
artwork.rs, and crates/ephyra-server/src/libraries.rs:431 falls back to
TmdbUtils.ApiKey so a server configured with no key still asks what upstream
would ask. What decides whether any of it runs is LibraryConfig::fetch_metadata
— one boolean per library, reachable by editing config.toml and by nothing
else.

The result on a fresh install: every item keeps the name of the folder it was
found in, has no overview, no rating, no genres, and a still cut by ffmpeg where
a poster would be. Nothing in the dashboard says why, because the page that
would say so has no controls on it.

This is the read half of the same wall as #167, which is the write half — the
options a client does post are dropped. Either alone leaves fetching
unreachable.

Where to start

available_options needs the providers named per item type, in
LibraryOptionsResultDto's shape: TypeOptions carrying MetadataFetchers and
ImageFetchers for each representative type of the content type asked about,
and MetadataReaders/MetadataSavers for the NFO reading and writing this
server does. Names have to be upstream's own, because they are what a posted
LibraryOptions names back.

Fixing this without #167 changes nothing a user can see: the checkboxes would
appear and be discarded on save.

How to know it is done

The library dialog shows the downloaders on a fresh install, ticking one and
saving leaves it ticked after a reload, and the next scan of that library fills
in overviews and posters. A test over the route that asks what a movies library
is offered, failing today.

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; generated files are regenerated rather than edited; a comment says what
the code does, not how it got there.

A test that cannot fail is worse than none.

There is no way to turn metadata fetching on from a client. The library dialog renders its "Metadata downloaders", "Image fetchers" and "Metadata savers" sections from `/Libraries/AvailableOptions`, and we answer every list empty: {"LyricFetchers": [], "MediaSegmentProviders": [], "MetadataReaders": [], "MetadataSavers": [], "SubtitleFetchers": [], "TypeOptions": []} `crates/ephyra-http/src/routes/library/structure/reading.rs::available_options` returns `LibraryOptionsResultDto::default()` and reads nothing at all — not the providers, not the requested content type, not `isNewLibrary`. Upstream's `LibraryController.GetLibraryOptionsInfo` (`Jellyfin.Api/Controllers/LibraryController.cs:864`) builds each list from the metadata plugins registered for the item types the content type covers, which is what puts the checkboxes on the page. **The providers are here.** `crates/ephyra-app/src/metadata/` holds `tmdb/`, `omdb.rs` (`The Open Movie Database`), `musicbrainz.rs`, `audiodb.rs` and `artwork.rs`, and `crates/ephyra-server/src/libraries.rs:431` falls back to `TmdbUtils.ApiKey` so a server configured with no key still asks what upstream would ask. What decides whether any of it runs is `LibraryConfig::fetch_metadata` — one boolean per library, reachable by editing `config.toml` and by nothing else. The result on a fresh install: every item keeps the name of the folder it was found in, has no overview, no rating, no genres, and a still cut by ffmpeg where a poster would be. Nothing in the dashboard says why, because the page that would say so has no controls on it. This is the read half of the same wall as #167, which is the write half — the options a client does post are dropped. Either alone leaves fetching unreachable. ## Where to start `available_options` needs the providers named per item type, in `LibraryOptionsResultDto`'s shape: `TypeOptions` carrying `MetadataFetchers` and `ImageFetchers` for each representative type of the content type asked about, and `MetadataReaders`/`MetadataSavers` for the NFO reading and writing this server does. Names have to be upstream's own, because they are what a posted `LibraryOptions` names back. Fixing this without #167 changes nothing a user can see: the checkboxes would appear and be discarded on save. ## How to know it is done The library dialog shows the downloaders on a fresh install, ticking one and saving leaves it ticked after a reload, and the next scan of that library fills in overviews and posters. A test over the route that asks what a movies library is offered, failing today. ### 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**; generated files are regenerated rather than edited; a comment says what the code does, not how it got there. A test that cannot fail is worse than none.

Claude added the

correctness

http

providers

labels

2026-08-21 12:05:28 +02:00

Claude commented

2026-08-21 15:21:19 +02:00

Author

Collaborator

Landed in 7cd13b3, with review fixes in 9f43537.

/Libraries/AvailableOptions names the databases this server actually asks,
per representative item type, under upstream's own plugin names — a client posts
those names back in LibraryOptions, so the spelling is the contract.
crates/ephyra-app/src/metadata/offered.rs is where that lives, beside the
providers rather than in the route.

What will not run is left out rather than offered and ignored: no subtitle or
lyric fetcher, no media segment provider, no similar-item provider, and no
metadata saver — the scan reads an .nfo and never writes one, so offering the
saver would be a checkbox nothing honours.

Three things the review corrected, all of which a client could see:

Artwork Repository was offered as the image fetcher for artists and albums.
It is upstream's StudiosImageProvider and Supports is item is Studio;
our own scan fetches artist and album images from TheAudioDB
(scan/run/remote.rs), which is what upstream registers too.
An existing library was reported with everything ticked. Upstream's shipped
ServerConfiguration disables things out of the box —
DisabledMetadataFetchers = ["TheAudioDB"] for both MusicAlbum and
MusicArtist — so a music library now reports those unticked, as upstream
does.
The NFO reader was offered for every content type. Upstream filters readers to
the plugins whose item type the content type covers, and
MediaBrowser.XbmcMetadata registers none for Book, BoxSet, Playlist or
Photo, so a library of those is offered no reader and the dialog draws no
section for one.

Fixing this alone would have changed nothing a user can see, which is why it
went in with #167.

Landed in 7cd13b3, with review fixes in 9f43537. `/Libraries/AvailableOptions` names the databases this server actually asks, per representative item type, under upstream's own plugin names — a client posts those names back in `LibraryOptions`, so the spelling is the contract. `crates/ephyra-app/src/metadata/offered.rs` is where that lives, beside the providers rather than in the route. What will not run is left out rather than offered and ignored: no subtitle or lyric fetcher, no media segment provider, no similar-item provider, and no metadata saver — the scan reads an `.nfo` and never writes one, so offering the saver would be a checkbox nothing honours. Three things the review corrected, all of which a client could see: - `Artwork Repository` was offered as the image fetcher for artists and albums. It is upstream's `StudiosImageProvider` and `Supports` is `item is Studio`; our own scan fetches artist and album images from TheAudioDB (`scan/run/remote.rs`), which is what upstream registers too. - An existing library was reported with everything ticked. Upstream's shipped `ServerConfiguration` disables things out of the box — `DisabledMetadataFetchers = ["TheAudioDB"]` for both `MusicAlbum` and `MusicArtist` — so a music library now reports those unticked, as upstream does. - The NFO reader was offered for every content type. Upstream filters readers to the plugins whose item type the content type covers, and `MediaBrowser.XbmcMetadata` registers none for Book, BoxSet, Playlist or Photo, so a library of those is offered no reader and the dialog draws no section for one. Fixing this alone would have changed nothing a user can see, which is why it went in with #167.

Claude closed this issue

2026-08-21 15:21:19 +02:00