I was able to get BD-J support with the recent April update.
There are some points which makes it difficult to get it running:
kodi is built against armv7-libbluray-osmc which is version 1.0.2
there is no bdj package for that in stretch
i copied the /usr/share/java/libbluray-j2se-1.0.2.jar from my Fedora 29 to /usr/share/java on my vero4k
then I installed openjdk-8-jre-headless
Kodi/libbluray still complains about “can’t load JVM”
the reason is that the package installs
but libbluray needs it in
easy fix: cd /usr/lib/jvm/java-8-openjdk-armhf/jre/lib/arm/; ln -s client server
last but not least a DISPLAY variable is needed. I set one using
systemctl edit mediacenter
- systemctl daemon-reload
- systemctl restart mediacenter
After that at least my test BD with BDJ menu worked.
What does the ‘BDJ’ package include?
I think we just need to build libbluray against Java. The problem will be licensing.
You should try re-building armv7-libbluray-osmc instead as it is the way we plan to get this in to OSMC.
The BDJ package basically includes the JRE file, but stretch uses 0.9.3
$ dpkg -L libbluray-bdj
Why do you think there is a licensing problem? This file/package is included in Fedora and Debian as well.
The BDJ package should depend on JRE
Does it depend on OpenJDK?
If so – we’re good. Oracle is trickier… to say the least.
it depends on
$ apt-cache depends libbluray-bdj
So, yes it depends on openjdk. But the 0.9.3 version also depends on libjvm.so in “server” directory, not “client”. Maybe that’s a wrong packaging on stretch? On Fedora it’s in “server”.
Possibly wrong packaging in stretch.
Good to know openjdk is a suitable target.
Why not patch OSMC’s libbluray to build with OpenJDK?
It may bloat the installation but we can always produce two versions of the lib / try and dyload.
Thank you for this @MASHtm !
Currently I’m testing this with a Dolby Atmos Demo BD. The menus work so far, but if I select a movie I only hear the audio and the screen stays black. And if I’m waiting a short time my vero does not respond at all. AFAIS in the logs A/V sync fails (maybe because it can’t display the video at all) and “top” shows that it ends up in a out of memory state.
If I play the according .m2ts directly it works like a charm.
I didn’t have time to debug this any further yet.
Although I don’t use it, I can see a real benefit for OSMC, good job @MASHtm!
the issue with the client/server search path seems to be fixed in newer versions of libbluray
I was able to rebuild armv7-libbluray-osmc with the .jar file included. I used these two patches:
They also fix the search path for the .jar and jvm.so.
But still no video and critical kodi memory usage
I think you’ll find the menus can’t be HW accelerated which is probably causing the issues you are seeing.
Thanks for the patch.
I’ll need to look in to the effect this has on filesystem size.
It would be ideal if we didn’t need to link against Java.
Meanwhile I was able to build the most recent 1.1.1 release as well. And I think you do not need java installed at all. The libjvm is loaded dynamically and BD-J simply doesn’t work if it is not found. Same for the .jre file. It is still possible to install the libbluray without openjdk IMO. But currently it’s quite useless.
@Acadia: you mean that starting a selection from a BD-J menu which can’t use HW acceleration disables it for the selected movie as well? What I see is a huge memory leak. Even if I’m fast enough to press stop before my vero gets unresponsive the RSS from kodi stays at that point and does not return to the usual <150MB footprint.
Correct, VideoPlayer can’t switch decoding method without being re-opened.
Is the performance even acceptable with hardware acceleration disabled?
libbluray is still used for handling Blu-ray discs without menus; so it’s not useless without BD-J.
Can you post output of ldd on your libbluray so I can see if there’s a dependency on Java?
I meant useless for BD-J and no improvement from the current state
...:/usr/osmc/lib$ ldd libbluray.so.2.1.1
libxml2.so.2 => /usr/lib/arm-linux-gnueabihf/libxml2.so.2 (0xf74d6000)
libfontconfig.so.1 => /usr/lib/arm-linux-gnueabihf/libfontconfig.so.1 (0xf749e000)
libfreetype.so.6 => /usr/lib/arm-linux-gnueabihf/libfreetype.so.6 (0xf7425000)
libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xf7412000)
libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xf73ee000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xf7300000)
libicui18n.so.57 => /usr/lib/arm-linux-gnueabihf/libicui18n.so.57 (0xf7153000)
libicuuc.so.57 => /usr/lib/arm-linux-gnueabihf/libicuuc.so.57 (0xf702a000)
libicudata.so.57 => /usr/lib/arm-linux-gnueabihf/libicudata.so.57 (0xf579d000)
libz.so.1 => /lib/arm-linux-gnueabihf/libz.so.1 (0xf577b000)
liblzma.so.5 => /lib/arm-linux-gnueabihf/liblzma.so.5 (0xf5751000)
libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xf56d7000)
libexpat.so.1 => /lib/arm-linux-gnueabihf/libexpat.so.1 (0xf56af000)
libpng16.so.16 => /usr/lib/arm-linux-gnueabihf/libpng16.so.16 (0xf567f000)
libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0xf5573000)
libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xf554a000)
If of interest I can provide the patches and a .deb for libbluray-1.1.1 as well.
If you can put the patches here that would be great.
There is no explicit dependency on JVM libraries; so this is something we could include in OSMC and make optional.