Also, I have no idea how to search for this, other than perhaps reading tons of lengthy threads, but today I noticed another inconsistency related to extras naming:
When adding extras at the episode-level, let’s say the base name is Series S01 E01 - Title.ext
Filename: Series S01 E01 - Title - Deleted Scene Name-deleted.ext
Shows up as: Series S01 E01 - Title - Deleted Scene Name / Deleted Scene
Filename: Series S01 E01 - Title-trailer.ext
Shows up as: Series S01 E01 - Title / Trailer
Filename: Series S01 E01 - Title - Interview Name-interview.ext
Shows up as: Interview Name / Interview
Filename: Series S01 E01 - Title - Scene Name-scene.ext
Shows up as: Scene Name / Scene
Given the layout of the iOS and Android apps, the shortened display text for interviews and scenes is much much cleaner. Why the system treats the various extras types differently seems to me like an oversight bug. I haven’t tried all extras types yet but at the very least, deleted scenes and trailers behave differently than scenes and interviews, with the latter pair’s behavior being my preference.
This can happen if the Deleted Scene Name section contains a - (“dash”).
Most server host platforms support using alternate characters, e.g. – (“en dash”), — (“em dash”), or ‑ (“soft hyphen”).
All of my file names contain at least one dash. In the examples I provided above, which originate from poking around in the X-Files, there’s still some sort of inconsistency present if dashes are the cause.
The Deleted Scene has two dashes and behaves not as desired.
The Trailer has one dash and behaves not as desired.
The Interview and the Scene each have two dashes and behave as desired.
The Interview and Scene cases suggest that the presence of dashes alone isn’t the cause, since there are two preceding their -extra flags.
The deleted scene for the episode I’m poking at does have a # character in it, though.
Removing it doesn’t change the behavior.
Removing one dash and the # sign results in the file title being presented as deleted1.
Removing both dashes and the # sign results in the deleted scene disappearing altogether.
I’m not sure I see how replacing dashes with alternate dashes could solve the problem.
Edit: Whether or not there are multiple extras of a type matters. When applying the convention -extra1, -extra2, etc. when multiples exist, there seems to be no possible way to get the extra’s name to appear in the client. However, using a dash to separate the episode title from the extra name, and avoiding the the -extra# indexing convention seems to work. This suggests that the regex(es) used to parse the names yields inconsistent results depending on whether the -extra# indexing is used.
Works: Series S01 E01 - Title - Deleted Scene Name #1-deleted.ext
Doesn’t Work: Series S01 E01 - Title[any combination of anything tried]-deleted1.ext
I’ve moved this into a separate thread as it’s not so much related to the feature suggestion where you originally posted / I responded.
Would you mind sharing the exact file names?
Don’t use -deleted# (with # representing a number) with named local episode extras. Just use -deleted as file name suffix if you include a title for the extra. The numbered suffix is only required if you don’t distinguish multiple extras of the same type for the same episode.
Yes, sorry about that - train of thought - I didn’t mean to go off topic.
Following the guidance provided here, I’ve discovered that the resulting display names are inconsistently rendered. This behavior seems to effect all TV series, though, I happened to be working on the X-Files when I noticed it.
Filename
Displayed name
Notes
X-Files S01 E01 - Pilot-trailer
X-Files S01 E01 - Pilot
Original naming attempt
X-Files S01 E01 - Trailer-trailer
(Not detected)
Expected behavior
X-Files S01 E01 - Pilot - Trailer-trailer
Trailer
Acceptable compromise. Wasn’t expecting to need to give the trailer a name.
X-Files S01 E01 - Pilot (Chris Carter)-interview
X-Files S01 E01 - Pilot (Chris Carter)
Original naming attempt. Didn’t realize the next line would work better.
X-Files S01 E01 - Pilot - Chris Carter-interview
Chris Carter
Expected behavior
X-Files S01 E03 - Squeeze-trailer1
trailer1
Works better than the single-trailer case but looks odd
X-Files S01 E03 - Squeeze-trailer2
trailer2
Works better than the single-trailer case but looks odd
X-Files S01 E03 - Squeeze - Trailer 1-trailer
Trailer 1
Taking advantage of the unique title, the -trailer# convention is dropped in favor of the -trailer convention.
X-Files S01 E03 - Squeeze - Trailer 2-trailer
Trailer 2
Ditto
X-Files S01 E01 - Pilot (Deleted Scene #1)-deleted
X-Files S01 E01 - Pilot (Deleted Scene #1)
Original naming attempt
X-Files S01 E01 - Pilot (Deleted Scene #2)-deleted
X-Files S01 E01 - Pilot (Deleted Scene #2)
Original naming attempt
X-Files S01 E01 - Pilot (Deleted Scene 1)-deleted
X-Files S01 E01 - Pilot (Deleted Scene 1)
Removed # character
X-Files S01 E01 - Pilot Deleted Scene 1-deleted
X-Files S01 E01 - Pilot Deleted Scene 1
Removed () characters
X-Files S01 E01 - Pilot (Deleted Scene)-deleted1
X-Files S01 E01 - Pilot (Deleted Scene)
Tried the -extra# convention
X-Files S01 E01 - Pilot - Deleted Scene #1-deleted
Deleted Scene #1
Added # back, added extra dash. Acceptable result.
Takeaways:
Dashes didn’t really seem to matter - in fact, they turned out to be beneficial
The -extra# convention seems incapable of producing a display name that doesn’t also include the Series S## E## - Title identification
I think there must be two Regex rules at play here - one for files implementing the -extra# convention and one for those that just implement -extra.
Giving the extra a name and separating it from the Series S## E## - Title with a dash - while also avoiding the -extra# convention seems to work best.
It takes two systems to troubleshoot this: a computer, to manipulate the filenames on the server, and an iOS or Android device to actually see the extras and their displayed names.
I know, I know, but scrunching those parts together is a bit like nails on a chalkboard to me. Doing so makes the files so much harder to read. Plex clients don’t have a monopoly on playback in my house - I still browse and play from real computers, too, so being able to read the file names is important to me.
Is there a known failure mode when a space is present between the season and episode encoding? My experience with programming regular expressions suggests that, unless there was a specific rule to act or not act based on the presence of a white space before the episode encoding or after the season encoding, the rule isn’t going to care.
Given that the presence of a space in that position on thousands of files hasn’t thrown the agents off in my library yet suggests that what might once have been a problem has either long since been resolved or was a misdiagnosis in the first place.
Official request: Support a single space between the series and episode filename encoding for TV series. haha
Other than the time it would take to quality assess the [already 99.999%-functioning] nuance, add unit tests, etc. versus the opportunity cost of working on more important problems, I can’t imagine any logical reason not to support it - especially if external subtitles are the primary trouble-spot. I can’t be the only one putting spaces in files…
No media managers support a space between episode and season # because it has never been a number standard anywhere. Some might be able to guess what the name is but failing would be the norm. I’ve never ever seen anyone suggest it so, so I can’t imagine there would be any value in them spending any of the limited dev resources trying to support it.
The equivalent is saying that you want them support titles with spaces at every syllable because you don’t like seeing words with multiple syl lab les written as one word. But no one has ever written them that way as they are just one word. Just like s00e00 is one ‘number’ that has only ever been used that way. (and as OttoKerner mentions, I find writing it with lower case letters makes it easier to read).
I don’t think your syllable analogy works. S## and E## are two different pieces of information, just as much as two different words. It’s more like bluebird; sure, you can spell out bluebird but it’s an unnecessary contrivance. “Because everyone else does this way” or “it’s always been done this way” doesn’t sway me, either.
More importantly, though, after dozens of series and probably a thousand or more files, I’ve never seen Plex fail to properly recognize an episode (or its extras) whose season and episode encoding are separated by a space because of the space. It might miss an extra for some other reason but not because of a space. There’s really no incentive to change over to S##E## or even s##e## when S##E## works just fine.
I’m more interested in the nuances as to why -extra# yields different results than -extra. There must be an if-then-else split with two slightly different regexes or parsing algorithms, plus incomplete auto-naming when explicit names aren’t provided (i.e., not all extra types have get simplified automatic names) .
No interest in “swaying” you or convincing you of anything. I’m simply telling you the same thing that the others did: putting a space between them is wrong. You are the only one who is doing that as it has always been against the naming standard, everywhere.
You also seem to misunderstand that because something has worked, that you must be doing it correctly so it failing is their shortcoming. It has worked because of some fuzzy matching that Plex folks do, not because it is supported. Plex will often, but not always, correctly match things that I goof on a name, and I don’t know I goofed unless I use a different media manager which fails to find the title (or mismatches).
Net is, they are not ever going to spend time trying to code to officially support something just because of your personal preference that isn’t in line with naming standards.
I fully understand that I am going off trail and that my preferred nuance to the file naming convention isn’t officially supported. I also don’t expect the developers to jump at making it officially supported. And I’m fine with that. Zero misunderstanding here. There are plenty of other niceties, bugs, inconsistencies, oversights, and whatnot I’d rather the developers spend time on.
So why does -extra behave so differently than -extra#? Beyond the indexing aspect of the latter that’s meant to exist, obviously…
They have different purposes. -extra# exists to deal with multiple episode extras of the same type for the same episode which have no other distinction — e.g. there’s 5 trailers and you have no idea (or interest) of further identifying them, like „US Teaser“, „UK TV Preview“, „Spanish Trailer“, „US DVD Trailer“…
If you know which is which and just want an option to apply an index, you can include that in the extra title itself (e.g. if you have a list of deleted scenes and want to maintain their proper sequence)
Right. What I’m curious about is in how the automatic display name is produced. I’ll use trailers as an example:
Filename
Display Name
Result
Series S01E01 - Episode Title-trailer.ext
Series S01E01 - Episode Title
Bad
Series S01E02 - Episode Title-trailer1.ext
trailer1
Bad
Series S01E02 - Episode Title-trailer2.ext
trailer2
Bad
In the above cases, I didn't provide a name for any of the trailers. (Why would I, right?) But when I do provide names for them:
Filename
Display Name
Result
Series S01E01 - Episode Title - Generic Name-trailer.ext
Generic Name
Good
Series S01E02 - Episode Title - Generic Name-trailer1.ext
Series S01E02 - Episode Title - Generic Name
Bad
Series S01E02 - Episode Title - Generic Name-trailer2.ext
Series S01E02 - Episode Title - Generic Name
Bad
And so the only way I've found to deal with the multiple extras case is:
Filename
Display Name
Result
Series S01E02 - Episode Title - Generic Name 1-trailer.ext
Generic Name 1
Good
Series S01E02 - Episode Title - Generic Name 2-trailer.ext
Generic Name 2
Good
It would seem that the `-extra#` indexing mechanism isn't capable of producing a clean display name.
And before anyone asks, I also tried these variations while also omitting the space between the series and episode encodings, so that isn’t driving any of these behaviors. Rest assured, though: I put the space back when I was done.
It’s no “indexing” mechanism.
File systems don’t allow for different files in the same folder to have the same name… hence Plex allows for the -trailer1, -trailer2 naming (instead of limiting you to 1 trailer / deleted scene / interview / …).
Why the insistence to stick with an indexed suffix, and not simply go with what’s been explained / listed as working naming schema before (and confirmed by yourself several times)? Not sure what you’re trying to achieve.
Interesting. I wouldn’t have gathered that from the way the documentation reads. I would’ve interpreted that top section as implicitly stating:
A folder with extras but not extra in its name will be ignored
A file can have extras or extra in the name and will not be ignored
Also, just in case I accidentally caused any confusion, I have not been actually naming any files with -extra or -extra# in my previous posts. I’ve only been using extra as a substitute for all the various extra types that are supported.
Files that include the word sample in the filename and are less than 300MB in size
Really? This seems like an overreach. Is the limit configurable somewhere? What if someone had an episode with sample in the title? I don’t have this series but this wasn’t hard to find this episode:
Would a reasonably average-to-low-res MP4 of this be automatically ignored?
Are Music libraries and songs affected by this?
I have both indexed and non-indexed extras - lots of them. I assumed that the display naming mechanism was consistent but clearly it is not. So on top of the thankless task of converting ~25 years of ISOs into things Plex will support, I’m finding that these behavioral inconsistencies are generating all sorts of re-work. I am trying to ascertain just exactly what the program can actually do so as to minimize any re-work. The documentation only tells about 75% of the story, so here I am digging.
I personally prefer assigning a title to each episode extra. If the sequence matters, I keep an index in the extra title part of the file name.
e.g.
Show Title (2024) - s01e01 - Episode Title - 1. Cold Open-deleted.ext
Show Title (2024) - s01e01 - Episode Title - 2. Extended Conversation-deleted.ext
Show Title (2024) - s01e01 - Episode Title - 3. Next Extra Title-deleted.ext
…
Edit:
Here‘s an example. Sorry… file browser on my mobile is cutting some parts of the file name (replacing it as „…“)y
