1.
{vf} is indeed based on the file content on not the file name. Since you didn't post the MediaInfo table for each file, I had to guess the value of
{vf} based on the file path that you did share with us, just to illustrate what is probably happening with some example numbers.
2.
The current conflict action API is unfortunately ill-suited to compare arbitrary files. A conflict script assumes that the second parameter is the target file, and may choose to rename the current
X to
X.backup to resolve the conflict, before confirming X as target file path, or choose to confirm a different target file path, so things may go very badly if the "to" parameter is suddenly unexpectedly one of the input files in some use cases
(i.e. process both versions at once) but not others
(i.e. process one file at a time).
I see no issue with hardlinking files into a temporary staging location
(instant, no extra disk space required) to resolve conflicts locally, and then moving files ot the the remote location, ideally with
rsync.
EDIT:
If you could find and sort files ahead of time, i.e. custom program that collects files, and then groups / sorts them according to your custom quality metric, and then passes them on to the
filebot call then - assuming that FileBot processes files in order of input arguments - do that with
--conflict skip since the first occurance in the process is going to be the better quality one, and the second lower quality one will run into a conflict and get ignored.
We can mostly reuse the code above for that and then
| xargs the lines into a new
filebot call:
Groovy: Select all
#!/usr/bin/env filebot -script
args.files.findAll{ it.video }.toSorted{ from, to ->
def score = { f ->
def x = ['2160p': 30, '1080p': 20, '720p': 10][getMediaInfo(f, '{vf}')] ?: 0
def y = ['HEVC': 2, 'AVC': 1][getMediaInfo(f, '{vcf}')] ?: 0
return x + y
}
return score(to) - score(from)
}.each{ println it }
EDIT 2:
xargs is finicky AF. \n isn't the default separator. macOS xargs doesn't have the -d option. -I enables \n as separator but implicitly disables -n resulting in one filebot command per one file. I'm always surprised how ill-suited xargs can be for the most most typical xargs use cases one can think of, just run a command for every line, how hard can it be...
Maybe better to avoid
xargs, and instead write arguments in order to a text file, and then have
filebot read arguments from that text file in order:
EDIT 3:
FileBot r9859 adds the
--file-order option to re-order the input argument array before processing:
viewtopic.php?t=13796
Here's a snapshot for FileBot r9844 in the meantime:
