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
Posts by Pretoriano
-
-
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.
-
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
Code22: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
Code
Display More# 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 :
-
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
CodeACTION=="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
Code
Display MoreLibreELEC:~ # /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
Code
Display MoreLibreELEC:~ # /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.
CodeLibreELEC:~ # 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
Code[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.
CodeLibreELEC:~ # 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.
And this is the hwclock -r output.notice that RTC time is UTC
QuoteLibreELEC:~ # 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.
-
-
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
-
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).
-
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.