Your episode descriptions don't match the episode

Here's the symptom, and it's oddly specific. You put on a show. The episodes play in the right order and nothing is obviously missing. But the little description under each one belongs to the next episode. The thumbnail is wrong too. And somewhere near the end of the season there are a few entries with no title at all, just Episode 15, Episode 16.

It feels like a corrupted download or a broken scanner. It's neither. It's two databases politely disagreeing, and your server picked a side without telling you.

The hour-long episode problem

Some shows air an occasional double-length episode. A season premiere, a wedding, a finale. The network calls it one episode with a runtime of an hour. But when that episode goes to streaming or syndication, it's usually chopped back into two normal-length halves.

So: is it one episode, or two? Both answers are defensible, and the two big metadata databases picked different ones. (If those names are new to you, here's what they are and why there are several.)

Neither is wrong. But your filenames follow one convention, and your media server follows the other. A file named S04E01-E02 - The Picnic.mkv is speaking TVDB. A server that thinks season 4 has 14 episodes is speaking TMDB.

What the mismatch actually does

The server sees a file claiming to be episodes 1 and 2, so it dutifully files it under both. Now episode 2's slot is occupied by episode 1's video. Everything downstream shifts by one. Then it happens again at the next hour-long episode, and shifts by two. By the end of the season your files have run out but the numbering hasn't, so the leftover slots sit there empty and untitled.

Mapped out, a real season 4 looked like this:

How to spot it

Open the season and compare each episode's position to the episode number written in its own filename. Most servers will show you the file path in the episode's info panel.

• Two different slots showing the exact same filename.
• A slot playing a file whose number doesn't match the slot's number.
• Untitled Episode NN entries at the end of a season.

Only seasons containing an hour-long episode will be affected. Seasons made entirely of normal-length episodes are untouched, which is exactly why this is so confusing — most of your library looks perfect.

Now check whether it's actually broken

This part matters enormously, and we learned it the expensive way. Those symptoms above catch two completely different situations that look identical from the outside. One needs fixing. The other is working exactly as intended, and "fixing" it would break it.

In the benign case your server and your files already agree — a genuine two-part episode simply lives in one file that covers both slots. Slightly redundant, entirely correct, and renaming it would only create a phantom missing episode.

The test that tells them apart

Look at the single-numbered files in the season — the ordinary ones, not the double-numbered one. For each, does the title your server shows at that episode number match the title in the filename?

• They all match → benign. Your numbering is already correct. Walk away.
• None match → shifted. Worth fixing.

A worked example: a season where slot 3 is titled "Hell Hath No Fury" and the file named S04E03 is also "Hell Hath No Fury" is fine, no matter how many slots that double-numbered file is occupying. A season where slot 3 says one thing and the S04E03 file says another is genuinely shifted.

Out of a library of eleven thousand episodes, thirteen shows tripped the initial symptoms. Only four were genuinely broken. If we'd renamed all thirteen, we'd have damaged nine shows that were working perfectly.

Fix 1: the setting (try this first)

Plex has a library-level preference that most people never find. Edit your TV library, open the Advanced tab, and look for Episode ordering. The options are "The Movie Database" and "TheTVDB." The default is TMDB.

If your files were named by an automated library manager, they're almost certainly TVDB-numbered, and switching this to TheTVDB is the correct setting going forward.

Fix 2: rename the files (reliable, per show)

The dependable fix is to make the filenames agree with whatever your server believes. Since each double-numbered file is genuinely one broadcast episode, you renumber the files so that each one lands on a single slot and the collision disappears.

The obvious approach is to list the files in order and number them 1, 2, 3… That works, but only if the season is complete. If a single episode is missing, sequential numbering pulls everything after the gap one slot too far forward and you've quietly mislabelled the back half of the season while trying to fix the front.

Use each file's own numbering instead, and track how far you've drifted:

offset = 0
for each file, in order of its starting episode number:
    new number = start − offset
    offset += (end − start)      # a double-numbered file consumes one extra

This gives the same answer on a complete season and the correct answer on one with holes in it, because it never assumes the file you're looking at is the nth episode — it only assumes the numbering drifts by one at each double-numbered file.

The mechanical version: list the distinct files in a season in order, then number them 1, 2, 3… ignoring the original double numbers entirely.

S04E01-E02 - The Picnic.mkv   →  S04E01 - The Picnic.mkv
S04E03-E04 - The Merger.mkv   →  S04E02 - The Merger.mkv
S04E05-E06 - The Launch.mkv   →  S04E03 - The Launch.mkv
S04E09 - The Ad.mkv           →  S04E05 - The Ad.mkv

Before you rename anything, three pieces of hard-won advice:

1. Check your work against the server's own titles. Your target for slot 5 should already be labelled "The Ad" in the interface. If every renamed file lands on a slot whose existing title matches, your mapping is right. That check caught nothing on a 62-file run — which is exactly how you want to find out you got it right.
2. Rename in two passes. Move everything to temporary names first, then to final names. Otherwise a file can collide with one that hasn't moved yet.
3. Write down what you changed. A plain text file of new-path → old-path makes the whole thing reversible. Ours got used, which is the entire argument for writing it.

Stop your library manager from undoing it

If an automated tool manages the show, it will happily rename everything back to its own convention and then start hunting for the "missing" episodes it thinks you now lack. Before renaming, set that series to unmonitored. For a show that finished airing years ago this costs you nothing — there's nothing left to catch.

Afterward, that tool's view of the show will look wrong: it still counts in the other numbering and will report missing episodes forever. That's cosmetic, and harmless while the series is unmonitored. Just don't re-enable monitoring later and forget why.

Then make the server notice

1. Scan the show's folder.
2. Empty the library's trash, or the old numbering lingers as ghost entries.
3. Refresh the show's metadata.

One side effect worth knowing: watch progress for the affected seasons may reset, because the server is now matching those files to different episode records. Untouched seasons keep their history.

So whose bug is this?

Nobody's, and that's why it survives. Both databases are internally consistent. Both orderings are legitimate. The server supports either one. Nothing is malfunctioning.

The actual failure is a defaults mismatch with no warning. The tools that name your files default to one convention, the server that reads them defaults to the other, and they only disagree on the handful of shows with hour-long episodes. So it quietly mangles four or five shows in an otherwise perfect library, presents as a scanner glitch, and the fix is a dropdown you'd have no reason to open.

The detection would be trivial, for what it's worth: a filename containing E01-E02 in a library set to TMDB ordering is an unambiguous signal. One warning at scan time would spare an awful lot of people an evening of confusion.

The short version

• Only affects seasons containing hour-long episodes.
• Content plays in order; descriptions and thumbnails are offset. Files are fine.
• Check whether it's actually broken before fixing it. If the ordinary single-numbered files already match your server's titles, nothing is wrong — a two-parter simply lives in one file.
• Check the season's last episode separately. A double-length finale hides from that test.
• Check the library's Episode ordering setting first.
• On an established library, renaming the files is the fix that actually holds.
• Unmonitor the series first, or your automation will undo it.
• Keep an undo list. You will want it.