vlcj 3.0.0 fails to initialize vlc #226
Comments
|
What happens if you remove the NativeDiscovery and add this instead? ? I can't think of anything I changed in this area. I notice you are apparently not using an official build of vlcj because of this in the log... ? What happens if you use an official build? |
|
Log after applying the change you suggested: The .jars and test-sources were taken/build straight from http://vlcj.googlecode.com/files/vlcj-3.0.0-dist.tar.gz Result when I use vlcj-3.0.0.jar from http://vlcj.googlecode.com/files/vlcj-3.0.0-dist.tar.gz instead of the one build from the sources: Interesting. How does the version info get lost when compiling from source? |
|
What I can see is that the native library is being found correctly but the first call to get a new libvlc instance is what is failing. So I can only assume that something is wrong with the factory arguments that are used to make that call. Which is pretty incredulous if you say it works unchanged with the previous version of vlcj. There may be some more information available via the native log (usually you just need to pass "-vvv" when you create the factory to get that log). It's working just fine for me, and I'm pretty sure I changed nothing in that area, so I don't know what's wrong I'm afraid. As to why the version info gets lost when compiling from source, well if you use Maven it does not get lost - the version information comes from a dynamically tokenised properties file which is populated by Maven using the version from the POM. If you don't use Maven, this tokenisation won't happen. |
|
Ran the sample file from 3.0.0 (with the changes discussed above) against vlcj 2.4.2 and jna-3.5.2 - works fine. Using Netbeans to build from source... |
|
Nothing has been changed in terms of parameters in the example BasicEmbeddedMediaPlayerComponentTest.java. As far as I can see, the EmbeddedMediaPlayerComponent constructor used in BasicEmbeddedMediaPlayerComponentTest does not even allow to specifiy extra parameters? |
|
Maybe something going wrong with the change from JNA 3.5.2 to JNA 4.0.0, maybe in relation to String handling. I really don't know right now. I'm pretty sure I changed nothing in vlcj related to this. |
|
There is difference in the vlc parameters in EmbeddedMediaPlayerComponent from 2.4.1 vs. 3.0.0: 2.4.1: 3.0.0: |
|
What happens if you run: |
|
That hint on jna did it: vlcj-3.0.0 + jna-3.5.2 works! |
|
I would be interested to know if you add those "missing" factory arguments one-at-a-time with JNA 4.0.0 if it starts working or not. Those factory arguments were removed because they were apparently the defaults. Leaving that aside, the fact that it fails with JNA 4.0.0 is quite worrying and will likely be a PITA to track down. |
|
Both tests work with vlcj-3.0.0 and jna-3.5.2, but not with jna-4.0.0. |
|
So as a workaround, should I continue to use jna-3.5.2 with vlcj-3.0.0? |
|
Well if it works, I suppose. I don't know if something else will break or not. If you don't mind one more test... uk.co.caprica.vlcj.test.bare.BareBonesTest For the record, JNA 4.0.0 is working just fine for me, but I don't use Win7. |
|
uk.co.caprica.vlcj.test.bare.BareBonesTest fails with both jna-3.5.2 and jna-4.0.0. VLC was re-installed minutes before. Using jna-3.5.2: Using jna-4.0.0: |
|
That 'bare bones' test is failing because "instance" is null, i.e. the same problem that you originally described. However this time we also see a "no plugins found" error in the native log... usually the fix for that is to specify -DVLC_PLUGIN_PATH=/directory-that-contains/vlc/plugins. That should not be necessary because libvlc is supposed to be able to find its plugins automatically, e.g. by looking in the [directory-that-contains-libvlc.dll]/vlc/plugins, but nevertheless sometimes it is necessary (usually on Windows but rarely on Linux). |
|
By the way, the native log is being suppressed in the other tests because of the use of "--quiet" in the factory args. |
This workaround would be rather impractical when vlcj is distributed with an application - anything I can do to help to debug vlcj not finding the plugin directory? Removed '-quiet' from the parameters: jna-3.5.2 (works): jna-4.0.0 (not): |
|
This is the critical piece of information: [051dea5c] main libvlc error: No plugins found! Check your VLC installation. There is no reasonable explanation that I can see why this would be different with vlcj 3.0.0, nor with JNA 4.0.0. I thought it might be related to the plugins cache, but you said adding that switch back in still failed. In terms of how practical the system property solution is, well I suppose NativeDiscovery could be extended to set that system property programmatically once it found the correct plugins directory. I still think there's something else amiss here. |
|
Also confusing the picture is that when you quote this in your log: Where is the rest of the message and the stack trace? There should be a long message describing precisely the plugin-path issue and what can be done to resolve it. |
|
Uninstalled VLC. Installed VLC 2.1.2 fresh, selecting 'Delete Settings and Cache'. Added NativeLibrary.addSearchPath(RuntimeUtil.getLibVlcLibraryName(), "c:/program files (x86)/videolan/vlc"); to BareBonesTest.java. Fails both with vlcj-3.0.0 and jna-3.5.2 or 4.0.0: Works fine with vlcj2.4.1, even without setting VLC_PLUGIN_PATH: |
|
Full stacktrace for EmbeddedMediaPlayerComponent.java, vlcj-3.0.0.jar (without -quiet) and jna-4.0.0: |
|
Cloned the github repo and build through maven. Even after setting NATIVE_LIBRARY_SEARCH_PATH path in VlcjTest.java, the test fails: |
|
The particular fix here is to set the VLC_PLUGIN_PATH environment variable, not Java system property. Usually this would be done in a shell-script I suppose. |
|
Anyway, I too can conclusively confirm that using JNA 4.0.0 rather than 3.5.2 is what is causing the problem here. I have no idea why that might be the case, but it's 100% repeatable if you swap the different versions of the JNA jar files in and out. |
Difficult from inside an IDE... You suggested in an earlier comment:
This is the same as using System.setProperty("VLC_PLUGIN_PATH", "/directory-that-contains/vlc/plugins"); inside the java code... I just checked out tag 2.4.1 and it build ok after setting NATIVE_LIBRARY_SEARCH_PATH, but I guess this is not surprise after your bug report against jna? |
|
Are you sure it's jna-4.0.0? BareBonesTest.java failed above with vlcj-3.0.0 and both jna-3.5.2 or 4.0.0. It works with vlcj-2.4.1 and both jna-3.5.2 and 4.0.0, though!?! |
|
To address a few of your comments... There is too much going on in this issue that might be the same thing or might not... I have a 100% repeatable before and after test case where the only thing I change is to go from JNA 3.5.2 to JNA 4.0.0 and back again. That's also what you observed earlier. So it looks to me like there is some problem that may be related to JNA somehow. That's not an unreasonable conclusion based on what I've observed. Yes, VLC_PLUGIN_PATH needs to be set as an environment variable, not a system property. I was wrong in my earlier comment. But then again I was in a state of confusion about the whole thing because it makes not much sense to me... If it is really true like you say that vlcj 2.4.1 works with JNA 4.0.0, then as far as I can see it can only be related to the use of the plugin-cache switch on the factory, and I assumed you checked that already based on the earlier comments in this ticket. Finally, you say it's "difficult" to set the environment property inside an IDE, that's not true at least if you use Eclipse - it's very easy to set. Presumably NetBeans has equivalent functionality? |
Unfortunately not.
When playing around with this class, I got confusing results from combinations of vlcj and jna working or not. So i started from scratch, pulled all jars from the distribution zips before the test and did a re-install of VLC 2.1.2 with 'Clear Settings and Cache' in between runs. Turned out the order of vlcj and jna in the classpath matters as well! Not sure whether this helps or not, but there are combination where jna-3.5.2 fails and jna-4.0.0.jar works, only vlcj 3.0.0 and jna-4.0.0 together don't work, no matter the order. Please let me know if I can be of any help with more information. |
|
If you don't mind... in that test code please remove the native discoverer and instead add some hard-coded path like this: This should totally eliminate the various versions of vlcj as contributing to this problem. |
ghost
assigned
|
Unchanged: |
|
So how can a different version of vlcj make a difference... there is no version-specific code here... That makes no sense to me at all. |
|
Glad it doesn't make sense to you either. That's the code I have - plus 3 printlns. Maybe a class from jna is duplicated in vlcj with a different implementaion? Just guessing... Sorry, can't solve the mystery, only report observations. |
|
Or is it rather the classpath set in the manifest in vlcj-2.4.1.jar pulling in the correct jna-3.5.2.jar - which is still in the same folder - when it is first on the classpath and jna-4.0.0.jar is ignored as all dependencies are resolved? And vice versa for vlcj-3.0.0.jar. Which would basically support your hypothesis of jna-4.0.0.jar being the culprit. Will check by removing the .jar not mentioned on the classpath... |
|
Yep. The version specific code is the classpath in the manifest. vlcj-2.4.1.jar;jna-4.0.0.jar: fails when jna-3.5.2.jar is not in the same directory as vlcj-2.4.1.jar vlcj-3.0.0.jar;jna-3.5.2.jar: fails when jna-4.0.0.jar is in the same directory as vlcj-3.0.0.jar Mistery solved. jna-4.0.0.jar it is. |
|
I am thinking about reverting back to JNA 3.5.2 for the official build. |
|
By the way, thanks for all the testing you did on this. |
|
Made vlcj release 3.0.1 built against JNA 3.5.2. I am unsure how to proceed with JNA 4.0.0, as getting a Win32 build of vlc with more debug statements in it is rather difficult. |
|
the same goes here, with JNA 4, i got the same issue. with 3.5.2 it is working fine. i believe the documentation should be update with this since it is saying JNA 4 I'm using windows 7 64bit. Java8 32 bit. |
|
JNA has still not made a new release, it has been almost one year since the last JNA release. Which documentation are you reading that still says JNA 4? |
|
Tracked under #258. |
|
this page: "Version 3.0.0+ of vlcj requires version 4.0.0+ of JNA." |
|
Thanks, it is easy to forget to update that page on a different branch when changing the README in the master branch. |
|
I'm still getting a plugin error after you guys did the upgrade to JNA 4.1.0. This is the init code (from the YouTubePlayer.java), slightly modified to point to my vlc dll files: This is my stack trace:
|
|
this is solved by JNA 4.2.0 |
|
For everyone who experiencing same issue on versions 3.0.0, 3.10.0 or 3.10.1:
<dependency>
<groupId>uk.co.caprica</groupId>
<artifactId>vlcj</artifactId>
<version>3.10.1</version>
<exclusions>
<exclusion>
<groupId>net.java.dev.jna</groupId>
<artifactId>jna</artifactId>
</exclusion>
<exclusion>
<groupId>net.java.dev.jna</groupId>
<artifactId>jna-platform</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>net.java.dev.jna</groupId>
<artifactId>jna</artifactId>
<version>5.0.0</version>
</dependency>
<dependency>
<groupId>net.java.dev.jna</groupId>
<artifactId>jna-platform</artifactId>
<version>5.0.0</version>
</dependency>Tested on Windows 10 x64 with VLC 3.0.4 (x64) and Linux Mint 19 x64 with VLC 3.0.3. |
|
Interesting that JNA 5.x supposedly mitigates this, but what about #639? |
I have no such problem on JNA 5.0.0, but I use following construction on initialize: if (isWindows) {
if (is64bit && isJVM64bit) {
NativeLibrary.addSearchPath(
RuntimeUtil.getLibVlcLibraryName(), "C:/Program Files/VideoLAN/VLC/");
} else {
NativeLibrary.addSearchPath(
RuntimeUtil.getLibVlcLibraryName(), "C:/Program Files (x86)/VideoLAN/VLC/");
}
}
Native.loadLibrary(RuntimeUtil.getLibVlcLibraryName(), LibVlc.class);According to JNA docs, loadLibrary method is now deprecated in JNA 5.0.0, but it's possible to use JNA 4.5.2 instead of 5.0.0 without "fails to initialize vlc" error. I just want to say that the latest release version of vlcj (3.10.1) contains JNA 4.1.0. In my case, it's OK on Mint 19, but leads to "fails to initialize vlc" error on Windows 10 x64. |
Plain BasicEmbeddedMediaPlayerComponentTest.java with additional NativeDiscovery().discover() at the start.
VLC 2.1.2 installed and found by NativeDiscovery().discover()
Same sample from 2.4.1 works fine.
Output:
The text was updated successfully, but these errors were encountered: