Where all the show information actually comes from

Here's something that isn't obvious until someone says it out loud: your video files contain almost none of the information you see on screen.

The poster, the episode title, the little synopsis, the cast list with photographs, the air date, the season artwork — none of that is inside the file. A video file is video, audio, and maybe subtitles. Everything else your media server shows you was downloaded from an online database, matched to your file by name, and cached locally.

That's why a badly-named file shows up blank and mysterious, and why a correctly-named one arrives fully dressed within seconds. The server isn't reading your file. It's looking your show up.

The three names you'll keep seeing

Why your server ignores the famous one

This is the question everyone eventually asks. IMDb is the biggest, best-known film and television database on earth. So why does essentially no media server pull its data from it?

The answer is licensing, not quality.

• IMDb has no free public API. The official one is an enterprise product sold through Amazon's data marketplace, with entry pricing reported around six figures a year. That is not a thing a free media server can build on.
• The free datasets are deliberately limited. IMDb publishes downloadable data files for personal, non-commercial use — but the terms specifically prohibit using them to build a database of movie information, which is precisely what a media server does.
• TMDB, by contrast, is free for non-commercial use with attribution. That single difference is most of why it became the default for the entire ecosystem.

So IMDb remains the place you go to settle an argument about an actor, while your server quietly uses somebody else's data. IMDb still shows up in your library, though — just as an identifier rather than a source. More on that shortly.

Why two of them, though?

It looks like pointless duplication until you notice they were built by different people to solve different problems.

TheTVDB grew up around television, in an era of people meticulously cataloguing episode guides. Its strength is granularity: every episode, every special, every alternate ordering, every air date. If you need to know exactly how a season was broken up, it's the better record.

TMDB grew up around film, with an emphasis on artwork and international coverage. Its posters and backdrops tend to be better curated, it handles many languages gracefully, and its television data — while good — models a season the way a network schedule does rather than the way an episode guide does.

Neither is the "correct" one. They're two reasonable answers built by two communities with different instincts, and both are maintained by volunteers.

Where they disagree, and why it lands in your lap

Mostly they agree. Where they don't, the disagreement can quietly scramble a show in your library.

• Hour-long episodes. Is a double-length episode one entry or two? They genuinely disagree, and this causes the single most confusing bug in home media. It has an entire article.
• Specials. Christmas episodes, retrospectives, webisodes — which count, and in what order? This is where they diverge most, and it's why you sometimes see a pile of untitled entries in a season 0.
• Revivals and remakes. Is a show returning after fifteen years a new season or a new show? Different answers produce very different libraries.
• Titles. International releases, alternate titles, and translated names don't always line up.

The practical consequence: your library tools follow TheTVDB, your media server probably defaults to TMDB, and when those two disagree, you are the one who notices.

The ID numbers that hold it together

Every database gives each title a permanent identifier. You've seen the IMDb one even if you never registered it — it's the tt0386676 in an IMDb address.

These IDs are how the whole ecosystem stays glued together. TMDB records a title's IMDb ID. TheTVDB records both. Your tools pass them around so that "this show" means the same thing across five programs, regardless of spelling, translation, or a stray subtitle.

This is also the reliable fix when a show matches to the wrong thing. Rather than fighting the filename, find the correct entry, grab its ID, and tell your software to use that specific record. Most tools accept an ID directly, and a match made that way stays made.

You're allowed to fix them

This is the part most people never realise, and it's genuinely satisfying.

TMDB and TheTVDB are community-maintained. Not "community" in a decorative sense — ordinary people create accounts and enter the data. If an episode title is wrong, a poster is missing, or a special is filed under the wrong season, you can sign up and correct it. Changes go through review and then propagate to everyone.

So when a show in your library has bad data, there are two fixes. The local one patches your copy. The upstream one fixes it for every person who ever looks that show up again. The second takes about the same amount of effort, and a surprising amount of what's good about these databases exists because somebody bothered.

Others you'll bump into

The short version

• Your files hold video and audio. Everything else is downloaded and matched by filename.
• TMDB — free and open, movie-leaning, strong artwork. Usually your server's default.
• TheTVDB — TV-first, deep episode detail. What your library tools follow.
• IMDb — the best known, but licensed in a way that keeps it out of media servers. It survives as an ID.
• The two your software uses sometimes disagree, and that disagreement causes real bugs.
• Both are community-edited. Wrong data is something you can go and fix.