FileBot

1.
Yes, you can do that in your format. It looks like you just need to keep the -forced part from the original filename.


2.
I'm fairly sure that the clean logic doesn't care about ignored files, as in, they'll be deleted like any other clutter files.

1.
Plausible, but no. {subt} requires {lang} and {lang} doesn't work in this case, so {subt} doesn't work either.

You can match it manually: And you'll probably want to resort to that only if {subt} is undefined:
2.
That depends. You can run the cleaner script on a few example files and see how it works:
viewtopic.php?f=4&t=5#p1341

There are many conditions why it might or might not delete certain files. Most likely, it won't delete any files, if there's a video file in the same folder, which makes the folder untouchable as far as the cleaner script is concerned.

1.
You will find useful bits and pieces here and there:
viewtopic.php?f=5&t=1895

A full reference would include all of Java and Groovy and would be far too large and technical to be useful. Best to learn from the examples here in the forums, or ask questions if you need help with something.


2.
No, the --def options are exclusive to the amc script. Although the amc script does call the cleaner script internally, it does so with default options that can't be modified. Best to call the cleaner script in a separate filebot call if you need customized behaviour.

1.
You can check if the file is a subtitle, and then yield different values accordingly: NOTE: String.match() DOES NOT work the way you think. You can't use it as a boolean expression, since it'll either return a match or throw an exception, but never return null.

Best to prototype with the Format Editor GUI so you get instant feedback.


2.
Conceptually, these two expressions are completely different, although I guess they might give you the same value.


This is 1 groovy expression, that contains 1 function call, that gets passed in 5 closures as arguments: So you can do things like this:
What is the difference between def values = allOf{ac}{channels}{vf}{source}{vc} and def values = [ac, channels, vf, source, vc] you may ask. And the answer is again the previously linked unwind-on-undefined behaviour, because if we access a undefined variable, our expression will unwind, unless we catch that exception, and allOf(Closure...) and any(Closure...) do just that for each closure that is passed in.


This is 5 groovy expressions, each of which does nothing but reference a variable:
NOTE: Semantically, the outermost {...} are completely different from any other {...} within the outermost {...} since the outermost {...} merely delimit Groovy code, which itself uses {...} for code blocks, closures, etc.

I wouldn't worry about messy code as long as it works.

You can refactor next time you need to make changes.

Check the file name: Check the full file path: