Library databases, identities and indexes

A library database organizes indexed media records and relationships for queries, while source files and user-specific state retain separate roles.

A library database stores records that help a media server find and organize its collection. Queries can select films, sort titles and connect records without reopening every media file for each request.

The database is a catalog of application information. It is not another copy of each film's encoded content.

A query uses stored relationships

An original logical record might include:

Item identity: item-A
Media location: /media/Film.mkv
Display title: The Example Film
Collection: Movies

The example describes roles rather than Emby's internal tables. Its public API exposes documented item fields; those fields are an API projection, not a specification of the database's on-disk schema.

Indexes can let a query find relevant records without visiting every row. They also occupy space and need updating when relevant data change.

Work Database consequence
Browse a sorted library Reads records and suitable indexes
Add discovered media Creates records and updates relationships
Change indexed metadata Updates records and relevant indexes
Record user activity Updates the supported user-state relationships
Rebuild an index Performs work without creating another media file

Scanning observes sources; browsing queries the catalog

A scan enumerates accessible media and performs the required analysis. Browsing generally uses the information already stored from those observations.

That separation explains why a title can remain visible during a storage outage. A catalog entry establishes that the server has a record; opening its source requires current storage access.

It also explains why a newly copied file may not appear until the relevant observation and catalog update complete.

Rebuilding is not a universal restoration

A scan can recreate information obtainable from source files and providers. It does not inherently recover every user-specific or manually configured relationship from a lost database.

Database files can also need companion journals and a supported version relationship. Transactions, write-ahead logging and application backups describe those consistency and recovery roles.

For Emby, use supported library and recovery operations instead of deriving an editing procedure from an illustrative table or API field name.

See Also

References