Couch Potato Pal
the pal who remembers what's going on
Explainer 7 min read

What the *arr apps actually do

Sonarr, Radarr, Bazarr, and friends explained as what they are: librarians. A plain-language tour of the automation layer.

Spend ten minutes reading about home media servers and you'll trip over a family of similarly-named tools โ€” Sonarr, Radarr, Bazarr, and a handful of others. Everyone discusses them as if you already know what they are, which is unhelpful when you don't.

So, plainly: they're librarians. They don't play anything and they don't store anything. They watch over a collection of files and keep it tidy, named correctly, and consistently organized. That's the whole job.

What this article covers

The organizing and automation layer only โ€” naming, metadata, subtitles, requests, and library upkeep, for media you're entitled to have. Where files come from is out of scope here, and deliberately so.

The cast

ToolLooks afterWhat it actually does for you
SonarrTV seriesTracks seasons and episodes, names files consistently, spots gaps in a collection
RadarrMoviesSame idea, for films
BazarrSubtitlesFinds and keeps subtitles in sync across the whole library
Lidarr / ReadarrMusic / booksSame pattern applied to other media
Overseerr / JellyseerrRequestsGives household members a "can we get this?" page instead of texting you
RecyclarrSettingsSyncs community-maintained quality preferences so you don't hand-tune them

The naming is a running joke rather than a system โ€” Sonarr came first, the others followed the pattern, and by the time anyone noticed, it was too late. Collectively people write it as the *arr stack.

Why bother, if you already have a server

A media server displays what you point it at. It won't rename a badly-named file, won't notice you're missing episode 7, and won't find you subtitles. Once a collection passes a certain size, that manual upkeep becomes the whole hobby.

Concretely, the librarians are earning their keep when they:

That first one matters more than it sounds. Consistent naming is the foundation everything else rests on โ€” see the naming article.

Where they disagree with your server

Here's the friction nobody warns you about: the librarians and the server often use different metadata sources. The *arr tools are built around TheTVDB. Plex defaults to TMDB. Those two databases agree about almost everything โ€” until they don't.

The main flashpoint is shows with hour-long episodes, where the two databases genuinely disagree about how many episodes a season contains. Your librarian names the files one way, your server reads them the other way, and a handful of shows end up scrambled while the rest of the library looks perfect. It's the most confusing failure in home media and it gets its own article.

Worth internalizing the general lesson: when your server and your librarian disagree about reality, the disagreement is usually the bug โ€” not either tool individually.

Three things worth getting right early

  1. Path layout. Present one visible root to everything, so files can be linked rather than copied. Get this wrong and you silently store everything twice โ€” see the disk space article, and the NAS layout article for how the mounts should look. It's the single most common misconfiguration in the entire hobby.
  2. Stop chasing quality upgrades. Left unchecked, these tools will happily keep replacing files you already have with marginally better ones, forever. Filling gaps is worth automating. Endless upgrades mostly consume disk and bandwidth for differences you won't notice.
  3. Understand unmonitoring. Marking a series unmonitored tells the librarian to leave it alone. This is essential when you need to hand-correct something โ€” otherwise your careful fix gets reverted by automation an hour later. For a show that finished years ago, unmonitoring costs you nothing.

When something goes wrong

Nearly every problem in this stack is one of four things:

That's a genuinely useful checklist. Before assuming something is broken, ask which of those four it is. It's nearly always one of them, and each has a boring, findable cause.

The short version

Written for people running a personal media server for content they're entitled to have: their own disc rips, home video, over-the-air DVR recordings, and public-domain material. Nothing here is about obtaining media, and we don't cover that.