Posts by mglae

dipswitch Answer is there, it's no firmware issue.

dipswitch Using this thread now.

Oct 15 16:48:24.478568 LibreELEC kernel: pci 0000:00:1e.4: [8086:4b32] type 00 class 0x020000 PCIe Root Complex Integrated Endpoint

Required kernel module dwmac-intel for 8086:4b32 is not included in LE. Will post a PR the next few days.

No technical information, please provide logs.

2024-10-06 15:32:15.351 T:1041    debug <general>: CPythonInvoker(1, /storage/.kodi/addons/service.joy-it.fancontrol/fan.py): trigger Monitor abort request
2024-10-06 15:32:15.352 T:939      info <general>: [Joy-IT Fan Controller 1.0.9] Joy-IT fan control service finished
2024-10-06 15:32:15.352 T:939     debug <general>: CPythonInvoker(1, /storage/.kodi/addons/service.joy-it.fancontrol/fan.py): script successfully run
2024-10-06 15:32:15.352 T:939      info <general>: CPythonInvoker(1, /storage/.kodi/addons/service.joy-it.fancontrol/fan.py): waiting on thread 1496097344
2024-10-06 15:32:20.359 T:1041    error <general>: CPythonInvoker(1, /storage/.kodi/addons/service.joy-it.fancontrol/fan.py): script didn't stop in 5 seconds - let's kill it

_PvD Guess without any knowledge about gpiozero: GPIO "resource" is not freed because thread is killed instead of terminated gracefully.

Usually this is caused by Kodi hanging or crashing at shutdown and not writing wakeup information.

Unfortunately on your old LE 11 system pasting logs does not work any more because http://ix.io service was suspended. To upload it manually do (e.g.):

cat /storage/.kodi/temp/kodi.old.log | nc termbin.com 9999

You may consider updating to LE12.

Looking at the HW side the RTC battery may be dead. Having an older PC it is always worth just to replace the CR2032 on the motherboard. Remember to reset the BIOS/firmware settings to default after that.

Will not help, nobody is waiting for the service.

You can add before=multiuser.target but then boot is delayed until time-sync.target is reached and you stuck in splash screen without internet connection.

Better develop some kind of vpn-online.service using a time out and add it to the chain. Remove time-sync.target from the dependencies and rely on a larger timeout of network-online.target set in LibreELEC-Settings addon.

Today there is only a debug message generated on successful load. Setting drm.debug=0x4 kernel parameter should print it.

Another test: using drm.edid_firmware=edid/edid.binx should create a load error.

video=HDMI-A-1:D is accepted:

Sep 27 18:21:54.780410 LibreELEC kernel: [drm] forcing HDMI-A-1 connector on

But there is no sign for the edid.bin file.

Continue to use X11 and xrandr with the Generic-legacy image on your older HW. Put the image in /storage/.update and reboot

Information about /storage/.config/.sleep.d/*.power scripts got lost over time.

On my long time installed system there is still the sample file (not functional):

#!/bin/sh
case "$1" in
   pre)
     <do something on suspend>
     ;;
   post)
     <do something on resume>
     ;;
esac

Matches can be found by using the forum search.

The wiki dependencies are:

After=network-online.target nss-lookup.target wait-time-sync.service connman-vpn.service
Before=kodi.service

You are free to change anything you want.

You may consider removing wait-time-sync.service, this unconditionally wait until network is usable. The already included network-online.target is doing similar but with a network timeout defined in LibreELEC-Settings. The default 10sec may be too less, increase it at least to 30-60sec.

Quote from chewitt

mglae Could ConnMan be patched to log failed attempts too? .. might be useful?

Sure, I will have a look.

IIRR connman is only logging successful ntp adjusts by default.

See this post to enable full logging.

Just created the PR.

Quote from Sbrez81

I don't undestand why I see ds1307, mine is ds3231

ds3231 is supported by the ds1307 driver.

If the RTC ts having a battery you always should check the voltage.

My experience of the following is from Generic, I do not owe any RPI.

• RTC state can be shown with cat /proc/driver/rtc
• Boot activity: journalctl -k |grep rtc_cmos (your rtc module name is definitely different):

Sep 08 08:21:21 LibreELEC kernel: rtc_cmos 00:05: RTC can wake from S4
Sep 08 08:21:21 LibreELEC kernel: rtc_cmos 00:05: registered as rtc0
Sep 08 08:21:21 LibreELEC kernel: rtc_cmos 00:05: setting system clock to 2024-09-08T06:21:19 UTC (1725776479)
Sep 08 08:21:21 LibreELEC kernel: rtc_cmos 00:05: alarms up to one month, y3k, 114 bytes nvram, hpet irqs

Quote from frankvw

the output of hwclock -r comes back with UTC time, not local time (as per the output in my above post.) So why is that?

When hwclock was designed for PC Compatible the time was usually stored in the HW clock as local time (from Windows), Therefore default setting is assuming stored clock is local time.

Linux is storing UTC in HW clock to be independent from local time setting and having a monotone clock. When using hwclock you have to add option -u or --utc.

Quote from Sbrez81

I live in Italy so GMT +1

You are currently having Daylight Saving Time ending last Sunday in October, CEST = GMT+2. Try hwclock -u -r

For historical reasons hwclock default to local time. Use hwclock -u -r to use stored UTC time correctly.

But ADDON_VERSION is 12.80.0 and e.g. current PVR addons are not compatible any more.