[libbluray-devel] JRE for Android part 3

[Vitor Dall'Acqua]

ok, it now uses java_home for the java tmp dir...

It doesn't improve.. but one thing that might be the problem, is the same
thing I reported here, quite some time ago...

https://forum.rclone.org/t/constant-access-to-the-same-file-over-and-over-again/9849

I use rclone to serve the files from google drive and Jriver uses libbluray
to display the menus on Windows.
Without the cache backend of rclone it's impossible to use libbluray
because it hammers the files, instead of grabbing it all, it keeps
accessing it over and over again.

Right now, I'm testing with isos on my NAS, on my LAN, nothing like rclone
but looking at the logs this seems to be the case.
The best thing would be that libbluray actually copies all the bdjo,
*.mpls, *.clpi and all data files.. and access m2ts that play in the
background with bigger chunks of data.

that's just my guess but looking at the logs and taking 2 to 3 minutes to
actually start a disc and looking at logcat and see it access mpls over and
over, this seems to be the case.
Hopefully this is something easy to change and not something that requires
rewrite of libbluray entirely.



On Fri, Jan 29, 2021 at 2:33 PM Vitor Dall'Acqua <veggav at gmail.com> wrote:

> no it does not
>
> On Fri, Jan 29, 2021 at 2:26 PM Vitor Dall'Acqua <veggav at gmail.com> wrote:
>
>>   setenv("LIBBLURAY_CACHE_ROOT",
>> CSpecialProtocol::TranslatePath("special://userdata/cache/bluray/cache/").c_str(),
>> 1);
>>
>> solves option[n++].optionString = str_dup   ("-Djava.io.tmpdir=/storage/
>> emulated/0/Android/");
>>
>> it seems.
>>
>> On Fri, Jan 29, 2021 at 1:33 PM Vitor Dall'Acqua <veggav at gmail.com>
>> wrote:
>>
>>> I have a guess why it's sluggish now..
>>>
>>> This is how kodi sets the temp dir:
>>> #ifdef HAVE_LIBBLURAY_BDJ
>>>   std::string cacheDir =
>>> CSpecialProtocol::TranslatePath("special://userdata/cache/bluray/cache");
>>>   std::string persistentDir =
>>>
>>> CSpecialProtocol::TranslatePath("special://userdata/cache/bluray/persistent");
>>>   bd_set_player_setting_str(m_bd, BLURAY_PLAYER_PERSISTENT_ROOT,
>>> persistentDir.c_str());
>>>   bd_set_player_setting_str(m_bd, BLURAY_PLAYER_CACHE_ROOT,
>>> cacheDir.c_str());
>>> #endif
>>>
>>> but.. java doesn't honor it and tries to use /tmp/bdj-cache-dir
>>> and that's why I had to use
>>>
>>>     option[n++].optionString = str_dup
>>> ("-Djava.io.tmpdir=/storage/emulated/0/Android/");
>>>
>>> Petri, you know libbluray better than anyone.
>>>
>>> What is going on with this?
>>>
>>>
>>> On Fri, Jan 29, 2021 at 11:18 AM Vitor Dall'Acqua <veggav at gmail.com>
>>> wrote:
>>>
>>>> Playing on nvidia shield tv pro (2019)
>>>>
>>>> same for 2k movies.
>>>> The problem is somewhere here:
>>>>
>>>> https://github.com/xbmc/xbmc/pull/19102/commits/c895ed9d7652f2345bfb0a347c85b77a81e944b1#diff-2dcdd81ad44e3f2f759d9e58cfb0dcbca6d7509c19a6521b29f8b760579c40cdR4693
>>>>
>>>> On Fri, Jan 29, 2021 at 11:05 AM Shaya Potter <spotter at gmail.com>
>>>> wrote:
>>>>
>>>>> On Fri, Jan 29, 2021 at 4:02 PM Vitor Dall'Acqua <veggav at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Java isn't installed system wide. It's just a library being loaded.
>>>>>> if I use adb shell to do this there's nothing to be returned.
>>>>>>
>>>>>> I'll test it now while I test JIT disabled.. but I'm pretty sure it's
>>>>>> how Kodi treats menu playback.
>>>>>> I have fixed the chapter skipping and seeking in titles with popup
>>>>>> menus so I know that is do some really weird things during menu playback,
>>>>>> like stopping time and such.
>>>>>>
>>>>>
>>>>> but I'm not sure why kodi should behave performantly on x86 and not on
>>>>> android (unless the android device is severly underpowered relative to the
>>>>> x86, which can be true).
>>>>>
>>>>> what device are you playing it on?  nvidia shield (generation?) or
>>>>> something else?
>>>>> _______________________________________________
>>>>> libbluray-devel mailing list
>>>>> libbluray-devel at videolan.org
>>>>> https://mailman.videolan.org/listinfo/libbluray-devel
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/libbluray-devel/attachments/20210129/5ded4bd4/attachment.html>