[Bug] Pattern matching worse since 4.7

[Hemloc]

Sorry, but I really don't have enough information here in order to do anything :
1. Setting "-Dnet.filebot.logging.debug=ALL" in filebot.launcher.l4j.ini does nothing.
2. There is no console or console output so I don't understand how this option is supposed to work.
3. Where do I set the --log-file option?

[Hemloc]

Ok, this got stranger and stranger. In trying to figure where the logging option would be set for the GUI, I thought I would rerun the CLI command... and discovered that depending on which directory I run the CLI command in, I get different results :

l:\downloads>filebot -rename "Svartsjon (Swe, Fre, Eng) S01E08.srt"
Rename episodes using [TheTVDB]
Auto-detected query: [Sweet/Vicious, svartsjon]
Processing multiple shows at once requires -non-strict
Failure (°_°)

l:\>filebot -rename "Svartsjon (Swe, Fre, Eng) S01E08.srt"
Rename episodes using [TheTVDB]
Auto-detected query: [svartsjon]
Failed to fetch episode data: [svartsjon]
Failed to match files to episode data
Failure (°_°)

So I found the problem : The directory name "Downloads" causes the search to return different results.

If a file is dragged from a directory or sub-directory of a directory containing "downloads" (e.g. L:\Downloads\Newsleecher\Svartsjon.S01E01.720p.WEB-DL.AAC2.0.H.264_0 (1).mkv) the program returns two results. If you use another directory (e.g. root), it works just fine.

So there you go, either "downloads" or possibly your blacklist names are causing the "Strict" setting in the program to be ignored.

[rednoah]

1.
FileBot (console) (filebot.exe) will launch FileBot with console:
viewtopic.php?f=3&t=1961

Running filebot (without arguments) in CMD will do the same. You can do filebot -log-file /path/to/file if you want to log standard output to a text file as well.


2.
If you continue to narrow down the problem then you might find something interesting. Maybe a misleading NFO or URL file somewhere?

It works in a clean environment:

Code: Select all

$ filebot -rename "Downloads/Newsleecher/Svartsjon.S01E01.720p.WEB-DL.AAC2.0.H.264_0 (1).mkv"
Rename episodes using [TheTVDB]
Auto-detected query: [svartsjon]
Failed to fetch episode data: [svartsjon]
Failed to match files to episode data
Failure (°_°)

3.
Please run these commands and post the output:

Code: Select all

cd l:\downloads

Code: Select all

dir

Code: Select all

filebot -script fn:xattr "Svartsjon (Swe, Fre, Eng) S01E08.srt"

[Hemloc]

No, I have checked, you have to be physically in the directory when running the CLI, it does not show the problem otherwise :

c:\>filebot -rename "Downloads/Newsleecher/Svartsjon.S01E01.720p.WEB-DL.AAC2.0.H.264_0 (1).mkv"
Rename episodes using [TheTVDB]
Auto-detected query: [svartsjon]
Failed to fetch episode data: [svartsjon]
Failed to match files to episode data
Failure (°_°)

Output shows nothing :

l:\downloads>filebot -script fn:xattr "Svartsjon (Swe, Fre, Eng) S01E08.srt"
Done ?(?????)?

[rednoah]

I have no idea. Let's try to narrow down the problem:

1. Delete l:\downloads
2. Create a new file "Svartsjon (Swe, Fre, Eng) S01E08.srt"
3. Try again

[Hemloc]

I wish I could but I have too much in that directory, I would rather rename the directory and create a new one. Also... this only seems to happen under "L:\Downloads". I created a sub-directory "t" here with nothing in it and got this output :

l:\downloads\t>dir

Volume label : General Serial number : B6FE-D044 File System : NTFS
Path : L:\Downloads\t\*.*

. <Dir> 24/01/2017 11:02p .
.. <Dir> 24/01/2017 11:02p ..

0 bytes in 2 file(s) 0 bytes allocated
117,109,800,960 bytes available 3,000,457,228,288 bytes on disk

l:\downloads\t>filebot -rename "Svartsjon (Swe, Fre, Eng) S01E08.srt"
Rename episodes using [TheTVDB]
Auto-detected query: [Sweet/Vicious, svartsjon]
Processing multiple shows at once requires -non-strict
Failure (°_°)

l:\downloads\t>filebot -script fn:xattr "Svartsjon (Swe, Fre, Eng) S01E08.srt"
Done ?(?????)?

Tried the same thing with "C:\Downloads" and could not recreate the result. So something about the "L" drive.

[rednoah]

Is there an *.nfo or *.url file in l:\ or l:\downloads?

[Hemloc]

Sigh... yes, finally found this : L:\Downloads\Sweet.Vicious.S01E07.Heartbreaker.1080p.MTV.WEBRip.AAC2.0.x264-BTW.nfo

And yes, somehow having that file in that directory causes FileBot to match Svartsjon to "Sweet Vicious"... talk about obscure!

[Hemloc]

Removing the file has solved the Svartsjon issue (though who knows in the future if another nfo file causes another strange rename), but this does not seem to have helped my Strict checking, if Strict checking is on, why does FileBot return many results for a series for which there is only one series by that name, e.g.

c:\>filebot -rename Salem.S03E09.1080p.AMZN.WEBRip.DD5.1.x264-TrollHD_0.mkv
Rename episodes using [TheTVDB]
Auto-detected query: [Salem]
Multiple options: Force auto-select requires non-strict matching: [Salem, Alzeersalem 2000, Salem's Lot]
Failure (°_°)

There is a one to one match on "Salem" only?

[rednoah]

Yes, and opportunistic matching will most likely guess correctly in this fairly obvious case.


However, strict means really strict, as in "doesn't work half the time because it's so strict" strict. If the query is "Salem" and there are many search results that contain "Salem" then there are many unfortunate corner cases that might lead to a bad match. FileBot cannot guarantee a good match in this case, thus the file does not get matched.


Consider this use case:

Code: Select all

Auto-detected query: [Doctor Who]
Multiple options: Force auto-select requires non-strict matching: [Doctor Who, Doctor Who (2005)]
...

You'll probably want to use opportunistic matching at all times. Strict matching is not meant to be used for the average kind of use case.

[Hemloc]

Ok,

1. Sorry, but an nfo sitting in a directory above that somehow causes a series to be renamed incorrectly is a bug.

2. Why can't there be a simple method of matching? I mean "Salem" is a unique series name so the match should be exact and not require guesswork. Also, whether I choose Strict or Opportunistic, both return a drop-down list, so no, the program does not do this correctly.

3. I tried renaming Salem in 4.6.1 and lo and behold it works as expected! So I repeat the subject of this topic "Pattern matching worse since 4.7". Will 4.7 ever work as well as 4.6.1? (BTW at least 4.6.1 also had the nfo bug

[rednoah]

1.
I've tested with strict mode and nfo files and files remain unmatched as they should be. Bad matching behaviour appears to occur only in Opportunistic mode, which is expected.


2.
That's Opportunistic matching. It's the default a reason and most users never ever change that. The selection dialog is intentional. But you can reduce user interaction by clicking the auto-repeat toggle so it'll remember "Salem" for next time.

FYI the options in the select dialog are sorted by relevance, so you can just hit ENTER without looking at it, if the filenames look easy enough.


3.
For you specifically, possibly not. For the majority of everyone else, it already does work better than ever.

[Hemloc]

1. No, matching should occur on the files being checked, not some obscure file not even located in the same directory or even with the same series name. Also, recall I was using Strict mode for all my testing. So definitely a bug.

2. Yes, that should help (though like I said, actually it shouldn't be needed since for these sorts of series there is only a 1-1 match). It appears 4.6.1 did this but 4.7+ does not (a simple string length and string compare across all names to check if there is only one series with the same length name is not a hard thing to add).

[rednoah]

1.
Believe it or not, that was a feature that multiple people have specifically asked for: checking *.nfo files that are not selected and not in the same folder.

I did some additional testing with *.nfo files and I can't reproduce any bad matches:

At this point it's a bit of a waste of time for everyone involved. Let's just leave it be. If there's a indeed a bug, then it'll happen again with a completely different set of files. Then we can have a look again.


2.
Experience has shown that a 1-1 match is not good enough to make a decision that cannot be changed later on. You hitting ENTER on a pre-selected item is a minor inconvenience, and you only have to do it once. However, FileBot making a selection and getting it wrong (e.g. Doctor Who) is a major issue because it'll incorrectly match the file every and won't give users an opportunity to change the selection.

Having weighed the pros and cons, the current behaviour is the best compromise and ideal behaviour for the majority of users.

[Hemloc]

Whenever I code, I strongly believe in giving users options. If you cannot decide which way to go, then make it an option and let the user choose which way they want it, makes for more coding, but more happy users. Everyone is different and you can never make everyone happy, but adding options means you can minimise the unhappy users

Unfortunately you don't seem to follow this philosophy (I don't want it looking at directory names, I don't want it checking nfo files, but there are no options to turn these sorts of things off... and I didn't even know the software did this until I had problems) and that is why I had so many issues.

1. So this should be an option which I would switch off To recreate the problem you actually need the physical file (http://nfomation.net/info/1485365895.Sw ... 64-BTW.nfo), just a filename does not work, you need the contents of the file as well, but agreed, I found the problem, its resolved, moving on. You can solve the bug now if you want to

2. And I would have to ask : Why can't it be changed later on? That seems to indicate a flaw in the design We know users can far too easily do the wrong thing, accidentally choose the wrong option, so why is there no simple option to undo an incorrect decision?
Just so you know, that option on the list box to ask again is not in the FAQ, nor the tutorial, and I have never have even looked at the funny icon on the bottom right until you mentioned it, so it may be other users don't even know of this very useful feature

Anyway, it is what it is, the program works, it does what it says on the box, and barring a few issues for people like myself, most people will be very happy with the way it works.

[rednoah]

Yes, and IMHO manual series selection (in case there is room for error) is one of these options where users need to make the choice.


1.
How to make sense of the files is not something an average user needs to be concerned about, as long as it just works. And it does, assuming that files can be matched in the first place. In this case, the core issue is not that the random NFO files, but that a search for "Svartsjon" yields no results. Ignoring NFO files will not help you match "Svartsjon".

EDIT: If the series had more than 5 votes, then the show would have been indexed by FileBot with all international titles, which is especially useful for corner cases (of which there is many) where TheTVDB search fails.


2.
If FileBot makes a choice in the background, then users will not understand that there was a choice in the first place and think that it simply doesn't work. Being given a choice is self-explanatory, but having forcing manual selection via some option somewhere in the occasional case where auto-selection picks the wrong is definitely not exactly create design either. In this case, simplicity wins over arcane black magic.


I'm not opposed to having a billion configuration options, if and only if this is indeed necessary and desirable. See format expressions.