The current solution is best even though it doesn't work on exotic devices. FileBot might as well call 7z directly, and that would work on all platforms. Why would FileBot send an extract request to DSM via http requests if it's already running on the same machine? DSM will internally do a 7z syscall. It's only gotten tricky now that there's like a billion almost-the-same but binary incompatible embedded platforms. 7z could be used instead, though it only makes sense for platforms where the native libraries aren't easily available, but parsing output is dirty and the native libs work perfectly well on Windows/Linux/Mac. It's all of 7z native code plus Java API. It's just 7zip and some JNI bindings compiled into one native lib. It's just a matter of adding a few lines filebot.sh so you can check the latest changes in svn and copy & paste from there. From the sysinfo, it is looking for it in a subfolder (linux-x86) - do i need to create that folder in the filebot folder? That way people can update package dependencies easily from the Package Center when it notifies them, and will always have the most up to date version - without having to know to go looking for an update.Īppreciate your help! As always, super prompt.ĮDIT: After looking a little more, even adding the MediaInfo directory to the LD_LIBRARY_PATH, it still doesn't find it. It just seems easier to have package dependencies, rather than additional installations. Apparently the answer is no (thats fine, it was just a question for improving ease of installation). I know lib7-zip-jbinding.so isnt included, my question was if you could use the already installed extraction protocols from FileStation, rather than have to install the 7zip jbinding separately. Isn't that the point of symbolic links - so you can reference files in other locations? Does it matter who is logged in when you echo $PATH?ģ. I'm confused as to why having the actual files in the filebot folder (when it was working) and replacing those with symbolic links makes a difference in the resource PATH. Libmediainfo.so.0 (symbolic link to libmediainfo.so.0.0.0)Ģ. Libmediainfo.so (symbolic link to libmediainfo.so.0.0.0) After installing the mediainfo package, it points to and there are the following files inside : _Guide.pdf, instead of using 7zip? Or is it just not powerful enough? I would think that by using FileStation extraction, and linking directly to MediaInfo's package location, you could make it much easier to install the additional libraries.ġ. On a related, but less important note, is it possible to use the built in FileStation extractor. Uname: Linux RackStation 3.2.40 #5022 SMP Wed Jan 7 14:19: x86_64 GNU/Linux synology_bromolow_rs3412xs JVM: 32-bit Java HotSpot(TM) Embedded Server VMĬPU/MEM: 4 Core / 419 MB Max Memory / 30 MB Used Memory JRE: Java(TM) SE Embedded Runtime Environment 1.8.0_33 (headless) MediaInfo: : Unable to load library 'mediainfo': Native library (linux-x86/libmediainfo.so) not found in resource path ar])Ĭhromaprint-tools: fpcalc version 1.1.0 Attributes: OK Code: Select all RackStation> filebot -script fn:sysinfo
0 Comments
Leave a Reply. |