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.
Download ALL Hash Matched Subtitles?
Re: Download ALL Hash Matched Subtitles?
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.
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?
I've updated the script to give you much more information and behaviour similar to the CLI calls.
e.g.
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/
e.g.
Code: Select all
filebot -script dev:osdb.explain /path/to/video [-non-strict] --def fetch=y
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?
Great!
I tried it on a file: The.Last.Man.On.Earth.S02E08.720p.mHD.DailyFliX.XviD.avi;
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
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 ?(?????)?
p.s. I will do some more testing when I am back from a trip
Re: Download ALL Hash Matched Subtitles?
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?
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?
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?
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.
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.