Most media library problems aren’t storage problems, they’re organization problems. Enough drive space and a working RAID array doesn’t help if your media server can’t identify half your files, or if a “quick reorganization” three years from now turns into a multi-day project because everything’s tangled together. Here’s a folder and naming structure that holds up regardless of which media server you’re running, and why the small decisions you make on day one matter more than they seem to.

Why this matters more than it seems to

Plex, Jellyfin, and Emby all use scrapers, software that reads filenames and folder structure to identify what a piece of media actually is, then pulls metadata (posters, descriptions, cast info) from an online database. A file named movie.mkv sitting alone in a folder gives the scraper nothing to work with. A file named Blade Runner (1982).mkv in a folder called Blade Runner (1982) gives it everything it needs, matched correctly on the first pass, no manual fixing required.

Get this wrong at ingestion time and you’re not just fighting a slightly uglier library, you’re setting yourself up to manually re-match hundreds of items later, one at a time, through a web UI, which is exactly the kind of task nobody actually goes back and does. Get it right from the start and it stays right, automatically, as the library grows.

One library, separate top-level folders by type

Keep movies, TV shows, and anything else (music, audiobooks, home videos) in entirely separate top-level folders, not mixed together in one giant “Media” directory. This isn’t just tidiness, it directly affects how your media server scans and indexes content. Movies and TV shows use different scraper logic and different metadata structures, mixing them in one library in Plex or Jellyfin causes real matching problems, not just a messy view.

A sane top-level layout on your storage pool:

/media/movies/
/media/tv/
/media/music/
/media/home-videos/

Each of these becomes its own library in your media server, not a subfolder inside a shared one. This also makes permissions, backup rules, and storage placement easier to reason about independently, home videos probably deserve off-site backup in a way that your movie collection doesn’t.

Movies: one folder per film, year in the name

The standard, scraper-friendly movie structure is one folder per film, with the release year in both the folder name and the filename:

/media/movies/Blade Runner (1982)/Blade Runner (1982).mkv
/media/movies/The Matrix (1999)/The Matrix (1999).mkv

The year matters more than it looks like it should, because plenty of films share a title across different years (there are multiple movies simply called “The Thing,” “Dune,” or “Aladdin”). Without a year, a scraper is guessing, and it will sometimes guess wrong, silently attaching the wrong poster and description to your file. Include it every time, even for titles that feel unambiguous today, because you won’t remember which ones you skipped a year from now.

If you’re keeping extras (behind-the-scenes, deleted scenes, trailers), most media servers support an extras subfolder inside the movie’s folder, keep them there rather than loose in the main movies folder where they’ll get scanned as if they were their own films.

TV shows: show folder, season subfolders, consistent episode numbering

TV follows a similar per-item folder principle, but with an extra nesting level for seasons:

/media/tv/Breaking Bad/Season 01/Breaking Bad - S01E01 - Pilot.mkv
/media/tv/Breaking Bad/Season 02/Breaking Bad - S01E02 - ...

Two details matter more than they seem to here. First, zero-pad your season and episode numbers (S01E01, not S1E1). Sorting breaks without it, once you hit season or episode ten, S1E10 sorts before S1E2 in a naive alphabetical sort, and some scrapers fail to match altogether without the padding. Second, keep season folder naming consistent across your entire library (Season 01, not Season 1 in one show and S1 in another). Consistency is what lets you script against your library later, batch renames, batch permission fixes, automated organization tools, all of it assumes a predictable pattern, and a library that’s 90% consistent is nearly as much work to automate around as one that’s 0% consistent.

Filenames: skip the release-group tags in the final name

Downloaded or ripped media often arrives with release-group tags, resolution info, and codec details baked into the filename (Movie.Title.2023.1080p.BluRay.x264-GROUPNAME.mkv). That information isn’t useless, but it doesn’t belong in the primary filename your media server scans against, it adds noise that occasionally confuses scrapers and definitely clutters your library view. Rename to the clean Title (Year).ext format for the primary file, and if you genuinely want to preserve source info, most media servers let you see technical stream details (resolution, codec, bitrate) directly from the file itself without needing it spelled out in the name.

Automating this rename step is worth doing rather than doing it by hand. Tools built specifically for this (FileBot is the long-standing standard, and several *arr-stack tools like Radarr and Sonarr handle it automatically as part of their download-and-import pipeline) will rename and move files into the correct folder structure based on the same metadata sources your media server uses, so the naming stays consistent without you manually typing out folder names hundreds of times.

Separate your “working” storage from your “library” storage

If you’re actively downloading, converting, or processing media before it’s ready for the library, keep that work happening on separate storage from your actual library, not directly inside the library folders. A common, sane pattern:

  • /downloads/ (or similar): landing zone for incoming files, transcoding scratch space, anything mid-process
  • /media/: the finished, organized library your media server actually points at

This keeps half-downloaded or partially-renamed files out of your media server’s scan path, so it never tries to index something incomplete, and it means a download-tool failure or a bad transcode never touches your actual organized library. If your download storage and library storage are on genuinely different physical disks, this also isolates the write-heavy, high-churn download activity from your library disks, which see far less write activity once a file’s settled into place.

Plan your backup boundary before you need it

Folder structure isn’t just about media server scraping, it’s what determines how sane your backups are later. A library organized by type and consistently structured is trivial to back up selectively: maybe home videos and personal photos get a real off-site backup, while a movie collection you could re-acquire doesn’t, because it’s replaceable and backing it up would just be spending real money protecting something with no real recovery cost if lost.

That distinction only works cleanly if “replaceable” and “irreplaceable” content live in genuinely separate folder trees from the start. Mixing them means every backup decision becomes an exception-by-exception judgment call instead of a clean top-level rule, and exception-by-exception rules are exactly the kind of thing that quietly rot as a library grows and nobody remembers which specific subfolder was supposed to be excluded.

Bottom line

Separate top-level folders by media type, one folder per movie with the year included, season-subfoldered TV with zero-padded episode numbering, clean filenames without release-group noise, and a hard line between working/download storage and finished library storage. None of this is complicated, but it has to be decided before the library gets large, because reorganizing thousands of files after the fact is a real project, not a quick pass. Get the structure right at a hundred files and it’ll still be right at ten thousand, entirely on its own, with zero extra work from you as the collection grows.