Going by the ArchWiki for this, I would be going through step 3.2.2.
Yep, the disks are encrypted, because if I remove KEYDB.cfg and try to play the disk Kodi pops up a dialog saying:-
PlayBack Failed
This Blu-Ray disk is encrypted and can't be played.I did find a newer KEYDB.cfg, that makes Kodi works out of the box for my test disc and does not produce the VUK/VID directories… but that’s only because the VUK/VID for the disc was already included in the KEYDB.cfg
Opening VLC using this new KEYDB.cfg, also does not produce the VUK/VID. If I delete the KEYDB.cfg or use an empty KEYDB.cfg, VLC fails. So VLC is using libaacs and doing the Processing keys and a Host Key/Certificate method.
So is Kodi’s implementation of libaacs in libblurray broken so not performing the Processing keys and a Host Key/Certificate method, or is it not capable of doing so?
I couldn’t tell you that, all I know is that for as long I can remember I’ve always had to provide a KEYDB.cfg file and Kodi, to the best of my knowledge, has never created VUK/VID directories.
I update my KEYDB.cfg pretty regularly and I haven’t found a disk yet I can’t play, granted I only use Kodi for disk playback occasionally, so haven’t tested every single disk in my collection.
I also though you just need to use up to date KEYDB.cfg and that’s it - Kodi plays the disk if recognized.
So if I read the code correctly (I don’t code C/C++), with regard to the other libraries (libaacs/libmmbd)
libbluray will first try the environment variable $LIBAACS_PATH, if a failure occurs, it will try libaacs, if a failure occurs, it will then try libmmbd. This is why the log shows that if Loaded libaccs, but then says No usable libraries found.
The failure I’m having in libbluray / libaacs is occurring at:
*(void **)(&init) = dl_dlsym(p->h_libaacs, "aacs_init");if (init && open_device) {
p->aacs = init();
DL_CALL(p->h_libaacs, aacs_set_fopen, p->aacs, file_open_handle, file_open_fp);
error_code = open_device(p->aacs, device, keyfile_path);
If the init had occurred, I would have expected to see in the debug
BD_DEBUG(DBG_AACS, "libaacs "AACS_VERSION_STRING" [%u]\n", (unsigned)sizeof(AACS));
But that doesn’t occur.
Library from LIBAACS_PATH is used first, then libaacs. libaacs is found that’s why there is message in the log Using libaacs for AACS. But if something is wrong later then it tries to use libmmbd. I put few log messages and I saw this behavior.
I will check regarding calling init() function.
Can you upload AACS folder from your bluray disk? I think it would help me simulating encrypted disk.
Update: aacs_init() IS called. Just log is not visible. There are two environment variables controlling AACS_DEBUG_MASK and BD_DEBUG_MASK.
To easily debug BD&AACS create file /run/libreelec/debug/kodi.conf with content
AACS_DEBUG_FILE=/tmp/debug_aacs
BD_DEBUG_FILE=/tmp/debug_bd
AACS_DEBUG_MASK=0xffff
BD_DEBUG_MASK=0xffff
restart kodi and then you will see logs from both libraries in this two files.
@vpeter thanks! I didn’t know that could be done. That opened a whole new level of information.
1 Like
Running through Kodi not working versus working, the difference appears to be in libaacs routine “_read_vid”. Reason being there is an early exit IF the VUK/VID pair are already known from the KEYDB.cfg. When the VUK/VID pair is unknown, then execution continues to the call to “_mmc_read_auth”, which is the branch where the failure occurs.
So running through Kodi versus VLC we can trace this a little further. “_mmc_read_auth” calls “mmc_open”. I don’t conclusively have where in that routine. If it does the call “device_open” which then performs the following:
fd = _open_block_device(resolved_path);
I was expecting debug output from routine “_open_block_device”, but I don’t see that even for the VLC case. However my suspicion is this is where the failure occurs.
The AACS logs, truncate due to size. Start a few lines before they deviate.
truncated - debug_aacs-KODI_noVUK/VID
truncated - debug_aacs-VLC
When I get to that point, I will. I’ll continue to right things down in this thread as I go. Don’t feel the need to respond to everything I write.
I need to look back at the start of libbluray. There seems to be a difference is what is being sent to as the path/device.
In libbluray, the routine “disc_open” is operating different between Kodi and VLC. In the case of VLC, the root directory can be opened, so it goes into the else (i.e. IF (DP_IMG)). However for Kodi, it can’t read the root directory and goes into the IF.
if (p_fs && p_fs->open_dir) {
p->fs_handle = p_fs->fs_handle;
p->pf_file_open_bdrom = p_fs->open_file;
p->pf_dir_open_bdrom = p_fs->open_dir;
}
_set_paths(p, device_path);
#ifdef ENABLE_UDF
/* check if disc root directory can be opened. If not, treat it as device/image file. */
BD_DIR_H *dp_img = device_path ? dir_open(device_path) : NULL;
if (!dp_img) {
void *udf = udf_image_open(device_path, p_fs ? p_fs->fs_handle : NULL, p_fs ? p_fs->read_blocks : NULL);
if (!udf) {
BD_DEBUG(DBG_FILE | DBG_CRIT, "failed opening UDF image %s\n", device_path);
} else {
p->fs_handle = udf;
p->pf_fs_close = udf_image_close;
p->pf_file_open_bdrom = udf_file_open;
p->pf_dir_open_bdrom = udf_dir_open;
p->udf_volid = udf_volume_id(udf);
/* root not accessible with stdio */
X_FREE(p->disc_root);
}
} else {
dir_close(dp_img);
BD_DEBUG(DBG_FILE, "%s does not seem to be image file or device node\n", device_path);
}
For VLC the value of device_path in my test case is “/media/smf007/DUNKIRK”. This value makes sense, and in libaacs routine device_open would be able to perform a look-up in /proc/mounts.
For Kodi, I have yet to determine what it was using as device_path.
Maybe the problem is not Kodi itself but something more system based in CoreELEC?
Do you have /dev/sr0 in CE?
@vpeter I figured it out! It is that Kodi is not correctly call libbluray.
2020-05-11 10:13:34.469 T:140671914600192 DEBUG: CDVDInputStreamBluray::Open - opening /media/smf007/DUNKIRK
That is what Kodi wants to open. Then in DVDInputStreamBluray.cpp, bd_open_disc is not an available option. It only uses bd_open_stream or bd_open_files, and both of those routines set device_path to NULL
The Play Disc doesn’t work. Instead in file mode browse to the disc, bring up the context menu(?), and click play.
Not sure why Play Disc doesn’t work for you, it works fine for all my physical disks.
Doesn’t really mater at this point. Video Player doesn’t have the needed call.
I think it does matter and that’s the reason why it opens a file instead of a disk. Because you do open a file 