FileBot

I'll send you a PM if you want (likely), but here's the situation.

Go several files of a TV show and the log reports "No files selected for processing" at the end (just before the "Done" and the shrugging shoulders).

When using the GUI, it detects potential matches, but in the logs, it doesn't give any indication of attempted matches.

I'm not seeing an error of being unable to communicate with any services, it just says that there were no files selected. Been using the same .bat file for a few days with no issues, so it's not a case of FileBot being called differently or anything like that.

Could be just a fluke, so I'm wondering, is it expected that sometimes FB just won't match something even though it seems like it should, or is this something you would like to take a closer look at?

The amc script does a lot of things that the GUI doesn't, including excluding files before processing. No files selected for processing means that it doesn't even attempt to match files. All files are excluded for some reason, so there's nothing to process.

https://github.com/filebot/scripts/blob ... roovy#L309

There should be plenty of logs before it aborts that will tell you which files have been excluded and why.

Okay so where do I find those logs? I looked in the AppData/Roaming/FileBot/logs folder and that log file doesn't show anything additional (not even when tried with "--log all" and neither does the stdout (which I redirect to my own log files).

What's the command you're executing?


What does the console output say when you execute that command?


Since you're seeing the No files selected for processing log message, I'm assuming you are seeing all other log messages in the same console output.


e.g.

In one file for a different show, I see "Skip short video" for some featurettes. However, in the one this topic is about, nothing about files being skipped.

For one, I see the Input: list and such. In the issue one, no such list. Goes right from the formats to "No files selected for processing."

Are you using an exclude list? Are the files you're trying to process on the exclude list already?

Not using one.

Well, let's start by reproducing the issue.

1.
What's the command you're executing?

2.
What does the console output say when you execute that command?

3.
Run filebot -script fn:sysinfo and post the output.

Sent the info in a PM.

Yep. Everything looks good on first sight. My educated guess is that you're --def ut_dir is empty, or appears empty for some reason.

You could add a few sanity checks, e.g. call dir /ut/dir and filebot -mediainfo -r /ut/dir before calling the amc script just to confirm that file listing works for that folder.

It does that for the actual folder name as well.

If you look at the PM again, the ut_dir is defined with an actual value.

Oddly enough, if I do a "dir \ut\dir" to get a listing of files, it says "File Not Found," but if I CD to it first and then do a "dir" by itself, it lists files.

Actually found the issue, and will need to report it as a bug to qbittorrent. It's stripping extra spaces. There is an extra space before the "(" in the filename, but the execution filters that extra space out (confirmed by looking at the "Execution Log").

Thanks dude.

As per your example, a real call would of course use the actual value: If that argument doesn't exist, you'll get an error, and FileBot will do nothing.

The amc script is lenient with bad input, and if you pass in a folder that contains no files (because it doesn't exist) it will not complain and simply process nothing. Though additional sanity check with logging could be added.

rednoah wrote: ↑28 Aug 2019, 21:37 If that argument doesn't exist, you'll get an error, and FileBot will do nothing.

I was writing it as I was trying things, so I had tried that before discovering that extra spaces were being stripped.

rednoah wrote: ↑28 Aug 2019, 21:37 The amc script is lenient with bad input, and if you pass in a folder that contains no files (because it doesn't exist) it will not complain and simply process nothing. Though additional sanity check with logging could be added.

Saying that a folder doesn't exist (for example) would be a great for troubleshooting. Then if someone encounters that message, they can be told to closely compare the expected folder name with the actual folder name. Still need to report this as an issue, haven't had a chance yet, but then again, the bug isn't your concern since it's with a different product. Also have another thing to include in the bug report, as I believe it strips quote marks too.

No worries. I've added an extra sanity check:
https://github.com/filebot/scripts/blob ... roovy#L240

I was starting to submit a bug report but decided to double check myself and glad I did.

Part of the problem is that the 64 bit version of qBit (qBittorrent) hides cmd windows that are forked, with no way (that I know of) to force them to be seen. Not bad if you just straight out call a script and never want to see the window. However if you're like me, you want the window available, but not intrusive. So I have this: to call the script.

The problem that I started noticing was that my script file wasn't being called with quote marks. Not really an issue since the path has no spaces in it, but I prefer reliability by structure rather than circumstance. Also noticed that the parameters weren't being passed within quote marks. Turns out 'cmd' requires double quote marks to capture multiple parameters. So now it's a game of Private Detective... Study the clues to find out what works and what doesn't, since following the instructions sometimes works but sometimes doesn't. ie, that's why I didn't include the full code above, as the rest of it is still being sorted out. It's driving me nuts, to be honest.

Okay so all that said, turns out that somewhere in the process, the double space got removed after qBit but before my script. I took a closer look at the execution log (copied the one line) and it had the double space still there, though it doesn't properly show in the execution log.

I might pop a suggestion on there to have it be optional to have the cmd window visible and if so, minimized (hidden) or not. "Hide, Show, Minimize." Would solve many problems. It's a headache.

Phew!

Anyways, that's a great idea and I thank you for the addition of a sanity check. Oh and a major kudos for having the tv/movie/audio formats stored in the registry. That move saved me a crap ton of time from having to reconstruct my formats after the format files got ransomed. Only thing I'm having to rebuild is the script, and aside from the issue of parameters passing correctly, it's done.

1.
cmd ... many brave men have fallen facing the maelstrom of insanity that is.

2.
Always keep backups:
viewtopic.php?f=3&t=4205