FileBot

I had installed filebot and it worked fine. Then two thing happened. I scheduled the command below and the latest DSM update came in: DSM 5.1-5021 Update 2

I suspect the latter messed something up. But it seems to have done so in the CLI as well. When I run: filebot -script fn:artwork.tmdb /volume1/video -r, I get the following back:

Dec 31, 2014 3:25:39 AM net.filebot.media.MediaDetection readMetaInfo
WARNING: Unable to read xattr: null
NullPointerException: java.lang.NullPointerException
java.lang.NullPointerException
at net.filebot.media.MediaDetection.detectMovie(MediaDetection.java:581)
at net.filebot.media.MediaDetection$detectMovie.call(Unknown Source)
at Script1$_run_closure1.doCall(Script1.groovy:31)
at net.filebot.cli.ScriptShellMethods.eachMediaFolder(ScriptShellMethods.java:187)
at Script1.run(Script1.groovy:13)
at net.filebot.cli.ScriptShell.evaluate(ScriptShell.java:61)
at net.filebot.cli.ScriptShell.runScript(ScriptShell.java:82)
at net.filebot.cli.ArgumentProcessor.process(ArgumentProcessor.java:112)
at net.filebot.Main.main(Main.java:170)
Failure (°_°)

I understand I can ignore the xattr issue. That is fine, but funny, as it did not give me this error before.

I cleared the cache, I cleared the preferences. I uninstalled and re-installed JAVA. I uninstalled and re-installed FileBot from FileBot's repository. And still this error persists. I suspect JAVA is the issue, because the path do not *seem* to be correct:
export CLASSPATH='.:/var/packages/JavaManager/target/Java/jre/lib'
export JAVA_HOME='/var/packages/JavaManager/target/Java/jre'

These directories do not seem to exist. I pointed JAVA_HOME to /usr/bin - but am not sure where to point CLASSPATH to. I did clean the CLASSPATH for the '.:' in front of the path, but to no avail. I did NOT do any reboots. BTW: java -version does execute and returns:
Java(TM) SE Embedded Runtime Environment (build 1.8.0-b132, headless)
Java HotSpot(TM) Embedded Client VM (build 25.0-b70, mixed mode)

I also noted that ln -s /volume1/@appstore/java/bin/java /usr/syno/bin/java, did not work, due to the Permission being denied. The syno directory, in fact, does not contain a java entry. So this might be what's causing it. Don't know how to fix it, though.

Am at wits' end, saw it working this morning, and now it collapses on me.

[Edited: added the remark on ln -s]
[Edited: making clear my problem is in the CLI]

If you can start filebot (as the log indicates) then it's definitely not related to any system / java / etc software configuration issue.

It's most likely a software issue, an odd corner case that's not handle yet. There's probably once specific file or folder that is odd and that crashes everything.

If you can narrow down the issue and figure out exactly for which files/folders it doesn't work, then I can fix it.


EDIT:

try -script dev:artwork.tmdb to see if the latest changes fix anything

OKAY! some success here. I ran find /volume1/video/movie/ -maxdepth 1 -type d -exec echo {} \; -exec filebot -script fn:artwork.tmdb {} -r \;

My idea being that it would echo the actual directory being worked on and tell me what directory it started on, before failing. The first directory was a hit. It was '/volume1/video/movie' itself.

So now I am guessing that one of the files in that directory is causing the issue. This is the file-list: (I filtered out all the directories, which my trusty NAS is now processing merrily )
Mede8er.db
imdb.url
movie.nfo
movie.sfv
tmdb.url

I think the problem was that the files that were not *.db, were remnants of a movie that was in the root of my videos folder.

Think a good idea would be to have some sort of verbose option, to quicker be able to track which directory is failing [feature request?]

Anyways, it seems to work right now.

The issue was caused by FileBot detecting the folder as "media folder" on the one hand due to some of these files, but then failing when there actually wasn't any video files. That should be fixed now.