GUI Command-line parameters?

[J. Scott Elblein]

Is there a way to pass a filepath(s) to the GUI so that the result is the same as if I had drag & dropped the file(s) onto it? Something along the lines of:

Code: Select all

filebot.platform.launcher "C:\MyMovies\Somemovie.mkv"

[rednoah]

Yes, but only if you specify a --mode option

Code: Select all

filebot --mode Rename "/path/to/file"

[J. Scott Elblein]

Hmmmm. None of my presets show up then. Would it be possible to add the feature to the regular GUI exe's?

[rednoah]

Which *.exe you call shouldn't make a difference. Also, preferences are stored per user, again, regardless of which launcher you use.

[J. Scott Elblein]

Looks like it'll work OK if only 1 file is passed to the .exe (I tried with both the regular launcher and the platform launcher), but passing more than one file causes all kinds of Java errors.





Here're some error logs:

http://pastebin.com/qsuiJA0e

http://pastebin.com/CmyQYfBP

http://pastebin.com/Y896cYXG

The Way I'm calling it is via Directory Opus, in a menu item, using this command:

Code: Select all

@async "C:\Program Files\FileBot\filebot.platform.launcher.exe" --mode Rename {filepath}

I've also tried directly doing it via a command-line like this:

Code: Select all

S:\Media Server\.Unprocessed\Waynes.World.Duology.1080p>"C:\Program Files\FileBot\filebot.platform.launcher.exe" --
mode Rename "S:\Media Server\.Unprocessed\Waynes.World.Duology.1080p\Waynes.World.2.1080p.HDR.mkv" "S:\Media
Server\.Unprocessed\Waynes.World.Duology.1080p\Waynes.World.1080p.HDR.mkv"

But basically, it seems like it's causing memory errors, as if it's eating up enormous amounts of memory. I have 16GB on this machine, so it should be more than enough.

Any ideas?

[rednoah]

If memory isn't actually an issue, then maybe it's an issue with the *.exe launcher

Code: Select all

# There is insufficient memory for the Java Runtime Environment to continue.

Do not use 32-bit Java, if you are for some reason

Code: Select all

#   Use 64 bit Java on a 64 bit OS

Ignore that. Try increasing it. Use the *.ini configs files to force -Xmx and -Xms

Code: Select all

#   Decrease Java heap size (-Xmx/-Xms)

e.g.

Code: Select all

-Xmx2g
-Xms1g

[J. Scott Elblein]

Hmmm, while diagnosing all of this, I ran into some weirdness, and have a couple questions.

For awhile, I was just downloading the actual latest FileBot.jar file the repo, and overwriting the one I had, but then after a while I started getting an error once I would try to do the actual rename when using the regular launcher, so I switched to the platform launcher for a while, and it worked fine.

But then, while trying to do the above stuff (opening files via command-line) I saw that my Java needed an update anyway (I have both 32 bit & 64 Bit versions installed, since I'm a dev myself, plus, I like to try and use as much 64 bit stuff on my 64 Bit OS as I can), so I updated them both.

THEN (stick with me ), I kept getting errors in FB while looking at sysinfo, mentioning it wasn't able to load 32 Bit .dlls (media info, and 7Zip J Binding) and of course, it wasn't showing me any mediainfo details as it usually does, so I said screw-it, I'm going to completely clean out my portable install of FB, and grab the 64 Bit Installer version. (btw, why no 64 bit portable version?).

Installed, and now looking at the actual files it installed, both of the launchers are still 32 Bit(?), but the above mentioned .dlls are 64 Bit. Another sysinfo shows that it still can't load mediainfo.dll because it's not 32 bit?

Code: Select all

FileBot 4.6.1 (r3315)
JNA Native: 4.0.1
[b]MediaInfo: java.lang.UnsatisfiedLinkError: Unable to load library 'mediainfo': Native library (win32-x86/mediainfo.dll) not found in resource path([file:/D:/Program%20Files/Video/Misc/FileBot/FileBot.jar])[/b]
Apache Commons VFS: [zip, ftps, rar, ftp, tar, tgz, tbz2, sftp]
Chromaprint: fpcalc version 1.1.0 (D:\Program Files\Video\Misc\FileBot\fpcalc.exe)
Extended Attributes: DISABLED
Groovy Engine: 2.4.5
JRE: Java(TM) SE Runtime Environment 1.8.0_66
[b]JVM: 32-bit Java HotSpot(TM) Client VM[/b]
CPU/MEM: 4 Core / 247 MB Max Memory / 29 MB Used Memory
[b]OS: Windows 10 (x86)[/b]
Package: MSI
Data: C:\Users\J.Scott\AppData\Roaming\FileBot

The above sysinfo says a few strange things to me;

• It's still trying to load the 32 Bit mediainfo.dll for some reason?
  It's detecting my OS as x86 when it's actually x64?
  It's using the 32 Bit JVM instead of the 64 Bit JVM?

I have the java path variables for my Windows all point to the 64 Bit JVM. i.e. when I do java -version at the command-line, it shows:



To solve the mediainfo problem, I downloaded the latest MI, renamed the i386.dll and copied it over to the FB folder, but that's kinda hacky, and not making use of 64 Bit as I want it to.

Any ideas on all of this? I know I could probably solve all of this easily by just using 32 Bit everything, but, I'm a 64 Bit guy these days.

[rednoah]

1.
The portable package is neither 32-bit nor is it 64-bit because it's just Java, and it doesn't include the platform-dependent native libraries for exactly that reason. The FileBot.exe portable launcher is configured to prefer running things with a 64-bit JRE if available though.

2.
If sysinfo says x86 then it's running with 32-bit JRE and the process will be in 32-bit compatibility mode, so the OS will make the process think that it's running on an 32-bit machine (i.e. x86).

3.
All the *.exe launchers are configured to run things with the latest 64-bit JRE. The FileBot Installer is also supposed to download & install the 64-bit msi package on 64-bit machines.

You seem to be saying that launch4j exe launchers are not using the right JRE. But that's probably because your registry is messed up. If you call "java" it'll use the %PATH% to find the java executable, but launch4j will check registry settings to find all installed JREs and then pick the right one, which should be the 64-bit one by default.

[J. Scott Elblein]

Ahh I see. Thanks for the registry heads-up, I wasn't aware any part of Java looked in the registry for any path info. I ended up having to go in to this key and manually editing the paths to the x64 installation, as it was set to the x86 installation:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JavaSoft\Java Runtime Environment

It (appears) that since both of my installations (x64 & x86) are the same version, the version keys there were the same as well, so they could only contain the path to 1 of them, afiak.

Sun really needs to make all of this stuff way more thorough and end user friendly, especially when having or wanting to install multiple versions and arch types, lol.

[rednoah]

launch4j is open-source and has nothing to do with Sun/Oracle. I don't know how to JRE lookup works in detail, but it seems to just work for most people.

You might wanna tell them about the issue if it's really not working:
https://sourceforge.net/p/launch4j/bugs/



This node is exclusively for a 32-bit processes running on a 64-bit machines:

Code: Select all

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JavaSoft\Java Runtime Environment

(this should point to the 32-bit JRE)


This node should be the native 64-bit node:

Code: Select all

HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment

(this should point to the 64-bit JRE, and used by launch4j to start FileBot)

[J. Scott Elblein]

launch4j is open-source and has nothing to do with Sun/Oracle. I don't know how to JRE lookup works in detail, but it seems to just work for most people.

I basically mean making JRE's a lot easier on the end user by not making them wrestle with paths all over the place; not having to make them fight with getting things working when having both 32 Bit and 64 Bit versions installed (or having to even install both on a 64 Bit system. Maybe figure out how to just install the 64 Bit runtimes, and then have it work for 32 Bit Java needs as well), cleaning up properly after itself when uninstalling, hassle-free updates, etc.

I've been in development since around 1995, and I still get frustrated when I have to deal with Java all of the time, .

Regarding, the RegKeys, I don't have a

Code: Select all

HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment

Because I installed the JDK awhile back, while reverse engineering some Android stuff, and evidently (unless Sun screwed things up again, lol) it only creates a

Code: Select all

HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Development Kit

Key there, and points to the root of it's folder tree, when you also install the JRE in it's subfolder. I moved the JRE out to a separate folder where I keep all of my JRE's, just because it's easier for me to remember and keep organized. I'm not sure at this point, if I should just change the paths in the JDK keys to point to the 64 Bit JRE now, or if I need to dig up the actual key structure that *should* be there for the JRE, and leave the JDK paths there alone. I'm assuming of course, if I change the JDK paths, whenever I mess around with Java coding again, things will get screwed up. *shaking fist at Sun*

[rednoah]

I'd just use 64-bit Java on 64-bit Windows and be done with it. 32/64 bit Java won't make a difference to pure Java applications, and the ones that do need to load 3rd party native libraries should really have 64 bit ones by now.

[J. Scott Elblein]

I wish I could, I've tried that before . Then you end up running into issues with browser plugins not liking the 64 Bit version, yadda yadda yadda.

I ended up getting it working though. I opened up one of my Hyper-V sandboxes, installed the latest 64 Bit JRE, exported:

Code: Select all

HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment

Then imported it into this machine, and edited the path in it. All good, until the next Java update most likely.

[rednoah]

Not installing the browser plugin is another added benefit of using the 64-bit JDK