Emby.Naming lets implement configuration.

[Warsen 2]

Apologies to the people who worked on this library; I think it's incomplete and it's discouraging people who would use Emby if only it would or could correctly parse their video files.

 

I saw a thread in the Emby forums about the Emby.Naming project over 6 months ago, but for the life of me I can't find it anymore, not through Google or by using the Search feature here. If I could find it, I would try to have this conversation on that thread instead. If anyone knows the location of that thread, please tell me: it was started by the person who was primarily working on it, and they were asking for people to help work on it.

 

The problem I am having is that Emby recognizes a Season 1280 or Season 1920 due to the fact that the file name contains a specified resolution:

E:\Anime\Air (2005)\Air - NCOP A (1280x720 Hi10P BD FLAC) [43076542].mkv

There's no episode number because this is an extra. You may already be doing this, but I'll repeat that if your parser does not find an episode number at all, then it needs to be considered an extra to be put into the "Extra" season. Unfortunately for me though, this ended up being put into Season 1280. I think the solution would be to ignore all file name contents within parentheses and brackets when capturing anything. Unless I am mistaken. I don't believe you people have any examples of file naming schemes where someone put episode and season numbers inside () or []. At least there aren't any such examples in Emby.Naming's EpisodeNumberTests.cs.

 

Furthermore, I have a different file structure that looks like this:

E:\Anime\Hoshizora e Kakaru Hashi (2011)\Extras\Hoshizora e Kakaru Hashi - Onsale [6BED17A7].mkv
E:\Anime\Hoshizora e Kakaru Hashi (2011)\Hoshizora e Kakaru Hashi - 01 If It Was a Bear, It Would End Here [3EB99134].mkv

There is a sub-directory in my directory which is supposed to contain extras, but to Emby, that sub-directory is being considered the path of the season "Extras", and everything that should have been Seaason 1 has also been put into Extras. Why would there ever be two episodes of same season in two separate directories? And if you can give me a legitimate reason for that, then I'd also like to know when would there ever be that situation but with one directory being a level up or down in relation to the other? I think they could only ever reasonably be the same number of directories deep. I don't think this is going to get resolved in changing regular expressions (patterns don't match with knowledge of earlier pattern matches). The code outside the regular expression is wrong for trying to make files in separate directories part of the same season, probably for lack of them specifying their own season in the file name. I'll look into it, but maybe someone here already knows what's going on with it.

 

I would like to be able to adjust the regular expressions and test them out myself, but they have been hard-coded into Emby.Naming's TV\EpisodePathParser.cs in this variable at the bottom named "_multipleEpisodeExpressions". These values should instead be read at run-time from a configuration file. Preferably something you can access through Dashboard. It doesn't sound to me like anyone is working on doing this. I'd like to help, but I haven't the slightest clue about making a runtime library pull this information from a file, I would never even do that because what if other parts of Emby are already utilizing a library to serialize/de-serialize configuration and I don't know about the existence of that. Same thign with Dashboard. I don't think you want some random guy like me to add something potentially-broken to the most public facing part of the project. We need one of your lead/senior developers to do this, right?

[aspdend 174]

Is this the thread you were looking for?

 

http://emby.media/community/index.php?/topic/17271-episode-metadata-detection-for-tv-series/?hl=+emby%20+naming%20+project

[ebr 14918]

Sorry, but this

1280x720

exactly matches a common convention for season and episode numbers:  2x20.

 

We have to have some sort of rules in order to provide all of the functionality and features that we do.

[Warsen 2]

Is this the thread you were looking for?

 

http://emby.media/community/index.php?/topic/17271-episode-metadata-detection-for-tv-series/?hl=+emby%20+naming%20+project

 

It isn't the thread I was looking for, but the thread you just linked is perfect anyways because it describes a situation and a resolving process similar to what I need. Thank you!

 

I did some deep digging in my web browser's history and found what I had seen: http://emby.media/community/index.php?/topic/13206-contribute-to-the-new-file-naming-project/

I'll still want to find out what Luke's plan for the project is. It sounds to me like his intention all along was to have the patterns read from a configuration.

 

 

Sorry, but this

1280x720

exactly matches a common convention for season and episode numbers:  2x20.

 

We have to have some sort of rules in order to provide all of the functionality and features that we do.

 

Understood, but I think there is a good case for either not matching the numbers because they are contained in a pair of brackets or round brackets, or because they contain triple or quadruple digits. The longest running television series is 69 seasons for Meet the Press (Source: https://en.wikipedia.org/wiki/List_of_longest-running_United_States_television_series ), I don't believe NBC news is even going to exist in the next 30 years, and the code we write today will most likely be revised again within 30 years. A 2 digit season number cut-off sounds like a good idea.

Edited June 1, 2016 by OmegaPhlare

[Happy2Play 8293]

Unfortunately a 2 digit season won't work since TVDB started using Year for some series seasons.  Here Looney Tunes is one example.

[Warsen 2]

Good example. I guess we'd have to use a different rule for finding out whether _,_,_,_x_,_,_,_ is intentionally the season and episode number, or if it's just specified resolution for the user to recognize which quality of video they're looking at.

 

Maybe we're lucky that televised video content did not exist before 1928, so we could reasonably discard season matches in the range of 200 through 1920. Or if we want to be even safer, discard the season and episode match when season is above 200 AND episode is above 365. As no show will ever run for 200 years and have more than 1 episode per Earth day. That sounds like it would be a very difficult regex to make though, so I think discarding seasons 200-1920 should be a sufficient rule. Even if we could make a super extreme edge case where the above would be invalid. Is it worth it to make that theoretical file name work in the future instead of the real actual file name I have in-front of me right now?

[Luke 37090]

for tv series, we can go ahead and treat an extras folder the same as specials or season 0. so that's one change that can be made out of this.

[Warsen 2]

I have a new but related proposal, which I believe can be the groundwork for ensuring that any pattern matching mistakes will not be happening and you would not have to be apprehensive about modifying regular expressions and breaking current patterns that the end users are using right now. But it's going to need Emby to break off from using the default regex patterns inherited from Kodi or at least put them on a lower priority (IE further down the list) than the new regular expressions.

 

As I was examining the code, I saw that the hard-coded patterns I was looking at are not the only ones. They're simply modified copies of the hard-coded expressions given in the default constructor of NamingOptions, and for whatever reason they exist there instead of the constructor of ExtendedNamingOptions. They exist because the ability to parse multi-episode file was probably added late. If you were to modify one, you have to modify the other, so modifying them at all at this stage is just a bad idea. And if you've seen the size of those regular expressions, you might not even want to touch them anyways.

 

Maybe we could generate a series of regular expressions from reusable components at run-time the same way we format a date and time. Like if I specified "(TITLE) (SE)x(EP)" the library will generate the regular expression it would need to identify something like "Cops 19x18.mkv". "(TITLE) (DATE)" to capture a show with a daily episode like "The Daily Show 01-13-15.mp4". We'd probably do derivative formats like (SEEP) in addition to (SE) and (EP) so that we could code that one to avoid hitting Season 1280 episode 720. And when all of that fails, then we can try end-user-defined regular expressions, because at that point the end-user has a special case he needs for his library.

 

As it is right now, Emby.Naming fails 3 tests involved with matching episodes where the episode number is done with a roman numeral. I don't think anyone is going to fix that if they have to write a roman numeral catcher for every existing regex looking for an episode number. What are your thoughts?

[Luke 37090]

Yea so you're talking about a regex builder based on some user configuration. There's nothing wrong with the idea it's just hard to prioritize that kind of work very highly. For us it would be easier to just dump the options object to a file that the user could optionally choose to modify.

[chef 3746]

Yea so you're talking about a regex builder based on some user configuration. There's nothing wrong with the idea it's just hard to prioritize that kind of work very highly. For us it would be easier to just dump the options object to a file that the user could optionally choose to modify.

Please keep in mind that not everyone completely understands regex, and auto-organize works pretty well for a lot of people (like myself).

 

If there is a happy medium, with advanced features and a KISS (Keepin It Simple Stupid) feature for the rest of us, would be amazing (in the future... If something like that is added to the core)

Edited June 3, 2016 by chef

[Luke 37090]

Yea that's basically why this might have to be limited to manually changing a config file and not part of the UI.