Nightly images for A64, H3, H5, H6 and R40 boards

  • Is there a chance for official NanoPi K1 Plus support?

    Only boards which are or will be officially supported by Linux kernel can be supported. Somebody must submit DT upstream and once it's confirmed, we can talk again.


    Note: We don't accept additional out-of-tree wifi drivers anymore. It's also stated in first post of this topic. In short, unless someone manages to include rtl8189ES driver in Linux, it won't be supported.

  • CEC-adapter (firmware 4.0.7) not workong on OrangePi Plus.

    Libreelec Version: LibreELEC-H3.arm-10.0-nightly-20210705-3010e06-orangepi-plus.img

    TV: Panasonic Viera PR50ST50


    CEC firmware 4.0.4 on Llibreelec 9.20 working fine with this hardware

  • Allwinner H6 has crazy stuttering in default.


    Two options help - setting dirty region to 0 and using EGL instead of Direct to Plane.


    Default = crazy stuttering

    Direct to Plane + 0 = almost no but still there

    EGL + 0 = I don't perceive any stutter in pan view


    Problem with EGL, though, is that it fails to trigger HDR mode on the TV. =/

  • Am I the only one having network problem with my Tanix H6 when returning from standby? The player is answering to pings but Kodi shows the wrong time and has no access to file shares or PRV backend.
    This happens mostly when the system was longer than 20-24h in standby and happens with these nightly builds as well as with the current audio passtrough testbuild.

  • Am I the only one having network problem with my Tanix H6 when returning from standby?

    I never observed any issue with ethernet after resume, but I'm not sure if I ever tested network access after being in suspend that long.

    Anyway, I added some code which completely turns off Ethernet PHY at suspend and completely re-init it at resume. Please test this update:

    Index of /test/ac200-suspend/

    source: GitHub - jernejsk/LibreELEC.tv at ac200-suspend

    EDIT: scratch that, I found some issues...


    BTW, which wifi chip is on your board? There are many variants of this board and 3 different wifi chips are known. I'm working on mainline driver support for all 3, so I would like to find people with all variants for testing.


    Allwinner H6 has crazy stuttering in default.

    I can't really agree with that. There might be stuttering with *some* videos, but not all. At least if they are HW decoded. Tweaking GPU settings sound like your video is SW decoded. Can you tell more about videos you watch? Like which codec, framerate, etc. Enabling debug log, watching some video and then posting log here (preferably via pastebin or similar service) will clear some questions I have.

  • ElwoodSC I prepared better test update, just follow links in previous post to test it.

    Thank you very much for that - I will test and report my findings! :)

    To elaborate a little more on the issue: To me it seems more like a Kodi issue than a OS issue, the player answers to PINGs as soon as it resumes from suspend but Kodi shows a not NTPed time on screen and is not able to access my PVR backend or my SMB-shares with movies.

    I found kodi-waitonnetwork: enabled by default with 10 sec timeout / use NTP for Online Status by mglae · Pull Request #4802 · LibreELEC/LibreELEC.tv · GitHub which comes quite close to my problems - but the fix is already included but does not work completely with my Tanix H6. Just to test it I disabled the WaitOnNetwork yesterday jut so see whether is does make a difference.

  • Wait on network is used only at boot if I'm not mistaken. It's meant to wait on network to become available, so all addons, which depend on network availability, can work. If anything, you can try with longer delay, I wouldn't disable it in your case, since you're using PVR backends and SMB.


    Anyway, please try test image anyway. If nothing else, it should lower power consumption, since it disables Ethernet PHY in suspend.

  • Anyway, please try test image anyway. If nothing else, it should lower power consumption, since it disables Ethernet PHY in suspend.

    I installed your testbuild (maaaany thanks for your support btw.) yesterday and tested it - unfortunately it does not change the odd behaviour of not using the correct time after suspend. Here is a journalctl -o short-precise from just now, as you can see from the timestamps the system is hanging behind 83 minutes and it takes (in that case) 3 minutes to correct the time. On other occasions it took much longer - mostly I lost patience and just rebooted the system. On reboot I always have a correct time.


  • ElwoodSC If I understand correctly, clock difference is the same as the amount of time spent in suspend state? If that's true, then RTC is accidentally stopped when transitioning to suspend state.


    Note that Tanix TX6 doesn't have dedicated RTC oscillator on board. It uses internal RC oscillator, which has terrible precision. Drift can be 0.5 second or more per minute.

  • Hmm, no, it is not that obvious - I switched the player to standby yesterday at 23:06 and started it this morning at around 10:56. When started it was thinking it was 83 minutes earlier until after running for three minutes it synced NTP to the correct time (at 09:36:50 in the log).
    I guess if NTP sync would be in the resume from suspend stack than the problem would be gone. From my point of view I can't the a logic to when the ntp-client tries to sync time.

    When it is just running it seems to ntp every 17 minutes - that would explain the wait time after a resume from suspend.


    Code
    Jul 26 21:10:47.744371 mediawz connmand[506]: ntp: adjust (slew): +0.015361 sec
    Jul 26 21:27:51.744636 mediawz connmand[506]: ntp: adjust (slew): +0.008531 sec
    Jul 26 21:44:55.740670 mediawz connmand[506]: ntp: adjust (slew): +0.004358 sec
    Jul 26 22:01:59.716942 mediawz connmand[506]: ntp: adjust (slew): +0.001634 sec
    Jul 26 22:19:03.744245 mediawz connmand[506]: ntp: adjust (slew): +0.000759 sec
    Jul 26 22:36:07.676150 mediawz connmand[506]: ntp: adjust (slew): +0.000785 sec
    Jul 26 22:53:11.738523 mediawz connmand[506]: ntp: adjust (slew): -0.000112 sec
  • That's about 1.43 seconds per minute drift, which is about right for imprecise RC oscillator. Only thing we can do about it, is to run NTP sync right after resume, as you suggested. But to be honest, I'm not knowledgeable enough about systemd services to fix that right away. I'll check few sources...