Kodi Community Forum

Full Version: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0)
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
(2016-09-03, 23:12)zaphod24 Wrote: [ -> ]Had a little more time to test today. Even with 0902, a modest overclock is needed to stop the "invalid format" issue. Without it, the problem still occurs. Works just fine with the modest overclock so I am calling that a win.

I'd be interested which part of the overclock is required. I suspect it is the sdram part, so you could try removing core_freq and v3d_freq from config.txt.
Just noticed a small issue which must have started over the last few weeks.
I'll try and narrow the exact build.
My rpi3 goes through an AVR (pioneer vsx 922)
The AVR is set to not pass through HDMI when in standby.
When I switch off the AVR at the end of the night, the HDMI signal is correctly not passed through. However if the pi is rebooted whilst the AVR is off (happens automatically as i have a cron job to do this at 5am daily) then as the pi reboots, it brings the HDMI back up and starts passing it through to the TV whilst the AVR remains in standby.
I don't remember seeing this behaviour before the last few weeks so uncertain if it's a pi issue or AVR issue so I'll try going back through builds to see if it stops.
Just reporting now to see if anyone else can confirm.
Image
(2016-09-04, 13:11)popcornmix Wrote: [ -> ]
(2016-09-03, 23:12)zaphod24 Wrote: [ -> ]Had a little more time to test today. Even with 0902, a modest overclock is needed to stop the "invalid format" issue. Without it, the problem still occurs. Works just fine with the modest overclock so I am calling that a win.

I'd be interested which part of the overclock is required. I suspect it is the sdram part, so you could try removing core_freq and v3d_freq from config.txt.

Using 0903 it looks like the only required overclock is the ram at 500.
I am seeing a large amount of ERRORs in the logs for CEC when I have it disabled on my RPI3.

http://sprunge.us/OFXb
(2016-09-04, 18:49)pyrodex Wrote: [ -> ]I am seeing a large amount of ERRORs in the logs for CEC when I have it disabled on my RPI3.

http://sprunge.us/OFXb

Read above, could be the name change for the CEC settings file. Disable it again (so the disabled setting is saved to the new settings file), or wait until tonight's update when it should be disabled again after you update.
(2016-09-04, 17:02)zaphod24 Wrote: [ -> ]Using 0903 it looks like the only required overclock is the ram at 500.

Thanks. Does removing the sdram overclock and adding:
Code:
v3d_limiter=0x1080f1
help? See here for explanation.
Build #0904 is broken - major stuttering with any video.
(2016-09-05, 06:31)smp1 Wrote: [ -> ]Build #0904 is broken - major stuttering with any video.

Not really seeing that here (although I haven't had much time to test) - can you post a debug log?
New LibreELEC.tv Krypton build #0904: RPi / RPi2
(Supercedes previous build)

Code:
# uname -a
Linux rpi512 4.7.2 #1 Sun Sep 4 21:11:16 BST 2016 armv6l GNU/Linux

# vcgencmd version
Sep  2 2016 11:53:38
Copyright (c) 2012 Broadcom
version 0706e45eb49a02aadefa58183d474791df2a81fb (clean) (release)

# lsb_release
LibreELEC (Milhouse) - Version: devel-20160904211015-#0904-g3be9cfe [Build #0904]

# vcdbg log msg 2>&1 | grep DTOK
002390.263: Kernel trailer DTOK property says yes

# Kernel device tree status: Enabled

Based on tip of LibreELEC.tv master (3be9cfe3, changelog) and tip of XBMC master (5bcf9ba7, changelog) with the following modifications: Build Highlights:
  1. ffmpeg: fix for pixellated thumbnails
  2. Restore old CEC settings filename
  3. llvm and various package updates (clean build)
Build Details:
  1. LibreELEC.tv:
    • tvheadend42: update to 4.1.2236 (PR:688, 1 commit, 2 files changed)
    • docker: update to 1.12.1 (PR:691, 1 commit, 2 files changed)
    • rsyslog: initial addon (PR:684, 6 commits, 17 files changed)
  2. XBMC:
    • skin: remove all use of hyphen as none value (PR:10388, 1 commit, 69 files changed)
    • [Estuary] fix / unify PVR window breadcrumbs (PR:10381, 3 commits, 8 files changed)
    • [cmake/linux] Add target to execute tests with valgrind (PR:10350, 1 commit, 1 file changed)
    • VideoPlayer: ffmpeg, ignore pics before first key frame (PR:10391, 1 commit, 2 files changed)
    • VideoPlayer: catch silly CRedirectException, fixes crash (PR:10387, 1 commit, 1 file changed)
    • VideoPlayer: fix and cleanup deinterlacing methods (PR:10339, 12 commits, 49 files changed)
    • [cmake] fix sse detection (PR:10372, 4 commits, 12 files changed)
    • VideoPlayer: fix vaapi after 6cad53545815eb1cca65e9997a9382550d204ed7 (5bcf9ba7)
  3. newclock5:
    • Commits no longer in build:
      • VideoPlayer: fix and cleanup deinterlacing methods (932b027a)
      • RBP: Add Pi specific deinterlace support reporting (4f4eb77f)
  4. Additional commits/pull requests/changes not yet merged upstream:
    • Added: [env] patch: Fix memory leak in mesa 12.0.1 (fixed in 12.0.2)
    • Added: [env] PR:689: llvm: update to 3.9.0
    • Added: [env] PR:690: Package updates
    • Added: [pkg] PR:10393: peripheral: Add backward compatability for older settings files
    • Added: [pkg] PR:10400: VideoPlayer: fix lateframes if fps does not equal refresh rate
(2016-09-05, 06:38)Milhouse Wrote: [ -> ]
(2016-09-05, 06:31)smp1 Wrote: [ -> ]Build #0904 is broken - major stuttering with any video.

Not really seeing that here (although I haven't had much time to test) - can you post a debug log?
http://sprunge.us/KcRL
OK yes, lots of stutter when using MMAL, but OK with OMX.

Edit: With only MMAL enabled and playing an h264/720p/23.976fps video, in the PlayerDebug overlay I see "drop" increasing by 1 every 1 second, while playback frame rate is about 2 or 3 fps. With SD/25fps material I don't see "drop" increasing, but playback is still very choppy.
PR10400 is likely the cause of the stutter.
Here's build #0904x with fix for PR10400: RPi / RPi2
(2016-09-02, 16:05)Milhouse Wrote: [ -> ]
(2016-09-02, 15:31)outcave Wrote: [ -> ]and then I remain screwed ....
Smile

Yes, I'm afraid so. It's much harder for Linux to change to 64-bit time_t on 32-bit platforms, as detailed here. The LibreSSL developers have a history of using and supporting OpenBSD which (for various reasons outlined in the LWN article) has already made the jump to 64-bit time_t everywhere, so I understand their attitude although I may not agree with it. Perhaps switching to LibreSSL was a bad idea if this is how they're going to act going forward, as it's pretty much a "fsck you" to (32-bit ABI) Linux.

In the meantime, the certificate authority industry should be mindful of this issue, and I'm sure many already are, and simply avoid issuing certificates with expiry dates after 2038 until there is a solution that supports Linux. I would suggest you contact Hide.me and discuss the issue with them, perhaps they have an alternative certificate you could use.

Hi again.
I don't think the certificate authority industry should be mindful of this issue, the problem is LibreSSL, OpenSSL works fine!
Hide.me answered to me that the certificate date problem is on LibreSSL and not with OpenSSL or with PolarSSL.
They "fully support only the official OpenVPN community distribution and that one is supposed to be linked with OpenSSL or PolarSSL ( mBed TLS ), not LibreSSL. The say more: "In OpenSSL, versions above 1.0.0, this bug is fixed and 32bit machines/OSes may validate any date constraint. OpenSSL uses it's own date routines and does not depend on the OS".

Then, they will not reissue a new certificate beacuse of LibreSSL...
Well, I think Hide.me right, it's not their problem and they are right the other that issue certificate with date more then 2038.

I do not want to debate, but why LibreELEC choose to use LibreSSL instead on the "classic" OpenSSL?
May be the word "LIBRE" is more fashionable then "OPEN"? Big Grin

Anyway, to summurize, LibreSSL on 32bit OS (such as Raspberry Pi, Raspberry Pi 2, and so on...) will not support Certificates issued with date more then 2038, it seem that they are not interested to solve the issue, so the problem will remain in LibreELEC.

I hope and I expect the LibreELEC community/devolopers will seriously evaluete this problem/limitation and will move again to OpenSSL.

Thanks!
Any project using current LibreSSL with Linux 32-bit is going to have this issue, which includes new OpenELEC builds. It's an issue for LibreSSL/Linux to sort out between themselves. Not using LibreSSL on Linux is of course an option, but not a decision we'll be taking overnight - there are sound reasons not to use OpenSSL anymore, and flip-flopping back and forth between LibreSSL and OpenSSL every time there's an issue is not really a workable solution.

Since Linux isn't going to change it's 32-bit ABI any time soon to support 64-bit time_t, the only solution is for LibreSSL to implement their own time routines (as OpenSSL already does) but I suspect a degree of anti-Linux/pro-OpenBSD developer ego is manifesting itself here.