Kodi Community Forum
OpenELEC Testbuilds for RaspberryPi (Kodi 16.0) - Printable Version

+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: General Support (https://forum.kodi.tv/forumdisplay.php?fid=111)
+---- Forum: Raspberry Pi (https://forum.kodi.tv/forumdisplay.php?fid=166)
+---- Thread: OpenELEC Testbuilds for RaspberryPi (Kodi 16.0) (/showthread.php?tid=231092)



RE: OpenELEC Testbuilds for RaspberryPi (Kodi 16.0) - afremont - 2015-12-05

It took a while, but I got the logs for the issue. I couldn't use pastbinit because the log was too large, so I used the logfiles thingy that automatically builds a compressed archive of all the logs. Here it is:

https://www.dropbox.com/s/o1rjw9fa1a6eu09/log-2015-12-04-22.39.58.zip?dl=0

Somewhere between 14:30 and 15:00 the issue occurred. It seemed to take a little longer than usual, but it still happened nonetheless. I was doing other things and didn't notice exactly when it happened. Let me know if I can provide anything else.


RE: OpenELEC Testbuilds for RaspberryPi (Kodi 16.0) - nalor - 2015-12-05

(2015-11-29, 23:56)Milhouse Wrote:
(2015-11-29, 23:28)nalor Wrote: Can you tell what kind of problems appeared with libaacs? I couldn't find anything here in this thread nor in the RaspberryPi section here in the forum - I only noticed that libaacs got removed beginning with build #1010 and the comment 'disable libaacs as this seems to be responsible for BD ISO crashes' - but couldn't find details about this issue.

https://github.com/OpenELEC/OpenELEC.tv/pull/4378

Today I've found time to play with the iso I've got from Milhouse and fix the main problem in libaacs - basically it is that this disc is simply not a valid bluray... there are a couple of things really strange in the aacs directory:
# MKB_RW.inf is completely filled with 00
# MKB_RO.inf is completely filled with 00

So I'm 100% sure this disc isn't an image of a real bluray - but nevertheless libaacs shouldn't lock up even if the disc is somewhat strange Wink

When libaacs tries to read records from the file 'MKB_RO.inf' it is done this way:
Code:
while (pos + 4 <= mkb->size) {
        len = MKINT_BE24(mkb->buf + pos + 1);

(....)

        pos += len;
    }

So when all values in the source file are 0, the variable 'len' will also be always 0 and in fact we're getting an endless loop and this is the reason for the lockup.

To fix this I've included a check if len=0 and 'break' the loop if this condition is detected. Finally I had to adjust a few followup procedures that don't expect that this main procedure might fail.. but in the end there's no lockup any longer.

Here's the diff that can be applied to the file mkb.c from the libaacs-0.8.1 source (I've never created a diff before - hopefully it's useable this way):

Code:
--- mkb_orig.c    2015-12-04 22:40:48.644390058 +0100
+++ mkb.c    2015-12-05 00:34:27.272274520 +0100
@@ -48,6 +48,13 @@
             return mkb->buf + pos;
         }

+        if (len == 0) {
+            BD_DEBUG(DBG_MKB, "Couldn't retrieve MKB record 0x%02x - len=0 error detected (%p)\n", type,
+                  (void*)(mkb->buf + pos));
+
+            break;
+        }
+
         pos += len;
     }

@@ -114,6 +121,9 @@
{
     const uint8_t *rec = _record(mkb, 0x10, NULL);

+    if (!rec) {
+        return 0;
+    }
     return MKINT_BE32(rec + 4);
}

@@ -121,6 +131,9 @@
{
     const uint8_t *rec = _record(mkb, 0x10, NULL);

+    if (!rec) {
+        return 0;
+    }
     return MKINT_BE32(rec + 8);
}

@@ -136,6 +149,9 @@
{
     const uint8_t *rec = _record(mkb, 0x21, len);

+    if (!rec) {
+        return NULL;
+    }
     if (rec) {
         rec += 4;
         *len -= 4;
@@ -148,6 +164,9 @@
{
     const uint8_t *rec = _record(mkb, 0x20, len);

+    if (!rec) {
+        return NULL;
+    }
     if (rec) {
         rec += 4;
         *len -= 4;
@@ -159,6 +178,10 @@
const uint8_t *mkb_subdiff_records(MKB *mkb, size_t *len)
{
     const uint8_t *rec = _record(mkb, 0x04, len) + 4;
+
+    if (!rec) {
+        return NULL;
+    }
     *len -= 4;

     return rec;
@@ -167,6 +190,10 @@
const uint8_t *mkb_cvalues(MKB *mkb, size_t *len)
{
     const uint8_t *rec = _record(mkb, 0x05, len) + 4;
+
+    if (!rec) {
+        return NULL;
+    }
     *len -= 4;

     return rec;
@@ -180,6 +207,10 @@
const uint8_t *mkb_signature(MKB *mkb, size_t *len)
{
     const uint8_t *rec = _record(mkb, 0x02, len);
+
+    if (!rec) {
+        return NULL;
+    }
     *len -= 4;

     return rec + 4;
@@ -242,3 +273,4 @@

     return -1;
}
+

Is it possible to give it another try with this fix applied and reenable libaacs support?


RE: OpenELEC Testbuilds for RaspberryPi (Kodi 16.0) - Milhouse - 2015-12-05

(2015-12-05, 01:51)nalor Wrote: Is it possible to give it another try with this fix applied and reenable libaacs support?

Great, that's progress, thanks.

However it's crashing for me when playing the 8GB ISO (the crash is immediate, as soon as playback is started).

I'm using the following patch (should be the same as yours, modified to apply on top of libaacs when building OpenELEC):

http://sprunge.us/VWdK

which produces the following crashlog:

http://sprunge.us/fLPe

Perhaps there are additional places that need fixing now that the loop is exiting early? Although I'm not seeing the "len=0 error detected" debug message, so maybe it's failing before it gets that far? It seems to be crashing in aacs.c: https://gist.github.com/MilhouseVH/bd80fdd1adc505859754

Edit: OK, so libaacs needs a hand before enabling debug logging...
I ran kodi as follows:
Code:
export AACS_DEBUG_MASK=-1
/usr/lib/kodi/kodi.bin  --standalone -fs --lircdev /run/lirc/lircd

and the following is written to stdout/stderr when playing the 8GB ISO:
Code:
aacs.c:987: libaacs 0.8.1 [160]
aacs.c:989: Initializing libgcrypt...
aacs.c:833: Disc ID: ec6afe5df8a1325068b95313f82bd72c09d4f963
keydbcfg.c:146: Opened /storage/.config/aacs/KEYDB.cfg for r
keydbcfg.c:631: found config file: /storage/.config/aacs/KEYDB.cfg
syntax error: line 161
bad entry at or around line 160
keydbcfg.c:146: /storage/.config/aacs/ProcessingDeviceKeysSimple.txt not found
keydbcfg.c:178: /etc/xdg/aacs/ProcessingDeviceKeysSimple.txt not found
keydbcfg.c:146: /storage/.config/aacs/HostKeyCertificate.txt not found
keydbcfg.c:178: /etc/xdg/aacs/HostKeyCertificate.txt not found
aacs.c:1020: Starting AACS waterfall...
aacs.c:736: Searching for keydb config entry...
keydbcfg.c:424: /storage/.cache/aacs/vuk/ec6afe5df8a1325068b95313f82bd72c09d4f963 not found
aacs.c:425: Calculate media key...
mkb.c:76: MKB size: 1048576
mkb.c:53: Couldn't retrieve MKB record 0x10 - len=0 error detected (0x5d8b4008)
mkb.c:77: MKB version: 0
mkb.c:53: Couldn't retrieve MKB record 0x10 - len=0 error detected (0x5d8b4008)
mkb.c:53: Couldn't retrieve MKB record 0x10 - len=0 error detected (0x5d8b4008)
keydbcfg.c:507: /storage/.cache/aacs/drl not found
mkb.c:53: Couldn't retrieve MKB record 0x10 - len=0 error detected (0x5d8b4008)
mkb.c:53: Couldn't retrieve MKB record 0x20 - len=0 error detected (0x5d8b4008)
keydbcfg.c:507: /storage/.cache/aacs/hrl not found
mkb.c:53: Couldn't retrieve MKB record 0x10 - len=0 error detected (0x5d8b4008)
mkb.c:53: Couldn't retrieve MKB record 0x21 - len=0 error detected (0x5d8b4008)
mkb.c:53: Couldn't retrieve MKB record 0x04 - len=0 error detected (0x5d8b4008)
mkb.c:53: Couldn't retrieve MKB record 0x05 - len=0 error detected (0x5d8b4008)
Segmentation fault (core dumped)

The mkb.c file is here: https://gist.github.com/MilhouseVH/d8bac0f67f98ae25d54f

Without your patch (ie. with unpatched libaacs), the output is:
Code:
aacs.c:987: libaacs 0.8.1 [160]
aacs.c:989: Initializing libgcrypt...
aacs.c:833: Disc ID: ec6afe5df8a1325068b95313f82bd72c09d4f963
keydbcfg.c:146: Opened /storage/.config/aacs/KEYDB.cfg for r
keydbcfg.c:631: found config file: /storage/.config/aacs/KEYDB.cfg
syntax error: line 161
bad entry at or around line 160
keydbcfg.c:146: /storage/.config/aacs/ProcessingDeviceKeysSimple.txt not found
keydbcfg.c:178: /etc/xdg/aacs/ProcessingDeviceKeysSimple.txt not found
keydbcfg.c:146: /storage/.config/aacs/HostKeyCertificate.txt not found
keydbcfg.c:178: /etc/xdg/aacs/HostKeyCertificate.txt not found
aacs.c:1020: Starting AACS waterfall...
aacs.c:736: Searching for keydb config entry...
keydbcfg.c:424: /storage/.cache/aacs/vuk/ec6afe5df8a1325068b95313f82bd72c09d4f963 not found
aacs.c:425: Calculate media key...
mkb.c:69: MKB size: 1048576
<Kodi hangs here - busy dialog spinning>

In this case, mkb.c is: https://gist.github.com/MilhouseVH/ac0fd8c2e825a35cc461


RE: OpenELEC Testbuilds for RaspberryPi (Kodi 16.0) - Milhouse - 2015-12-05

Code:
syntax error: line 161
bad entry at or around line 160

This seems to be an error in the KEYDB.cfg file included in libaacs (ie. it's an upstream error) and copied to /storage/.config/aacs. The following patch fixes the syntax error, but the crash remains the same.

Code:
diff -Naur a/KEYDB.cfg b/KEYDB.cfg
--- a/KEYDB.cfg 2015-01-23 11:27:45.000000000 +0000
+++ b/KEYDB.cfg 2015-12-05 02:05:37.402112348 +0000
@@ -158,7 +158,7 @@
| DK | DEVICE_KEY 0x00000000000000000000000000000000 \
      | DEVICE_NODE 0x0 \
      | KEY_UV 0x00000000 \
-     | KEY_U_MASK 0x00
+     | KEY_U_MASK_SHIFT 0x00

; bar's device key
| DK | DEVICE_KEY 0x00000000000000000000000000000000 \



RE: OpenELEC Testbuilds for RaspberryPi (Kodi 16.0) - username145 - 2015-12-05

Any chance we could get this in these builds? Doesn't look like it will make it into Jarvis: 7020 (PR)


Re: RE: OpenELEC Testbuilds for RaspberryPi (Kodi 16.0) - Milhouse - 2015-12-05

(2015-12-05, 06:14)username145 Wrote: Any chance we could get this in these builds? Doesn't look like it will make it into Jarvis: 7020 (PR)

No chance, I'm afraid - too many issues, disagreement, plus it's now locked and hasn't been updated for almost 6 months. At the moment it it doesn't look like it will make it into any release, Jarvis or K* - perhaps if it's ever unlocked, rebased and cleaned up then it can be reconsidered...


RE: OpenELEC Testbuilds for RaspberryPi (Kodi 16.0) - Ollo - 2015-12-05

Hello,

I'm still figuring out why I can't get DD5.1 passtrough working using the HifiberryDigi+, while DTS passtrough works. Therefore I tried the latest build #1204 as I noticed some changes regarding Hifiberry. As it didn't change the behaviour (DD5.1 detected but no sound) please find attached a debug log hopping that it helps.

Thanks.

http://sprunge.us/DdGV


RE: OpenELEC Testbuilds for RaspberryPi (Kodi 16.0) - niwa2 - 2015-12-05

hi there,

i am new to Kodi and just got a PI2 to play with.
I am running #1203 at the moment and when i am watching a .iso with a 3D movie, then the languages für audio and subtitles are not detected. it only says "unknown".
Any other iso with 2D content works fine. Also 3D mkv is working fine. It is just 3D iso that has this problem.

Is this a known issue?
Is there some way i can fix this?

edit: same build on a Windows 10 PC (no 3D support) shows the languages correctly.

thanks
niwa2


RE: OpenELEC Testbuilds for RaspberryPi (Kodi 16.0) - Milhouse - 2015-12-05

Kodi has branched Jarvis, and master is now K* or Kodi 17 a1.

All future Kodi testbuilds will be in a new Kodi 17 thread, here.

There will be no further Kodi 16/Jarvis testbuilds in this thread (please continue Kodi 16 discussion in this thread until there are Kodi 17 builds to test!)

Thanks for all your help testing, see you in the new thread... Smile


RE: OpenELEC Testbuilds for RaspberryPi (Kodi 16.0) - jackiass - 2015-12-05

(2015-12-04, 17:29)popcornmix Wrote:
(2015-12-04, 15:59)jackiass Wrote: Here is the full log. I installed the latest build 1203. The log is how it looks after a restart and then me using the right button once. The highlight disappeared right after that.

Thanks. I've reported to original author and he's commented: https://github.com/xbmc/xbmc/pull/8129#issuecomment-161988960

OpenELEC doesn't have evtest. Can you connect the keyboard to a linux machine (Pi running raspbian should be suitable) and run:
Code:
evtest /dev/input/event0

and press some keys (or trigger other bits of keyboard if it has touchpad or similar).
Repeat for event1, event2, event3. @maxnet would like to know how the keyboard uses each of the four reported interfaces.

You may need to run "sudo apt-get install evtest" first if it is not installed.

Thanks popcornmix. I will continue to investigate with maxnet. Hopefully he will be able to come up with a fix that can be integrate into OpenELEC.


RE: OpenELEC Testbuilds for RaspberryPi (Kodi 16.0) - popcornmix - 2015-12-05

(2015-12-05, 13:34)niwa2 Wrote: i am new to Kodi and just got a PI2 to play with.
I am running #1203 at the moment and when i am watching a .iso with a 3D movie, then the languages für audio and subtitles are not detected. it only says "unknown".
Any other iso with 2D content works fine. Also 3D mkv is working fine. It is just 3D iso that has this problem.

If you disable MVC support in video/acceleration settings (on Pi) do the languages get detected correctly?


RE: OpenELEC Testbuilds for RaspberryPi (Kodi 16.0) - niwa2 - 2015-12-05

(2015-12-05, 14:47)popcornmix Wrote:
(2015-12-05, 13:34)niwa2 Wrote: i am new to Kodi and just got a PI2 to play with.
I am running #1203 at the moment and when i am watching a .iso with a 3D movie, then the languages für audio and subtitles are not detected. it only says "unknown".
Any other iso with 2D content works fine. Also 3D mkv is working fine. It is just 3D iso that has this problem.

If you disable MVC support in video/acceleration settings (on Pi) do the languages get detected correctly?

Yes. With disabled 3D support the languages get displayed correctly.

I tried this as well on #1204 with the same result. But #1204 does not play anything in 3D. With #1203 3D is working fine.


RE: OpenELEC Testbuilds for RaspberryPi (Kodi 16.0) - popcornmix - 2015-12-05

(2015-12-05, 17:44)niwa2 Wrote: Yes. With disabled 3D support the languages get displayed correctly.
With MVC enabled we don't use libbluray. I suspect this is where language info comes from. Not something trivial to fix.

Quote:I tried this as well on #1204 with the same result. But #1204 does not play anything in 3D. With #1203 3D is working fine.
I don't see anything 3D related in changes for #1204. Can you double check? If still a problem,
then a more detailed description of exactly how it doesn't work and a debug log (wiki) would be useful.


RE: OpenELEC Testbuilds for RaspberryPi (Kodi 16.0) - niwa2 - 2015-12-05

(2015-12-05, 18:37)popcornmix Wrote:
Quote:I tried this as well on #1204 with the same result. But #1204 does not play anything in 3D. With #1203 3D is working fine.
I don't see anything 3D related in changes for #1204. Can you double check? If still a problem,
then a more detailed description of exactly how it doesn't work and a debug log (wiki) would be useful.

ok i double checked and 1204 really does not play 3d.
I played a 3d iso on 1203 in 3d.
Then updated to 1204 without changeing any settings and the same movie starts in 2d. I do not get the prompt that asks me with 3d mode i prefere. Also when i press m while playing the movie, the 3d icon next to the audio and video settings is missing in 1204.
Downgrade to 1203 and the same movie plays in 3d again.
Here is the log of 1204 with broken 3d:
http://xbmclogs.com/pp9emem6e

And here is a log of 1203 with working 3d:
http://xbmclogs.com/pmlbue7gz


RE: OpenELEC Testbuilds for RaspberryPi (Kodi 16.0) - nalor - 2015-12-05

(2015-12-05, 03:16)Milhouse Wrote:
(2015-12-05, 01:51)nalor Wrote: Is it possible to give it another try with this fix applied and reenable libaacs support?

Great, that's progress, thanks.

However it's crashing for me when playing the 8GB ISO (the crash is immediate, as soon as playback is started).

I'm using the following patch (should be the same as yours, modified to apply on top of libaacs when building OpenELEC):
(...)

I analyzed the aacs.c a little bit and I think I know where it crashed - there's a division by zero in one of the procedures because of the len=0 return value.

But I think we need to decide what the result of those fixes should be - should the iso finally play? After fixing the code above libaacs finally exits with 'AACS_ERROR_CORRUPTED_DISC' because the disc contains an AACS folder - but no valid AACS data....

So I think in the end all we can reach is that nothing is crashing, but as the disc is still corrupt it won't play Sad