Page 1 of 1
Download ALL Hash Matched Subtitles?
Posted: 24 Nov 2015, 18:38
by viking
I am often getting poor hash matched subtitles due to the poster not doing a good job.
I then have to manually download the subtitles one-by-one (using GUI) to find one that might work. I usually find a working one this way.
Is there some way that I could download all hash matched subtitles for each episode? Maybe an option in the suball script? In this case, the original subtitle name would be saved.
Re: Download ALL Hash Matched Subtitles?
Posted: 25 Nov 2015, 05:18
by rednoah
It might be possible to make a script for that, but it's not supported out-of-the-box neither in GUI nor CLI.
If you ever manually match subtitles, please re-upload them again with FileBot, so that the correct video/subtitle match there for the next guy.
Re: Download ALL Hash Matched Subtitles?
Posted: 04 Dec 2015, 16:32
by rednoah
I've updated the script to give you much more information and behaviour similar to the CLI calls.
e.g.
Code: Select all
filebot -script dev:osdb.explain /path/to/video [-non-strict] --def fetch=y
This will list all the subtitles, and show you which ones filebot would be choosing. It'll also batch download all of them (using the original subtitle name).
PS: If you want to make AcoustID/MediaInfo/7z working on 64-bit Windows for the portable package, you just need to copy these files:
https://svn.code.sf.net/p/filebot/code/ ... win32-x64/
Re: Download ALL Hash Matched Subtitles?
Posted: 05 Dec 2015, 01:52
by viking
Great!
I tried it on a file: The.Last.Man.On.Earth.S02E08.720p.mHD.DailyFliX.XviD.avi;
Code: Select all
D:\Portable_Progs\FileBot_4.6.1-portable>filebot.cmd -script dev:osdb.explain D:\!Data\junk\The.Last.Man.On.Earth.S02E08.720p.mHD.DailyFliX.XviD.avi [-non-strict] --def fetch=y
File: D:\!Data\junk\The.Last.Man.On.Earth.S02E08.720p.mHD.DailyFliX.XviD.avi
Hash Lookup (hash: 664d476671f68db8, size: 359345282, lang: eng)
Best Hash Match: null
Done ?(?????)?
Strangely, using the GUI, I see a couple of hash matches (black text on white background) but nothing when using the script?.
p.s. I will do some more testing when I am back from a trip
Re: Download ALL Hash Matched Subtitles?
Posted: 05 Dec 2015, 09:18
by rednoah
Try adding -non-strict and see if you then get those subtitles. If a name-search yields subtitles where the name matches exactly then it might be displayed as good match as well.
Re: Download ALL Hash Matched Subtitles?
Posted: 05 Dec 2015, 11:47
by viking
1. I originally had [-non-strict] as a parameter (I had simply copied your original post above). I guess the [] makes it ignored?
2. I used -non-strict and indeed got several subtitles downloaded. However, I am a bit confused now..:
A. The downloaded subtitles were obviously not hash-matched but name matched. However, the names were very different from the media file.
B. The omission of non-strict (in the previous post) eliminated name-match. Why then did the GUI show those subtitles as black text on white background. Doesn't that mean hash-match?
Re: Download ALL Hash Matched Subtitles?
Posted: 05 Dec 2015, 12:20
by rednoah
1.
By [...] I meant that the parameter is optional. So you can either specify -non-strict or not.
2.
If the GUI only shows "Exact Search" then it should all be exact hash/tag matches. If the GUI shows "Fuzzy Search" as well then some of the matches may be name matches. Note that FileBot will not perform any "Fuzzy Search" if "Exact Search" yields enough results.
"Exact Search" results are always white/perfect, but "Fuzzy Search" results can also be white/perfect if FileBot thinks that it's a very good match for some reason. So a name-match may very well be white and on top of the list, if there's no hash-match, and if it looks like it might be a good match.
3.
The "goodness" of a video/subtitle name match is computed from matching SxE numbers, date patterns, substring occurrences, movie/year patterns, etc...
e.g. "Alias.1x01" might be considered a perfect match for "Alias.S01E01"
The current algorithms try to make sure the the best result is the #1 result, so you shouldn't ever have to manually select another result. If there is no correct answer, than this will completely fail of course, and the "next best" result will be as wrong as any other.
I have no idea what might be happening in certain specific cases, and I'd have to just run the code on some example to see what it's doing.