I'm trying to optimize my post-processing script and add some functionality, however I really don't want to test it on real files.
Is there a suggested set of files (movie / tvshow season) which is known to work well and could be used for this purpose?
Also, if I understand correctly how FileBot works, the name alone could be enough with a file created like so:
You can test with 0 byte files if you want. Just need to set --def minFileSize=0 accordingly. As long as you use --action test why not to test it on your real files?
Mainly because it's not for the testing of filebot itself but of the exec bits, before and after.
With --action test files aren't created and some post-processing action fail (as expected).
I mostly get entire seasons of TV shows, but exec runs for every file, since I'm running on a low-powered system I am trying to run some tasks only once for the entire season.
I only work in black and sometimes very, very dark grey. (Batman)
If you're testing --def exec calls then you probably want to test with real files. I'd just use --action hardlink. That way you'll get a real copy instantly, and you can delete those again before each test run. Your original files will remain untouched (as long as you don't modify the physical file content).
So is --action hardlink the only way to get something close to --dry-run with Runbot? I can appreciate this approach as it at least doesn't touch the source files, but it still creates stuff which might pollute existing libraries if you make a mistake and write files to locations with existing media and therefore make a big mess.
Perhaps you could add add the switch --test-clean or something that would delete create hardlink files but then immediately delete them and output a list of all of the files which would have been created? I realize that for certain operations are hard to dry run, like stitching together segmented files, but even if you printed an output describing the operation that would help. It's not just about testing being non-destructive but also about time to process so that test cycles are shorter.
--action TEST allows you to just do nothing instead of move/copy operations. However, a custom --def exec call would then also need to implement custom dry-run behaviour, as would helper scripts such as the cleaner script.
Implementing dry-run behaviour would make these scripts significantly more complex, and likely result in dry-run behaviour different from actual behaviour.
Besides, the OP is about testing --def exec and that's already possible, you can even pass the --action parameter along to your --def exec command if you want to do a dry-run, but nobody has ever done that, because it adds unnecessary complexity.
DarfNader wrote: ↑15 Apr 2018, 21:11
So is --action hardlink the only way to get something close to --dry-run with Runbot?
As mentioned by rednoah it really depends on the exec action, this is already outside of FileBot's control.
In my case I just wanted to make HTTP requests with it and using --action TEST with a simple test for the existence of the file avoids errors.
I don't need to include custom dry-run behavior but in this specific case it would boil down to an if/else.
I only work in black and sometimes very, very dark grey. (Batman)
Please read the