Posts by nvdias

    I was able to replicate the problem with a fresh install:


    I've Installed LibreELEC 9.1.502 in another new 8GB SD-CARD in my Pi 4 4GB.


    After 1st boot configured ssh, wired ethernet, fixed ip (into which my router forwards ports 80 and 443).

    Activated debug logging.

    Installed docker, linux.io repo and the add-on with letsencrypt and nginx

    Configured ddns in the add-on as requested per install.

    All seem to be ok.


    After another reboot, docker crashed as in my initial SD-CARD.

    (as before, this happens roughly 1 in each 3 reboots).


    This happens only in beta 2. In beta 1, All is ok.



    This url is for full untouched logs of this fresh install:


    http://ix.io/20xr

    (search for "segmentation fault")


    Hope this help in finding the issue.



    Thanks Guys.

    LibreELEC has been awesome !

    LibreELEC 9.2 Beta 2 and Docker

    I'm creating this thread to easily read and get support :), as the previous post was placed in the news section.



    Updated the system to Beta 2

    I have docker installed with only the official container for letsencrypt and nginx.


    a) At each 3 reboots, docker fails, at least 1 time - sometimes work, sometimes don't - always working fine in beta 1;

    b) Doing a "docker restart docker.linuxserver.letsencrypt" in ssh shell, takes a lot of time (compared to Libreelec Beta 1) and fails to start again a lot of times.

    c) System shutdown / reboot taking a lot of time (a stop job is running for docker container .... 3 minutes) - almost immediate with beta 1


    Logs from a failed docker start after system boot:




    Note docker crashes in this lines:

    Code
    1. Apr 11 17:28:41 LibreELEC dockerd[369]: time="2019-04-11T17:28:41.760117072+01:00" level=info msg="libcontainerd: started new containerd process" pid=430
    2. Apr 11 17:28:41 LibreELEC dockerd[369]: time="2019-04-11T17:28:41.760551072+01:00" level=info msg="parsed scheme: \"unix\"" module=grpc
    3. Apr 11 17:28:41 LibreELEC dockerd[369]: time="2019-04-11T17:28:41.760600776+01:00" level=info msg="scheme \"unix\" not registered, fallback to default scheme" module=grpc
    4. Apr 11 17:28:41 LibreELEC dockerd[369]: time="2019-04-11T17:28:41.797000224+01:00" level=info msg="ccResolverWrapper: sending new addresses to cc: [{unix:///var/run/docker/containerd/containerd.sock 0 <nil>}]" module=grpc
    5. Apr 11 17:28:41 LibreELEC dockerd[369]: time="2019-04-11T17:28:41.797126520+01:00" level=info msg="ClientConn switching balancer to \"pick_first\"" module=grpc
    6. Apr 11 17:28:41 LibreELEC dockerd[369]: time="2019-04-11T17:28:41.797396094+01:00" level=info msg="pickfirstBalancer: HandleSubConnStateChange: 0x4d6ab50, CONNECTING" module=grpc
    7. Apr 11 17:28:41 LibreELEC dockerd[369]: time="2019-04-11T17:28:41.819133578+01:00" level=error msg="containerd did not exit successfully" error="signal: segmentation fault (core dumped)" module=libcontainerd




    Back to LibreELEC 9.1 Beta 1 .. All is fine with docker .. no more core dumps.


    I 've also tried a Beta 2 fresh install in a clean sd-card and got the same symptoms - testing several restarts, and docker fails to start 30% to 40% of the time

    I've just installed Docker and Letsencypt on a RPi4 4G without issues. Not too sure what the issue might be with your setup, but I would uninstall Docker and letsencrypt and then reinstall.


    If you still have issues:

    Please provide a full debug log.

    How to post a log (wiki)

    1. Enable debugging in Settings>System Settings>Logging
    2. Restart Kodi
    3. Replicate the problem.

    Note: Full logs only. No partial or modified logs.

    Do not post your logs directly into the forum, use pastebin.com and post the link.

    LibreELEC 9.2 Beta 2 and Docker

    (replicated the issue)


    Updated (again) the system to Beta 2



    a) At each 3 reboots, docker fails, at least 1 time - sometimes work, sometimes don't - always working fine in beta 1;

    b) Doing a "docker restart docker.linuxserver.letsencrypt" in ssh shell, takes a lot of time (compared to Libreelec Beta 1) and failing to start again.

    c) System shutdown / reboot taking a lot ff time (a stop job is running for docker container .... 3 minutes) - almost immediate with beta 1


    Logs from a failed docker start after system boot:


    Back to LibreELEC 9.1 Beta 1 .. All is fine with docker .. no more core dumps.


    (All I've made was upgrading from beta1 to beta 2 and then back to beta 1.
    (Also tried a Beta 2 fresh install in a clean sd-card)



    Should I create a new thread for this issue ?

    As I've said, I've re installed everything in a new sd card, and the same issues - very slow docker loading docker container (in this case, letsencrypt with nginx) and failing with core dump 50% of the time.
    I will repeat the process and provide the logs.

    I've upgraded my Pi4 to LibreELEC-RPi4.arm-9.1.502.tar and found some issues with Docker.

    (using docker, linuxserver.io to support docker.linuxserver.letsencrypt).

    After the upgrade the letsecenrypt add-on (which includes nginx) takes a long time to boot and docker service itself fails around 50% of the boots with a core dumped error.


    Docker restarts also taking a long time and exiting many times with core dumps.


    Just to be sure I've re installed everything in a new sd card, and the same issues.

    I've downgraded to 9.1.501 and everything is good again with docker.


    I just cannot say if it is something with docker or with libreelec 9.1.502, nor what it is.




    Thanks

    I can think in three possible issues:

    A - in settings, input devices, hdmi - configure-it NOT to switch tv input, turn on or turn off the tv.

    B - try checking if your cables are ok

    C - you may have a defective pi4 (mine had a non working micro hdmi 1 (had to replace it at the shop) - validate by installing a different distribution , as the official raspbian.

    i guess i have the exact same issue, but there is a solution that i found.


    if you run the pi in any 60hz resolution, everything will be fine. 1080p @ 60z or 2160p @ 60hz.


    the 60hz removes absolutely ALL judder for all video types and audio profiles, and with and without subtitles. just my two cents.

    that is odd. You can not have judder free when watching 23.976fps or 25 / 50 fps movies at 60hz.

    There is no direct conversion. These formats should be played at native refresh rates configured in the white list.

    To add my voice to the mix I'm also noticing stuttering and juddering on Pi4, with newest LibreElec on videos with 5.1 audio in all formats (AC3, EAC3, and DTS). I'm using an external USB sound card and I do set the audio to 'Fixed' at 48KHz. This setup, and these videos, have been playing fine on a 3B+ for months.


    I've also noticed that, sometimes when the juddering starts the audio channels suddenly get randomly mixed up - eg center becomes left, left becomes subwoofer, etc etc - this happens during playback and then it gets stuck like that. Sometimes even a reboot doesn't cure it. There's nothing whatsoever in the kodi log.


    that is basically the same behaviour I've got.

    Try forcing 4.0 audio output (or less) and confirm that Judder disappears.

    (Stutter will continue on some subtitles - if you use them)



    Yes. Ir works fine with Pi 3.

    Waiting for new betas for pi4 :)

    After some more testings I can do a very educated guess, that the video issues are really related to audio configuration !

    I've previously said that disabling audio pass trough gives me a perfect video experience, but some of you could not confirm this.

    So, I've looked deeper in this issue and found that:


    a) If the audio output has 4.0 or more channels there are always artefacts in video. For both 23.976 and 25 fps (at a video output on 1920x1080).

    b) If the audio output is less than 4.0 (2.0, 2.1, 3.0, 3.1), video plays perfect and smooth.


    So, I'm now forcing 2.1 audio output trough HDMI and either video files and live-tv are playing great.

    This is true for audio pass-trough enabled or disabled - of course that only with audio pass-trough disabled, you can guarantee the output format.


    This is just a quick turn-around to help diagnose this "audio configuration that implies issues in video playback"

    As suggested, I'm reposting my message originally in announcement tread:


    I’m running LibreELEC-RPi4.arm-9.1.501 in my Rpi 4.

    I’ve noticed that some video does not play smoothly.

    There is judder, jerkyness and stuttering (lost frames?).

    The odd thing is that no report whatsoever in kodi.log.

    Butthe result is very unpleasant to watch.

    It happens with 23.976fps material and also live-tv @25fps.

    In the first case, kodi switches the tv to 23.976fps in the second one to 50fps (as it should be).

    Kodi.log reports the correct fps switching.

    But Looking to the video playback there’s a lot of strange motion artifacts, as if kodi is processing output to another fps different from the one it is outputting.

    I have configured “Adjust Display Refresh Rate” as “start/stop”.


    TURN AROUNDS:

    a) In version LibreELEC-RPi4.arm-9.1.501 this seems to happen only if I have audio with “Allow Pass Trough” enabled. Disabling it, the video runs fine!

    b) In version LibreELEC-RPi4.arm-9.1.002, I found a turn around by forcing “Adjust Display Refresh Rate” as “always”.


    My TV is a SONY Android TV from 2016.

    Note: I also have a RPi 3, with same configurations, in which all goes very smoothly.



    Hope this can be fixed in the next releases.

    Keep up the great work supporting the Pi 4

    ;)

    More than likely has to do with the file. H264 and H265 are very smooth, but I've noticed with some old and badly/oddly encoded videos there is slight stutters. The pi doesn't seem to break a sweat on the codecs it supports via hardware. Have been thinking about just re-encoding things to h264.

    Nope !

    The exact same video files working great with pi3.

    And it fails also in every live video channel ! (again: ok with pi 3).

    And looking into other reports, it seems to be related to this release for pi4.


    re: stuttery video playback on rpi4


    I think I also found a workaround while fiddling with it.

    It seems like this is somehow related to audio - when I set the audio output to analogue or hdmi+analogue the video playback is smooth, but when the audio output is set to hdmi only (which is the default) the video playback gets stuttery.

    So:

    I've noticed that disabling audio passtrough works ok.

    krobolbus also had good response by forcing hdmi+analogue.


    Someting at the audio processing level ???

    (I hope this would help devs into the right way).

    Video playback on rpi4 is still very stuttery as on the previous release ( LibreELEC (Leia) 9.1.002 ALPHA ) hope you guys will address this as it is pretty game breaking.


    I’m running LibreELEC-RPi4.arm-9.1.501 in my Rpi 4.

    I’ve also noticed that some video does not play smoothly. There is judder, jerkyness and stuttering (lost frames?) - The odd thing is that no report whatsoever in kodi.log – the result is very unpleasant to watch.

    It happens with 23.976fps material and also live-tv @25fps.

    In the first case kodi switches the tv to 23.976fps in the second one to 50fps (as it should be).

    Kodi.log reports the correct fps switching.

    But Looking to the video playback there’s a lot of strange motion artifacts, as if kodi is processing output to another fps different from the one it is outputting.

    I have configured “Adjust Display Refresh Rate” as “start/top”.


    TURN AROUNDS:

    a)     In version LibreELEC-RPi4.arm-9.1.501 this seems to happen only if I have audio with “Allow Pass Trough” enabled. Disabling it, the video runs fine!

    b)     In version LibreELEC-RPi4.arm-9.1.002, I found a turn around by forcing “Adjust Display Refresh Rate” as “always”.


    My TV is a SONY Android TV from 2016.

    Note: I also have a RPi 3, with same configurations, in which all goes very smoothly.



    Hope this can be fixed in the next releases.

    Keep up the great work supporting the Pi 4

    ;)