[libbluray-devel] BD-J on UDF/ISO cannot read BDMV/STREAM

[Shaya Potter]

PR addressing this -
https://code.videolan.org/videolan/libbluray/-/merge_requests/77

On Sun, Sep 6, 2026 at 6:34 PM Shaya Potter <spotter at gmail.com> wrote:
>
> This prevents titles that have java code that validate via a stream
> file to fail-close
>
> Tried Mercy Street Season 1 (PBS, BD-J with an obfuscated Xlet). From
> older AnyDVD use I already knew the Java title is not needed for
> playback in the usual sense: it mainly writes a few GPRs and hands off
> to HDMV. On libbluray the disc would not play correctly.
>
> After tracing the Xlet, the failure was a FileNotFoundException
> opening a file under BDMV/STREAM (here 00019.m2ts). That read is what
> the protection seemingly uses to decide whether to publish the real
> episode GPRs or dummy values that play wrong obfuscated playlists.
>
> On a directory mount, I believe this is invisible: cacheAll is off and
> Java can FileInputStream the host path. On ISO/UDF, bluray.vfs.root is
> the VFS cache, and VFSCache skips BDMV/STREAM (so I believe it does
> not want to copy multi-GB .m2ts into /tmp). Java then never sees the
> file, the Xlet "fails", and the menu plays the wrong titles.
>
> Once STREAM was readable from Java (without copying the clip into the
> cache), the Xlet wrote the proper GPRs and the title played.
>
> Suggested fix: keep “do not cache STREAM,” but implement
> exists/length/FileInputStream for uncached STREAM via disc I/O
> (disc_open_path / BD_FILE_H) instead of hiding the path. Copying
> STREAM into VFSCache is not a real fix (feature .m2ts would dump
> gigabytes into the cache).
>
> After figuring this out and having my hacked up libbluray, I only then
> tested with the mounted version, with a clean libbluray, which also
> worked (hence the comment above).
>
> This might explain in general misbehaviors between iso playback and
> mounted playback.