How metadata providers work
A metadata provider connects library requests to a catalogue or resource source through identification, retrieval, mapping and selection.
A provider supplies catalogue information or related resources to a library. The useful route begins with the intended entity and ends with selected library fields or images.
A poster can be missing even when the film's synopsis is present. Those outputs may depend on different requests, resources and selection rules.
From a hint to a selected record
A title/year search produces candidates. Choosing one establishes a provider-scoped identity; a subsequent lookup can obtain its description, dates, credits and associated references.
| Stage | Result |
|---|---|
| Candidate search | Possible matches |
| Identification | Selected catalogue entity |
| Record retrieval | Source fields and related references |
| Field mapping | Values recognized by the library model |
| Selection | Current values after applicable precedence |
A successful search is evidence about candidates. It does not mean the full record has already been imported.
Artwork is a related retrieval
A record may contain an image path or an asset identifier rather than the image bytes. The integration obtains a usable image resource, chooses its role/language/size and associates it with the item.
That gives several explanations for a synopsis with no poster: the matched source has no suitable asset, a reference did not yield bytes, the requested role/language was unavailable, or another image-selection decision applied.
Artwork providers can also use another catalogue's identity to find their assets. Those namespaces need a coherent cross-reference, not a guess based on equal-looking numbers.
Mapping retains meanings, not just strings
A provider's original title, translated title and sort label can occupy different fields. An episode record can refer to a parent series without being that series itself.
The integration must preserve those distinctions. A valid response can still be mapped into an unsuitable field or attached to the wrong local entity.
In Emby, Metadata Manager and the library's configured providers describe the product workflow. Precedence explains why a received candidate need not replace a protected or deliberately selected value.
A cache has a context
An original conceptual lookup key could include provider, entity type, identifier and requested language. Reusing a French response for an English request because only the numeric ID was retained loses that context.
Cached data also has acquisition/version history. Reading it today is different from obtaining a new response today. A missing-field refresh and a replacement operation can use the results differently.
These are interface relationships, not a universal cache-key or refresh algorithm. They let a comparison identify whether the missing boundary is identity, retrieval, field mapping or selection.
See Also
- Media identification
- Provider identifiers
- Metadata precedence
- Metadata providers in Emby Server
- Media artwork roles