Season 2 is identified as Season 7. Why?

Plex Media Server Desktops & Laptops
1

Server Version#: 1.25.9.5721-965587f64

About the Inuyasha anime serie, you can see in this link that it has seven seasons:

WinSnap 03
WinSnap 03459×714 45.3 KB

Ok. So I added this anime serie into my library, in Spanish language which only has the first six seasons translated to Spanish, and the problem is that the season 02 is falsely recognized as season 07… but I don’t have a season 07, I just have from season 1 to 6.

I have hundreds of anime series in my library, I use the same file name pattern for each season (directory and its files), and It’s the first time that I see this kind of strange missmatch with a season…

WinSnap 01
WinSnap 01891×561 118 KB

WinSnap 02
WinSnap 021462×924 84 KB

( in the second image you can see the full file path of s02-e01)

I insist, I use same naming pattern for every other seasons for this serie, and those series are matched right, but this season has a strange missmatch that I don’t understand.

Updating metadata or analyzing the serie does not solve the issue.

Why is happening this and how to fix it (and without breaking my file name pattern)?.

Library settings:

WinSnap 04
WinSnap 04819×610 51.6 KB

Thanks for read.

2

Plex Documentation → Your Media → Naming & Organizing Your TV Show Files

71eb5b69f895a593babc5017c2072ceabd82ab8f

You need to rename your files according to Plex requirements. See the support documents linked above.

Which folder is added to the Plex TV show library?
What is the directory name after “Animation”? The one in square brackets?
Plex does not support subfolders between the folder added to the library and the show folder.

Also, the naming for the show folder, Inuyasha (2002-2004), and the individual episodes, Inuyasha {S02.E01} (Capitulo 028), is incorrect.

After renaming & reorganizing, Plex Dance the entire series.

Example:

x:\Series\Animation <-- "Animation" is folder added to Plex library, not "Series." 
                        "Series" cannot be added to any Plex library.  
                        Also, remove the directory in square brackets after "Animation."
...\Inuyasha (2000) {tvdb-71361} <-- show_name (year), TVDB ID optional
......\Season 01 <-- "Season" in English, Two digits for number
.........\Inuyasha (2000) - s01e01.mkv <-- sXXeYY is mandatory and cannot be in brackets/braces.
3

I insist, I use same naming pattern for every other seasons for this serie, and those series are matched right, but this season has a strange missmatch that I don’t understand.

I have hundreds of anime series in my library, I use the same file name pattern for each season (directory and its files), and It’s the first time that I see this kind of strange missmatch with a season…

how to fix it (and without breaking my file name pattern)?.

4

You got lucky. Your naming scheme might have worked, but has never been supported.

You might be able to use the new match hinting capability: Match Hinting for TV Series.

The new Plex TV Series scanner/agent is more particular than the old scanners/agents.

If your existing media is correctly recognized, then you do not necessarily need to rename it.

If Match Hinting does not work, then going forward, you will need to use the Plex recommended naming scheme to have your new media correctly recognized. If you add new episodes to an existing series, you may need to rename/restructure the entire series to have Plex recognize the new episodes.

There are tools that can help with the renaming/restructuring process.

1 Like
5

If I had a dollar for everytime someone had to hear this. Doesn’t matter if it sometimes works. If you want it to work all the time (or at least more so than now) why not try naming it the way the docs suggest?

4 Likes
6

If I were a developer of a software product that receives so many dollars for every time someone had to hear this, then I would propose and implement a intelligent mechanic in the algorithms of my source-code (in the file name parsers of the PLEX agent scanners) to catch pattern variants and adapting these variants as the pattern form that my algorithm expects to be, this way I’ll help minimize or totally reduce to zero the number of people who is affected by the same problem over and over again…

( Continues here: )

…instead of just pointing them to read an article to impose to him the ONLY way to name a file in order to avoid his problem.

Why not allowing the end-user to let him use a reasonable variant if he/she wants to do so?. It will not break ANYTHING and it will bring a important factor in any software like this: versatility, productivity and readability.

s11e11:
A ugly and hard-to-read identifier standardized from naming patterns in piracy scene just to maintain some order in their releases.

A file name alone is not hard to read, but it begins a lot hard to read when you have many files with sXXeXX in their file names in a directory…

[S11-E11]:
A cool and productive identifier (at least for me!) that helps the human sight to read, search and follow faster this pattern when used in file names.

…but that pattern using [ ] characters is not allowed anymore with the latest and current Plex Media Server update. Maybe the devs have decided versatility / productivity and readability is not an important factor for end-users, so now I’m being forced to use this:

{S11-E11}:
A not-so-cool and not-so-readable identifier like using [] characters, but still way better for the human sight than using s11e11 all together in lowercase and without using separator and grouping characters.

It’s all about productivity and readability for me.

Of these three ways of writing an identifier, only the first way is “supported”. The second form was “supported” until the latest update, and the third form is “supported” at least for now, since it’s not supposed to be written that way because {} are characters reserved for other things, but it works, so I call it “supported”.

@PLEX TEAM:
Allowing (again) versatility in file names is the key. Stop naming patterns impositions that excludes any little variant form of writing a season/episode number identifier, please.

7

When having hundreds of seasons from TV shows following the same naming pattern and every season is identified fine, then it is not a matter of luck. I mean if it works it is because it is allowed. You can call it “not supported” or “likely to break in the future”, but it is allowed from at least more than a year.

Thanks for the info. I was not aware of that feature.

I added a file “.plexmatch” inside “.\Inuyasha\Season 02\” directory with this file content:

# This directory contains the second season of Inuyasha
Title: Inuyasha
tvdbid: 71361
Season: 2

# The series' first season originally aired in 2000
Year: 2000

Then I updated the library and the tv show, but nothing changed, the Season 02 is still identified as Season 07 / “The final act”.

I’m not sure If I miss something to add in the .plexmatch file content.

8

That’s the thing, though, isn’t it? The naming convention isn’t to make it easier for you to read it. The names are to make it easier for your computer to read it. Having to parse multiple variations of what someone might think is a ‘reasonable variant’ isn’t easy. I work in speech analytics and we have AI programs to try and decide what people mean when they say different things and that research took years and millions of dollars. And we sell it for aboutas much too. PLEX is still essentially free. Certainly the part that scans your local media is free. The development costs required to do what you are asking for would be 1) huge and 2) provide no extra benefit to a product that already has a method of reducing errors when scanning media.

2 Likes
9

I consider the comparison unfair, and unrealistic. We can’t put in the same level a millionaire cost algorithm which due its nature of complexity depends on technological advances from AI science to evaluate human voice full of tones, rhythms and mutations (and other things that I’m not aware of because that is not my work place), with a primitive and immutable thing like a text character with specific encoding. In other words: we can’t put in the same level a voice recognition algorithm with a text parsing algorithm.

Programmatically speaking It’s thousand times easier (and yes, reasonable) to support the addition of a character in the middle of two words, than determining what a person says within the middle of two spoken words. And you know it.

Regular Expressions are a universal solution. Every modern language engine includes as a built-in feature its own RegEx motor (with it’s corresponding syntactic and semantic differences depending on the language engine) for free. It doesn’t cost millions to produce and maintain, nor does it cost decades of perfection. It has public, up-to-date documentation on the world wide web and accessible to anyone from a professional software developer to a 10-year-old kid. It is relatively easy to learn and use for any beginner, and definitely it does a great job to catch almost-any possible variant form of text.

But that was just a example that I put that almost everybody can understand to be able compare things in a realistic way.

There are basic and professional methodologies, from a simple string substraction or substring, up to complex text analyzers developed from scratch using sophisticated syntax trees that a developer would code to implement a faster and more deterministic parsing algorithm to parse text than the usage of RegEx, which at the end it could be a universal solution but also it is very slow, and does not give the developer full control line by line, breakpoint by breakpoint for debug the text parsing.

PLEX is a software that needs and chooses to interact with the user’s files, so PLEX should be adaptive (more than it already is) with different types of user file naming patterns.

At the moment that the PLEX file scanner is unable to correctly identify a file of a TV show episode because even though the file name contains an identifier PLEX does not know how to interpret certain characters around that identifier, then something is faulty in the programming of that algorithm, or maybe in the way of thinking of the developers who decide that the algorithm must behave like this.

We’re not talking about any crazy thing, it’s just that something like “s01e01” is correctly identified, while something just as simple as “[s01-e01]” is not. It is text, not voice, come on…

10

Time for my favorite quote!

Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.
2 Likes
11

True story, and more likely if the problem is having to parse data contained within an html document.

12

tramp78, I agree. The naming conventions are clear and the support articles for naming go into quite a bit of detail about what is required in order for titles to be read correctly. No, it may not suit the user to name them as required but, as you said, it’s not for the benefit of the user. So, if the user chooses not to name them as advised, saying it worked 499 times out of 500 is no reason to complain if it doesn’t work the 500th time. It was good luck rather than good management.

4 Likes
13

Closing this thread. It is essentially a duplicate of OPs prior post, where the same answer was provided.

1 Like