Posts by Pretoriano

There's a PR for Kodi that might be related to your issue! Do you have overscan set? - > https://github.com/xbmc/xbmc/pull/21026

I can confirm that using latest 5.15.y kernel (a51218097a20b10e4696fa19bef8bebf3833020) addresses the slow system update issue.(and i kind of hijacked my own thread )

HiassofT just did a quick test with a LE11 build from 18/03/2022 (commit 5591832ae999f003bc53e3f7c15dc81c06c32413 ) ,which is the last commit before the RPi kernel bump and with this build the system update no longer stalls ,so this really seems a kernel issue .

No problem! With this occasion i've also tested the update process ,same SSD, SATA adapter and RPi4 as on LE11.....update only took a few seconds on LE10.

Just finished testing on LE10,it's all good with your RTC fix.

LibreELEC (HiassofT): devel-20220328220759-4d9d4e2 (RPi4.arm)
LibreELEC:~ # journalctl | grep rtc-ds1307
Mar 29 00:02:39 LibreELEC kernel: rtc-ds1307 1-0068: registered as rtc0
Mar 29 00:02:39 LibreELEC kernel: rtc-ds1307 1-0068: setting system clock to 2022-03-28T21:02:39 UTC (1648501359)

Tried to reproduce this on my RPi4, but i couldn't.

LibreELEC - LE 10.2

Raspberry - RPi4 8GB rev. 1.4

Overclock - CPU 1800MHz GPU 600 Mhz

Tested :

- inputstream.adaptive VP9 (SW) - Netflix stream

- drmprime HEVC (HW) - local video

- ff-h264 drm_prime (HW) - local video

bcmstat - ovorclock is working

22:14:21 1800Mhz  600Mhz    0Mhz 33.10C (36.51C) 12,106   4,546,123     101,927
22:14:23 1800Mhz  600Mhz    0Mhz 33.10C (36.51C) 13,138   4,985,402     113,389
22:14:25 1800Mhz  600Mhz    0Mhz 34.08C (36.51C) 14,350   5,559,116     125,401
22:14:27  900Mhz  499Mhz    0Mhz 33.10C (36.51C) 11,662   5,026,492     100,140
22:14:29  900Mhz  499Mhz    0Mhz 32.62C (36.51C) 10,341   4,619,576      82,231^C
Peak Values: IRQ: 17612, RX: 7546972, TX: 158784

config.txt

# SPDX-License-Identifier: GPL-2.0-or-later
# Copyright (C) 2009-2014 Stephan Raue ([email protected])
# Copyright (C) 2016-present Team LibreELEC (https://libreelec.tv)
################################################################################
# Bootloader configuration
# config.txt version v1 (do not remove or change this line!)
################################################################################
# For more options and information see
# http://rpf.io/configtxt
################################################################################

# Default GPU memory split, 76MB are needed for H264 decoder
gpu_mem=128

# Don't send initial active source message.
# Avoids bringing CEC (enabled TV) out of standby and channel switch when
# rebooting.
hdmi_ignore_cec_init=1

################################################################################
# Include distribution specific config file if it exists.
################################################################################
[all]
include distroconfig.txt

# uncomment to enable infrared remote recevier connected to GPIO 18
#dtoverlay=gpio-ir,gpio_pin=18
dtoverlay=i2c-rtc,ds3231
initramfs edid.cpio
arm_b00st=1
gpu_freq=600

The forum complained about a censored word (really?) so on arm_b00st replace 00 with oo

Perfect, thanks!

The "slow update" issue is new, on older LE11 builds update was very quick.

That kernel bug was fixed so it will be easy to check if that's the cause.

If it's still there, i will enable the cmdline debug. And i have several USB - SATA adapters to test.

Hopefully i will be able to find as many bugs i can with LE11, which probably will enter a "feature freeze" at some point! xD

HiassofT your test build works as intended,system clock is set correctly even if there's no network, confirmed by Kodi UI and dmesg log.

Thanks for the fix!

EDIT: I wonder if that slow update process that i'm seeing could be related to this - > https://github.com/raspberrypi/linux/issues/4930 <- even if im my case the system start just fine after the update is complete.

Nope, no changes from me, those lines are there even after a clean install of LE11.

I don't remember if those were there prior to the systemd bump.

Another strange thing is that manually updating takes a lot longer than older LE11 builds and i'm using a SSD here. After "Update Kernel 100%" it seems to get stuck there for minutes.

Let me know if there's a way to debug the update process and will check.

Yes, i will test it tomorrow and will return with feedback.

BTW, while i was testing the RTC thing, i noticed these 3 lines during shutdown :

systemd-shutdown[1]:Failed to set timeout to 10min:Invalid argument

failed to unmount /flash:Device or resource busy

systemd-shutdown[1]:Failed to finalize file systems, loop devices, ignoring.

Ok,after more testing i managed to gather more informations.

1) It seems that LibreELEC it's using busybox's hwclock

2) Libreelec use /usr/lib/udev/rules.d/80-clock.rules but current hwclock can't handle that command

ACTION=="add", SUBSYSTEM=="rtc", RUN+="/sbin/hwclock --hctosys --utc --rtc=/dev/%k"
ACTION=="add", ENV{MAJOR}=="10", ENV{MINOR}=="135", RUN+="/sbin/hwclock --hctosys --utc --rtc=/dev/%k"

3) I disabled hwclock in busybox target configuration and enabled it in sys-utils

LibreELEC:~ # /sbin/hwclock --help


Usage:
hwclock [function] [option...]


Time clocks utility.


Functions:
-r, --show           display the RTC time
--get            display drift corrected RTC time
--set            set the RTC according to --date
-s, --hctosys        set the system time from the RTC
-w, --systohc        set the RTC from the system time
--systz          send timescale configurations to the kernel
-a, --adjust         adjust the RTC to account for systematic drift
--predict        predict the drifted RTC time according to --date


Options:
-u, --utc            the RTC timescale is UTC
-l, --localtime      the RTC timescale is Local
-f, --rtc <file>     use an alternate file to /dev/rtc0
--directisa      use the ISA bus instead of /dev/rtc0 access
--date <time>    date/time input for --set and --predict
--delay <sec>    delay used when set new RTC time
--update-drift   update the RTC drift factor
--noadjfile      do not use /etc/adjtime
--adjfile <file> use an alternate file to /etc/adjtime
--test           dry run; implies --verbose
-v, --verbose        display more details


-h, --help           display this help
-V, --version        display version

4) With the new hwclock binary the command works just fine

LibreELEC:~ # /sbin/hwclock --hctosys --utc --rtc=/dev/rtc0 --verbose
hwclock from util-linux 2.37.4
System Time: 1648402402.545322
Using the rtc interface to the clock.
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
ioctl(3, RTC_UIE_ON, 0): Invalid argument
Waiting in loop for time from /dev/rtc0 to change
...got clock tick
Time read from Hardware Clock: 2022/03/27 17:33:23
Hw clock time : 2022/03/27 17:33:23 = 1648402403 seconds since 1969
Time since last adjustment is 1648402403 seconds
Calculated Hardware Clock drift is 0.000000 seconds
Calling settimeofday(NULL, 0) to lock the warp_clock function.
Calling settimeofday(NULL, -180) to set the kernel timezone.
Calling settimeofday(1648402403.000000, NULL) to set the System time.

5) However the 80-clock.rules still fails so i had to use systemd as a workaround.

LibreELEC:~ # journalctl -b -o short-precise | grep hwclock
Mar 11 09:33:35.753542 LibreELEC systemd-udevd[339]: rtc0: Process '/sbin/hwclock --hctosys --utc --rtc=/dev/rtc0' failed with exit code 1.
Mar 11 09:33:45.004166 LibreELEC systemd[1]: Starting hwclock-start to read rtc and write to system clock...
Mar 27 20:42:27.001309 LibreELEC systemd[1]: hwclock-start.service: Deactivated successfully.
Mar 27 20:42:27.001775 LibreELEC systemd[1]: Finished hwclock-start to read rtc and write to system clock.

6) Initially i used After= sysinit.target but again,hwclock failed and i managed to get it working only after using After= kodi.target

[Unit]
Description=hwclock-start to read rtc and write to system clock
After= kodi.target

[Service]
Type=oneshot
ExecStart=/sbin/hwclock --hctosys --utc --rtc=/dev/rtc0

[Install]
WantedBy=basic.target

This workaround was just for testing and it work indeed,but it would be much better if we managed to fix the udev rule.

These days,while checking various logs i noticed that all the logs from before the network time sync are wrong (that's normal,RPi doesn't have RTC) so i remembered that i still have a DS3231 module around the house and decided to hook it to my RPi4.

So after adding dtoverlay=i2c-rtc,ds3231 and rebooting LibreELEC i proceed with the hwclock .using hwclock -w and rebooted ,this time with no network cable attached,but unfortunately the time and date were completely wrong.

LibreELEC:~ # journalctl | grep hwclock
Mar 11 09:33:35 LibreELEC systemd-udevd[336]: rtc0: Process '/sbin/hwclock --hctosys --utc --rtc=/dev/rtc0' failed with exit code 1.

LibreELEC:~ # hwclock --hctosys --utc --rtc=/dev/rtc0
hwclock: settimeofday: Invalid argument

And this is the hwclock -r  output.notice that RTC time is UTC

Quote

LibreELEC:~ # hwclock -r

Sun Mar 27 12:18:34 2022 0.000000 seconds

To make sure that everything is fine with the hw,i tested the module on Raspbian OS (bullseye) and there everything worked as intended (see image),after rebooting the OS without network ,RTC time (UTC) was used and adjusted according to my TZ.

Note: I also tested on LE 10.2 and it's not working either.

Probably it's related to Widevine, the latest version it's known to cause such issues. Downgrading Widevine to 4.10.2252.0 should fix it.

Personally i used SlyGuy Common addon (use google to find it), it's very easy to downgrade Widevine with thay.

Personally i use SolidExplorer app, it has an option to add SMB share and it's very simple to use.

Just open SolidExplorer, then Storage Manager (from the 3 dots menu) and select LAN/SMB. The wizard will help you thru the whole process.

SupervisedThinking i'm also having issues building from master branch on Ubuntu 20.04 ARM (it's an Oracle Ampere instance).

I opened a bug report on GitHub - > https://github.com/SupervisedThinking/LibreELEC-RR/issues/8

Quote from Da Flex

Looks like a Widevine issue, because DAZN and Netflix are both using it: Click!

I was almost sure that it's related to Widevine because on LE 10.2 i reverted to WDV 4.10.2252.5 and had no crash with that setup, but on the LE11 test setup i forgot to revert it.

Hi, i got the same issue yesterday but in my case the configuration is different.

System = RPi4 + LE 11 (master)

Addon = Netflix

Same as you, after watching an episode, pressing the STOP button crashed Kodi.

It does happen randomly and in my case it happened twice (2) out of four (4) times.

I dont have the logs anymore but i couldn't find anything relevant when i checked, yesterday.

NOTE : At a first look, it seems that what we have in common is that :

- we both used a RPi (but different models)

- the "offending" addons are both using inputstream adaptive (and widevine).

Quote from Enigma

I have a PN41 where the latest stable for LE 10 doesn't work, but the Nightly for 11 works (but I would like to stick with Kodi 19 until 20 is stable)

https://test.libreelec.tv/ only seems to have images for 11

Is there a way to get a version of LE10 with a more recent Linux kernel? Searching through the forums a previous LE10 nightly worked for that user, but their link didn't work anymore.

Probably the only way is to build from LE 10 branch yourself.

As far as LE11 is concerned, in my case the stable version stops to 12/02/2021, after this date Python was updated to 3.9.10 and things (mostly 3rd party addons) are not so stable anymore. Python issues are nasty because if LibreELEC or Kodi environments are not the ones to blame, then it's up to python's devs to fix the code.

So Imho if you need an always stable system, then you should stay on a stable LE version.