[SharpCoder]

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.

#0904x did fix the stutter for me on rpi3

[outcave]

We are talking about this and in conclusion:

1. Linux will not yet support 64bit time in 32bit architectures
2. LibreSSL will not implement their own time routines (as OpenSSL already does)
3. OpenSSL is the only one that still works and will works
4. Both OpenELEC and LibreELEC use or will use LibreSSL

and then?

All of us on 32bit architectures (x86, ARM, RPI, etc..) cannot trust Certificate with date more than 2038 due to LibreSSL "stance".

I agree that switching to OpenSSL is not a decision you'll be taking overnight, but think about it seriously.

THANKS!

[CloneSnow]

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.

#0904x did fix the stutter for me on rpi3

Same Problem rpi2

[popcornmix]

@popcornmix
Did you have a chance to have a deeper look into the 1080i to 720p channel switching issue?

I would assume that this issue affects all resolutions when coming from interlaced channel and switch to a progressive channel. On HD channels the problem is more clearly visible because of the higher load they cause.
At least on my pi3 it appears to be so.

imho this needs to be fixed before kodi 17 comes out of beta.

Agreed. It's not something I can easily debug (I assume it's not possible to make a single recording that includes the channel switch?)
I'll have a play with IPTV simple and see if that will reproduce the issue.

[zaphod24]

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.

This also worked but resulted in jerky/stuttering video (as expected I think). For now I'm sticking with the sdram overclocked to 500.

[popcornmix]

This also worked but resulted in jerky/stuttering video (as expected I think). For now I'm sticking with the sdram overclocked to 500.

Not unexected. This would be interesting:
v3d_limiter=0x0c80f1

and if that is jerky then try:
v3d_limiter=0x0a80f1

[Aux_]

Here's build #0904x with fix for PR10400: RPi / RPi2

Wow! thank you for the fast reaction. TV working again :-)

[zaphod24]

This also worked but resulted in jerky/stuttering video (as expected I think). For now I'm sticking with the sdram overclocked to 500.

Not unexected. This would be interesting:
v3d_limiter=0x0c80f1

and if that is jerky then try:
v3d_limiter=0x0a80f1

v3d_limiter=0x0c80f1 was still jerky but v3d_limiter=0x0a80f1 seems ok so I've switched to using that setting and leaving the sdram at the 450mhz default. Thanks for the suggestions!

[popcornmix]

v3d_limiter=0x0c80f1 was still jerky but v3d_limiter=0x0a80f1 seems ok so I've switched to using that setting and leaving the sdram at the 450mhz default. Thanks for the suggestions!

You can switch to 0x0980f1 if you see any jerkiness or to 0x0b80f1 if there is no jerkiness but your display loses connection.
I'm quite interested in your results as it may be worth changing the default if it improves your setup and doesn't seem to have a downside.

[thegooddoctor]

#0904x did fix the stutter for me on rpi3

#0904x fixed stuttering for my RPi2's on MMAL for me; no problems with MMAL on 3D (works great)
radio works

[niwa2]

@popcornmix
Did you have a chance to have a deeper look into the 1080i to 720p channel switching issue?

I would assume that this issue affects all resolutions when coming from interlaced channel and switch to a progressive channel. On HD channels the problem is more clearly visible because of the higher load they cause.
At least on my pi3 it appears to be so.

imho this needs to be fixed before kodi 17 comes out of beta.

Agreed. It's not something I can easily debug (I assume it's not possible to make a single recording that includes the channel switch?)
I'll have a play with IPTV simple and see if that will reproduce the issue.

yes unfortunately tvheadend does not allow me to switch channels while recording something.
i wil try to reproduce this with two separate recordings in some way.

[3DBuff]

Current release #0904 gives me mega issues with screen refresh rates. I had to reverse to #0903.
I see new resolutions like 1920x1080i to choose from (not there yesterday) but the list of refresh rates dropped down to 60 and 50 fps only from 24 to 60 with all variants.
3D is stuttering for me when bumped to 60Hz

My typical setup for 3D ISO is frame packed with 23.98Hz with not a glitch.

[popcornmix]

Current release #0904 gives me mega issues with screen refresh rates. I had to reverse to #0903.
I see new resolutions like 1920x1080i to choose from (not there yesterday) but the list of refresh rates dropped down to 60 and 50 fps only from 24 to 60 with all variants.

Pretty sure that your issue is not related to #0904 (nothing changed in that area).
Is it possible you booted the Pi with the TV unpowered which has resulted in the list of supported resolutions failing to be read?

[kampfi]

Build #0904x
iptv on tvheadend stopped in 5 to 20minutes..
http://sprunge.us/cKjH

hardware is raspberry pi 3, control the kodi from pc with tool vnc

[niwa2]

@popcornmix
Did you have a chance to have a deeper look into the 1080i to 720p channel switching issue?

I would assume that this issue affects all resolutions when coming from interlaced channel and switch to a progressive channel. On HD channels the problem is more clearly visible because of the higher load they cause.
At least on my pi3 it appears to be so.

imho this needs to be fixed before kodi 17 comes out of beta.

Agreed. It's not something I can easily debug (I assume it's not possible to make a single recording that includes the channel switch?)
I'll have a play with IPTV simple and see if that will reproduce the issue.

yes unfortunately tvheadend does not allow me to switch channels while recording something.
i wil try to reproduce this with two separate recordings in some way.

So far I have Not come up with a way to reproduce this with two recordings.

But as soon as OMX is enabled the problem is gone.