Skip to content

High CPU After Install

A new instance has a backlog to clear. It matches your library, reads every media file, searches your indexers for everything wanted, and builds local artwork overnight. Expect high CPU and disk activity for the first several hours and again on the first night. Each backlog drains once. After that, Scryer only handles what changes.

System → Jobs shows what is running.

A library scan walks each root, groups files into title folders, matches each folder to a title, and loads its metadata from the metadata gateway: ids, seasons, episodes, and artwork links. This is the Title Match phase of the scan progress, four titles at a time.

The first scan runs from setup or Scan library in the library settings. After that, Background Library Refresh runs at startup and every two hours, and only picks up new folders and files.

Scryer opens every media file and reads its container: video codec, resolution, bit depth, HDR format, audio codecs, channels and languages, subtitle tracks, and runtime. Quality decisions and upgrades use these facts rather than the filename. This is the Media Analysis phase of the scan, up to 24 files at a time. On network storage it is usually the longest phase. Later scans skip files that have not changed.

With indexers and a download client configured, the background search looks for every missing or below-cutoff item on every indexer, once. Parsing and scoring the results is where the CPU goes. See Indexer Coverage.

Titles added in the last three days count as recent, so on a new install the whole library is in the fast lane. Requests are still paced per indexer by rate limits and API quotas, so a large library on a strict indexer takes days to finish. Each item drops out once every indexer has been searched for it.

Neither the background search nor RSS runs until a download client is enabled. Adding the download client last keeps this work out of the way of the first scans.

Scryer serves posters, backdrops, and episode stills as AVIF images it encodes itself, at the sizes the UI displays, stored in Scryer’s database. The Artwork Encoding job builds them. It runs daily between 03:00 and 09:00 host local time, waits for library scans to finish, and encodes four images at a time on a fast CPU or two on a slower one. The first night on a large library does most of the work. Later nights only handle new titles. Run now in System → Jobs skips the window.

The encoded images are small and served straight from Scryer with long-lived cache headers, so poster grids load fast and do not depend on metadata providers being up. A title added since the last run shows provider artwork, fetched on demand and cached, until that night’s encode.

Between midnight and 06:00, Full Hash Backfill also hashes media files for duplicate detection and move verification. It is throttled and shows up mostly as disk reads.