• 1
  • 2(current)
  • 3
  • 4
  • 5
  • 146
OpenELEC Testbuilds for RaspberryPi (Kodi 17.0)
#16
Hi Milhouse,

With build 1206 tvheadend isn't working anymore.

I installed service.multimedia.tvheadend-6.0.2-#1206-milhouse-v4.1-1176-g6693090.zip tough
#17
Are you telling me it's now working again after installing the #1206 addon? Or still not working? If it's still not working, where's your logs?
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
#18
(2015-12-07, 01:22)Milhouse Wrote: Are you telling me it's now working again after installing the #1206 addon? Or still not working? If it's still not working, where's your logs?

dmesg http://sprunge.us/NDBQ
debug log http://sprunge.us/iQQc

13:11:49 15.834048 T:1722807200 ERROR: PVR - Add-on 'Tvheadend HTSP Client' is using an incompatible GUI API version. XBMC minimum GUI API version = '5.10.0', add-on GUI API version '5.8.0'
#19
(2015-12-06, 19:57)afremont Wrote: hdmi_mode=16 fixed it. Is there any advantage either way?

I think hdmi_mode=16 or changing in GUI from DESKTOP to 1080p60 will have the same effect, and you should do one or other as interlaced output is undesirable.

Quote:Did the giant debug log I posted provide anything useful about the other issue with the skipping frames and high CPU usage?

Sorry not had a chance to dig through the log yet. I'm keeping an eye on the reports, so keep posting any new discoveries.
You say you didn't have the freezes a few weeks ago. Do they go away if you revert to a Milhouse build from a few weeks ago?
#20
@Milhouse It looks like there is a 3.4.1 version of pvr.mythtv out there on github. Is there a chance of having that included in the nightly build? I have version 3.3.9 installed and I want to be sure that my live TV and recording playback problems aren't due to that. Thanks.
Experience: It's what you get when you were expecting something else.
#21
(2015-12-07, 15:46)popcornmix Wrote:
(2015-12-06, 19:57)afremont Wrote: hdmi_mode=16 fixed it. Is there any advantage either way?

I think hdmi_mode=16 or changing in GUI from DESKTOP to 1080p60 will have the same effect, and you should do one or other as interlaced output is undesirable.

Quote:Did the giant debug log I posted provide anything useful about the other issue with the skipping frames and high CPU usage?

Sorry not had a chance to dig through the log yet. I'm keeping an eye on the reports, so keep posting any new discoveries.
You say you didn't have the freezes a few weeks ago. Do they go away if you revert to a Milhouse build from a few weeks ago?

The freezes that I'm referring to are with SSH logins to various Linux boxen, not just RPi OpenELEC devices. I don't seem to get them with large file copies or iperf runs so I'm a little hesitant to blame everything on them since I was having live TV playback problems for a while before noticing the "freezes".

I created a 3 hour long recording and played it back last night using videoplayer, it pretty much played okay all the way through. I let the box sit all night and I restarted the playback and it encountered quite a few problems then finally just stopped playing back. I uploaded that log file and here it is, though it's not a debug log:
http://sprunge.us/jacQ

Last night I was leaning towards the addon maybe being the problem when the 3 hour long recording played without high CPU usage or skipping thousands of frames. For whatever reason, it didn't want to play this morning, but I also tried doing an automatic upgrade of the addon, but you can see it got a dependancy error message. Maybe that left things in some kind of disarray? It looks like there should be a newer version of the addon, so I posted above to see if Milhouse could include it in his builds (assuming that he's not doing so already). The only one I can see in the repositories is version 2.4.3. The version I currently have is 3.3.9, but I believe there is a version 3.4.1 in the github.
Experience: It's what you get when you were expecting something else.
#22
I just noticed that pvr.mythtv 3.4.0 was included in 1206, updating right now. Thanks. Smile

Ooops, that didn't work out well. The addon couldn't be loaded due to some kind of API version mismatch. Here is a log:
http://sprunge.us/jbCF

The specific message is:
Code:
12:05:50  15.385637 T:1809839008  NOTICE: PVRManager - starting up
12:05:50  15.391278 T:1964720128  NOTICE: initialize done
12:05:50  15.391536 T:1964720128  NOTICE: Running the application...
12:05:50  15.467081 T:1782576032   ERROR: PVR - Add-on 'MythTV PVR Client' is using an incompatible GUI API version. XBMC minimum GUI API version = '5.10.0', add-on GUI API version '5.8.0'
12:05:50  15.467420 T:1782576032 WARNING: UpdateAndInitialiseClients - failed to create add-on MythTV PVR Client, status = 6
12:05:50  15.467549 T:1782576032 WARNING: UpdateAndInitialiseClients - failed to load the dll for add-on MythTV PVR Client, disabling it
Experience: It's what you get when you were expecting something else.
#23
(2015-12-07, 01:22)Milhouse Wrote: Are you telling me it's now working again after installing the #1206 addon? Or still not working? If it's still not working, where's your logs?

It was working with 1205 build but stopped working with 1206.
Sorry it took so look but here a my logs:

log
log
log

Hope this helps!
#24
I am curious to how colorspace conversion is working on the Videoplayer builds on the RPi. When forced to output “RGB Limited” is the video being scaled 16-235 -> 0-255 -> 16-235?

I have also been testing the Intel EGL builds and have tried forcing RGB full and selecting “limited range 16-235” in Kodi. The issue with that is my display only accepts RGB limited inputs so the method doesn’t work correctly.

After extensive testing I still get the best results with these RPi builds. I was just curious if it was handled any differently than the generic Openelec builds.
#25
(2015-12-07, 21:51)Jdiesel Wrote: I am curious to how colorspace conversion is working on the Videoplayer builds on the RPi. When forced to output “RGB Limited” is the video being scaled 16-235 -> 0-255 -> 16-235?

I have also been testing the Intel EGL builds and have tried forcing RGB full and selecting “limited range 16-235” in Kodi. The issue with that is my display only accepts RGB limited inputs so the method doesn’t work correctly.

After extensive testing I still get the best results with these RPi builds. I was just curious if it was handled any differently than the generic Openelec builds.

It's purely handled by GPU harwdare, so there won't be any common behaviour compared to Intel EGL.
There should only be a single conversion. The YUV data from the video decoder gets converted/composited to RGB on-the-fly and output through HDMI.
There are different matrices used for the different YUV formats (e.g. 601/709 colourspaces) and the limited/full RGB output modes.
#26
(2015-12-07, 22:32)popcornmix Wrote:
(2015-12-07, 21:51)Jdiesel Wrote: I am curious to how colorspace conversion is working on the Videoplayer builds on the RPi. When forced to output “RGB Limited” is the video being scaled 16-235 -> 0-255 -> 16-235?

I have also been testing the Intel EGL builds and have tried forcing RGB full and selecting “limited range 16-235” in Kodi. The issue with that is my display only accepts RGB limited inputs so the method doesn’t work correctly.

After extensive testing I still get the best results with these RPi builds. I was just curious if it was handled any differently than the generic Openelec builds.

It's purely handled by GPU harwdare, so there won't be any common behaviour compared to Intel EGL.
There should only be a single conversion. The YUV data from the video decoder gets converted/composited to RGB on-the-fly and output through HDMI.
There are different matrices used for the different YUV formats (e.g. 601/709 colourspaces) and the limited/full RGB output modes.

That is great to hear, once again the RPi just works. The YUY data is converted directly to RGB limited like it should and the fact that there is only a single conversion taking place explains the results I am getting. Thanks for the clarification.
#27
(2015-12-06, 01:20)Milhouse Wrote: No sorry, you seem to be the only person (so far) with this issue. I can't remember, but did you try rebooting a "clean" system? Do you have any other systemd services running on your system (mounts etc.)?

For what it's worth, I've never been able to reboot properly after setting up my mounts (going back to Feb when I first got my Pi 2). I get a black screen and have to pull the power cable each time, I just didn't mention it because I don't have to do it all that often.

My mounts look like this:

Code:
[Unit]
Description=test nfs mount script
Requires=network-online.service
After=network-online.service
Before=kodi.service

[Mount]
What=192.168.1.66:/mnt/sdb2/PVR
Where=/storage/pvr
Options=
Type=nfs

[Install]
WantedBy=multi-user.target

Code:
[Unit]
Description=test cifs mount script
Requires=network-online.service
After=network-online.service
Before=kodi.service

[Mount]
What=//192.168.1.66/Video
Where=/storage/maindrive
Options=username=thing,password=stuff
Type=cifs

[Install]
WantedBy=multi-user.target
#28
(2015-12-08, 03:16)username145 Wrote:
(2015-12-06, 01:20)Milhouse Wrote: No sorry, you seem to be the only person (so far) with this issue. I can't remember, but did you try rebooting a "clean" system? Do you have any other systemd services running on your system (mounts etc.)?

For what it's worth, I've never been able to reboot properly after setting up my mounts (going back to Feb when I first got my Pi 2). I get a black screen and have to pull the power cable each time, I just didn't mention it because I don't have to do it all that often.

My mounts look like this:

Code:
[Unit]
Description=test nfs mount script
Requires=network-online.service
After=network-online.service
Before=kodi.service

[Mount]
What=192.168.1.66:/mnt/sdb2/PVR
Where=/storage/pvr
Options=
Type=nfs

[Install]
WantedBy=multi-user.target

Code:
[Unit]
Description=test cifs mount script
Requires=network-online.service
After=network-online.service
Before=kodi.service

[Mount]
What=//192.168.1.66/Video
Where=/storage/maindrive
Options=username=thing,password=stuff
Type=cifs

[Install]
WantedBy=multi-user.target
Have you tried just putting them in /etc/fstab instead of manually creating the systemd mount files?
Leopold's Repository: Home of LibreELEC Dev Updater ...
#29
(2015-12-08, 06:46)Leopold Wrote:
(2015-12-08, 03:16)username145 Wrote:
(2015-12-06, 01:20)Milhouse Wrote: No sorry, you seem to be the only person (so far) with this issue. I can't remember, but did you try rebooting a "clean" system? Do you have any other systemd services running on your system (mounts etc.)?

For what it's worth, I've never been able to reboot properly after setting up my mounts (going back to Feb when I first got my Pi 2). I get a black screen and have to pull the power cable each time, I just didn't mention it because I don't have to do it all that often.

My mounts look like this:

Code:
[Unit]
Description=test nfs mount script
Requires=network-online.service
After=network-online.service
Before=kodi.service

[Mount]
What=192.168.1.66:/mnt/sdb2/PVR
Where=/storage/pvr
Options=
Type=nfs

[Install]
WantedBy=multi-user.target

Code:
[Unit]
Description=test cifs mount script
Requires=network-online.service
After=network-online.service
Before=kodi.service

[Mount]
What=//192.168.1.66/Video
Where=/storage/maindrive
Options=username=thing,password=stuff
Type=cifs

[Install]
WantedBy=multi-user.target
Have you tried just putting them in /etc/fstab instead of manually creating the systemd mount files?

I think I tried, but ran into other problems. Maybe it would try to mount before the network was ready, or I was not too familiar with linux and wasn't able to get it working.
#30
(2015-12-05, 21:08)popcornmix Wrote:
(2015-12-05, 20:56)nalor Wrote: 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

Ideally it should behave the same as it does when libaacs is not present.
The disk is playable on the Pi - at least with 3D/MVC enabled where we just play the ssif file.

Today I've found time to fix the problem - at least on my windows kodi I can play the 'special' iso and encrypted iso's without problems - so hopefully it's also working on the RPi2 Smile

Here's the additional patch (the other one from the previous post is also necessary):

Code:
--- aacs_orig.c    2015-03-13 10:20:13.000000000 +0100
+++ aacs.c    2015-12-08 10:54:21.636131922 +0100
@@ -282,6 +282,7 @@
     num_uvs = len / 5;

     if (num_uvs < 1) {
+        BD_DEBUG(DBG_AACS, "No UVS detected - corrupted disc\n");
         return AACS_ERROR_CORRUPTED_DISC;
     }

@@ -663,6 +664,7 @@
                                uint8_t *mk, uint8_t *vuk)
{
     char str[48];
+    char str2[48];

     aacs->uks = NULL;
     aacs->num_uks = 0;
@@ -684,7 +686,7 @@
             hexstring_to_hex_array(mk, 16, ce->entry.mek);

             BD_DEBUG(DBG_AACS, "Found media key for %s: %s\n",
-                  ce->entry.discid, str_print_hex(str, mk, 16));
+                  str_print_hex(str2, ce->entry.discid, 20), str_print_hex(str, mk, 16));
         }

         if (ce->entry.vid) {
@@ -692,14 +694,14 @@
                                     ce->entry.vid);

             BD_DEBUG(DBG_AACS, "Found volume id for %s: %s\n",
-                  ce->entry.discid, str_print_hex(str, aacs->vid, 16));
+                  str_print_hex(str2, ce->entry.discid, 20), str_print_hex(str, aacs->vid, 16));
         }

         if (ce->entry.vuk) {
             hexstring_to_hex_array(vuk, 16, ce->entry.vuk);

             BD_DEBUG(DBG_AACS, "Found volume unique key for %s: %s\n",
-                  ce->entry.discid, str_print_hex(str, vuk, 16));
+                  str_print_hex(str2, ce->entry.discid, 20), str_print_hex(str, vuk, 16));
         }

         if (ce->entry.uk) {
@@ -1007,12 +1009,17 @@
{
     config_file *cf;
     int error_code;
+    /* in case the unit_key_ro.inf contains only NULL byte values it's SHA1 hash is 'ec6afe5df8a1325068b95313f82bd72c09d4f963' - there are a few unencrypted discs available that need a special workaround */
+    const uint8_t null_byte_discid[20] = { 0xec, 0x6a, 0xfe, 0x5d, 0xf8, 0xa1, 0x32, 0x50, 0x68, 0xb9, 0x53, 0x13, 0xf8, 0x2b, 0xd7, 0x2c, 0x09, 0xd4, 0xf9, 0x63 };

     aacs->path = path ? str_printf("%s", path) : NULL;

     error_code = _calc_title_hash(aacs);
     if (error_code != AACS_SUCCESS) {
         return error_code;
+    } else if (memcmp(aacs->disc_id, null_byte_discid, 20)==0) {
+        BD_DEBUG(DBG_AACS, "Detected 0-Byte AACS file - no AACS processing necessary\n");
+        return AACS_SUCCESS;
     }

     cf = keydbcfg_config_load(configfile_path);
@@ -1299,3 +1306,4 @@

     BD_DEBUG(DBG_AACS|DBG_CRIT, "aacs_set_title(%d): invalid title !\n", title);
}
+

Finally it includes only very little changes:

  1. one additional debug line
  2. a correction of the debug output in procedure '_find_config_entry'
  3. and finally the change that corrects the problem: the discid for those 'special' discs is always identical because the file 'UNIT_KEY_RO.INF' contains only NULL-bytes and so I've simply created a constant for this special 'null_byte_discid' and in case the procedure '_calc_title_hash' (that calculates the discid for the current disc) successfully returns there's now a comparison to check if the current disc is a special disc or not - and in case it is simply return 'AACS_SUCCESS' and everything is fine. This is working because the final decryption of the disc is done in procedure 'aacs_decrypt_unit' and the first action inside this procedure is to check if the unit is encrypted at all and in case it isn't it simply returns success (and in our 'special' case nothing is encrypted so everything is working well Smile )

Hopefully this is working for Milhouse too and we can reenable libaacs support Smile

PS: there's no division by zero error....
  • 1
  • 2(current)
  • 3
  • 4
  • 5
  • 146

Logout Mark Read Team Forum Stats Members Help
OpenELEC Testbuilds for RaspberryPi (Kodi 17.0)6