Filebot AniDb Naming Pull Request

[evilsephiroth]

Hi.

Recently, I've stumbled upon some files that couldn't be processed correctly from Filebot using AniDB scraper

The structure

/path/Noein/01 XXX.mkv
/path/Noein/02 XXX.mkv
/path/Noein/02 XXX.mkv

The problem lies in the folder name. Noein isn't the correct name for the anime for AniDB(i.e. Noein: Mou Hitori no Kimi e)

MediaDetection considers reliable the name only if its length is greater/equal than the found name in AniDb Index.

i.e. Noein <= Noein: Mou Hitori no Kimi e

If the name was found in the episode name, it wouldn't be a problem because filename detection ensures the correct renaming.

So for this particular use case, I modified matchSeriesByName method on MediaDetection.java.

From this

Code: Select all

if (commonName != null && commonName.length >= it.getLenientKey().length && (bestMatch == null || commonName.length > bestMatch.getLenientKey().length))

to

Code: Select all

if ((commonName != null && (bestMatch == null || commonName.length >= it.getLenientKey().length || (bestMatch != null && commonName.length > bestMatch.getLenientKey().length))))

It's a less strict check but ensures that these glitch won't happen with poorly named anime. Nevertheless, normal detection works as expected.

Here's the gist of the modified code...

https://gist.github.com/anonymous/d6226 ... -java-L498

P.S. Hosting on github filebot source code will help you track issues and pull request more easily

[rednoah]

I'm in awe you figure things out by yourself in that detail. I barely understand how the code works anymore.

In this case I'm pretty sure it works the way it works for good reason. And allowing the first word to OK the entire name (although it works well in this case) is probably very bad in many other cases, leading to way too many options, leading to mismatches (and wasting AniDB resources). I'm afraid this commit might do a bit more harm than good.

In this case the best solution is just adding the Alias/Synonym to AniDB and the waiting a week.

I'll run some tests, but I think the original way is more safe.

PS: You're the first person with a non-obvious pull really, I might consider GitHub once we find a second or third. I just love my revision numbers too much to give up on SVN just yet.

[evilsephiroth]

No problem...

I tested the code with a lot of series with and without precise naming with no problem...

It's only a safe condition in case there's almost nothing that match the CollateKeys...

In fact, if a best match is found, it gets overwritten by

Code: Select all

commonName.length > bestMatch.getLenientKey().length)

preserving the actual workflow. I'll wait for your tests .

About GIT: I do understand your love with SVN. I'm in love too. But github offers safe procedures to do pull request and also forking without screwing your work. For collaborative solution, I think it's an epic win. On Github, I would have considered a fork

P.S. If you need help for bug fixing,feature and so on, count me in