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.
Thanks. And "in the meantime" is not better to revert to LibreELEC 2.2.x also for latest versions and latest builds of LibreELEC with Kodi 17.0?
Consider that not only Hide.me could use a certificate that will expire after year 2038....
LibreSSL seem to not be so interested to solve this issue, as you can read he says: "You need to actually fix this at the operating system level."
(2016-09-02, 13:43)zaphod24 Wrote: [ -> ]Thanks for the suggestions. Any suggestions for values to start with and if overvolting is needed?

Modest overclock:
Code:
sdram_freq=500
v3d_freq=400

High overclock:
Code:
sdram_freq=550
core_freq=500
v3d_freq=500
over_voltage=4
sdram_schmoo=0x02000020

You could try going to sdram_freq=600 too but that bay introduce instability.

With any overclock if you start seeing instability then lower the overclock level. In my experience:
The modest setting will work on almost all Pi's.
The high setting will work on the majority of Pi's.
sdram_freq=600 will be reliable on less than half the Pi's.
(2016-09-02, 14:08)outcave Wrote: [ -> ]Thanks. And "in the meantime" is not better to revert to LibreELEC 2.2.x also for latest versions and latest builds of LibreELEC with Kodi 17.0?
Consider that not only Hide.me could use a certificate that will expire after year 2038....
LibreSSL seem to not be so interested to solve this issue, as you can read he says: "You need to actually fix this at the operating system level."

You mean LibreSSL 2.3.0, as this problem seems to have been introduced in LibreSSL 2.3.1.

For the time being, the answer is "no" as we're not going to stay on an outdated version of LibreSSL with potential security issues simply because certificate authorities are issuing certificates that expire in more than 22 years from now - they could easily use a more realistic date that avoids this issue.

While I agree it's a troubling issue, it's not one that (right now, IMHO) justifies ignoring all future updates of LibreSSL. This is an issue for LibreSSL to resolve, assuming they intend to, otherwise they may as well drop support for all 32-bit operating systems (on Linux, at least).

I guess the attitude of LibreSSL stems from their BSD origin as OpenBSD supports 64-bit time_t on all hardware (apparently), while Linux (on 32-bit hardware) does not.
(2016-09-02, 14:10)popcornmix Wrote: [ -> ]
(2016-09-02, 13:43)zaphod24 Wrote: [ -> ]Thanks for the suggestions. Any suggestions for values to start with and if overvolting is needed?

Modest overclock:
Code:
sdram_freq=500
v3d_freq=400

High overclock:
Code:
sdram_freq=550
core_freq=500
v3d_freq=500
over_voltage=4
sdram_schmoo=0x02000020

You could try going to sdram_freq=600 too but that bay introduce instability.

With any overclock if you start seeing instability then lower the overclock level. In my experience:
The modest setting will work on almost all Pi's.
The high setting will work on the majority of Pi's.
sdram_freq=600 will be reliable on less than half the Pi's.

Ok, I tried:

gpu_mem=320
sdram_freq=550
core_freq=500
v3d_freq=500
over_voltage=4
sdram_schmoo=0x02000020

Unfortunately it still causes the "invalid format" when bringing up an OSD like info. I can try to cut a clip down to a few seconds and upload it somewhere.
(2016-09-02, 15:29)zaphod24 Wrote: [ -> ]Unfortunately it still causes the "invalid format" when bringing up an OSD like info. I can try to cut a clip down to a few seconds and upload it somewhere.

Sure, I'll take a look and see if I see the issue.
(2016-09-02, 14:37)Milhouse Wrote: [ -> ]
(2016-09-02, 14:08)outcave Wrote: [ -> ]Thanks. And "in the meantime" is not better to revert to LibreELEC 2.2.x also for latest versions and latest builds of LibreELEC with Kodi 17.0?
Consider that not only Hide.me could use a certificate that will expire after year 2038....
LibreSSL seem to not be so interested to solve this issue, as you can read he says: "You need to actually fix this at the operating system level."

You mean LibreSSL 2.3.0, as this problem seems to have been introduced in LibreSSL 2.3.1.

For the time being, the answer is "no" as we're not going to stay on an outdated version of LibreSSL with potential security issues simply because certificate authorities are issuing certificates that expire in more than 22 years from now - they could easily use a more realistic date that avoids this issue.

While I agree it's a troubling issue, it's not one that (right now, IMHO) justifies ignoring all future updates of LibreSSL. This is an issue for LibreSSL to resolve, assuming they intend to, otherwise they may as well drop support for all 32-bit operating systems (on Linux, at least).

I guess the attitude of LibreSSL stems from their BSD origin as OpenBSD supports 64-bit time_t on all hardware (apparently), while Linux (on 32-bit hardware) does not.


and then I remain screwed ....
Smile
(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.
OK and thanks!
I have already contacted Hide.me about that.
I hope they will generate a new CA cert valid up to 2037 :-)

Thanks!

PS: read my PM to you
(2016-09-02, 15:30)popcornmix Wrote: [ -> ]
(2016-09-02, 15:29)zaphod24 Wrote: [ -> ]Unfortunately it still causes the "invalid format" when bringing up an OSD like info. I can try to cut a clip down to a few seconds and upload it somewhere.

Sure, I'll take a look and see if I see the issue.

I've uploaded a 30 second sample here:

https://drive.google.com/file/d/0B8TU_Cp...sp=sharing

Please forgive that it's a local news broadcast Smile
(2016-09-02, 17:47)zaphod24 Wrote: [ -> ]I've uploaded a 30 second sample here:
No issues here on RPi3 with that sample.
(2016-09-02, 18:26)smp1 Wrote: [ -> ]
(2016-09-02, 17:47)zaphod24 Wrote: [ -> ]I've uploaded a 30 second sample here:
No issues here on RPi3 with that sample.

Yes, same here - no display issues.
Hello!

I think that I find a bug. When showing submenu over selected tv-recording, some options appear twice.

Image

New LibreELEC.tv Krypton build #0901, RPi2.
(2016-09-02, 18:58)garret Wrote: [ -> ]Hello!

I think that I find a bug. When showing submenu over selected tv-recording, some options appear twice.

...

New LibreELEC.tv Krypton build #0901, RPi2.

Can you test builds #0829 then #0830 to determine if the issue starts with #0830?
(2016-09-02, 19:05)Milhouse Wrote: [ -> ]
(2016-09-02, 18:58)garret Wrote: [ -> ]Hello!

I think that I find a bug. When showing submenu over selected tv-recording, some options appear twice.

...

New LibreELEC.tv Krypton build #0901, RPi2.

Can you test builds #0829 then #0830 to determine if the issue starts with #0830?

Sure!

But not until tomorrow.
(2016-09-02, 18:44)popcornmix Wrote: [ -> ]
(2016-09-02, 18:26)smp1 Wrote: [ -> ]
(2016-09-02, 17:47)zaphod24 Wrote: [ -> ]I've uploaded a 30 second sample here:
No issues here on RPi3 with that sample.

Yes, same here - no display issues.

Ain't that always the way... I'm viewing using the myth pvr plugin and I cut the 35 min video down to 30 seconds. I'll play the 30 seconds after work tonight and see what happens. In the meantime, just curious, did you guys play the sample directly from the RPI3 or over the network with NFS/SMB?