Posts by chewitt

Even if someone identifies an issue on LE12.2 we aren't going to ship another release so the first/only thing to test next is a current LE13 nightly. Also, if this is a device with an onboard LSPCON chip in the HDMI chain ensure all the firmwares are updated.

I've pushed revised RK3288/RK3328/RK3399/ RK356X/RK3576/RK3588 images to my test share. The main change is a kernel bump to Linux 7.2 with the latest usable iterations of the many patch series that go into current images. Of particular note: older Rockchip hardware is now using the same kernel as newer hardware since Kwiboo has been reworking old bit-rotten patches that broke and reworked patches are slowly being upstreamed.

However !!! WARNING !!! .. I'm on vacation with zero access to hardware so the images are compile tested only, and a few large G&T's have assisted some of the patch wrangling. What could possibly go wrong?

I'd advise taking a backup of KERNEL/SYSTEM before updating in case I messed things up and you need to roll back. I've not kept up with patches since Linux 6.19 so I'm half expecting some feature differences somewhere if I've missed things. Reports of success or failure (or feature completeness etc.) are appreciated.

sunlollyking There was a time where LE13 development images used GL instead, but as GLES now has feature parity with GL in Kodi (and surpasses GL in a few areas) we switched LE13 back to GLES again. The buildsystem supports a Generic 'OpenGL' build target if you want to make one for testing, but we have no plan to release GL images.

NB: I spotted a comment from you in a Kodi PR/Issue thread about lack of testing hardware. Drop me an email on my username @ LE or Kodi domains.

All drives manufactured in the last ~30 years have head auto-parking technology to avoid mechanical damage. That scratchy/clunk noise is the drive doing whatever it needs to do to safely stop when power is cut. Scripting shutdown might generate less noise but makes no real-world difference to the drive. If a drive died; it was just it's time (they don't last forever).

If the bitrate is low enough 4K content will play, but it needs to be really low to work so most 'normal' 4K content behaves badly.

Is that log using DHCP or manual? .. have you configured NTP servers? - In short, I'd like to see a log using normal DHCP and no additional configuration; thus anything we see in the log is your network pushing config to the device through the DHCP scope.

I'd also like to see a log with connman debug logging enabled. How that's achieved seems to have changed, but perhaps just add debug to kernel boot params in cmdline.txt and reboot.

Your network is definitely unusual, as evidenced by the NTP server responding with Kiss-of-Death packets.

I scrolled through the log as far as the piracy add-ons, then I lost all interest in this problem. NB: the add-ons are not technically on the Kodi banned list at the current time, but I've flagged them to be added.

Put Kodi in debug mode, reboot, leave it two minutes, then SSH in and run pastekodi and share the URL

# List of Fallback timeservers separated by ",".
# These timeservers are used for NTP sync when there are
# no timeservers set by the user or by the service, and
# when UseGatewaysAsTimeservers = false. These can contain
# mixed combination of fully qualified domain names, IPv4
# and IPv6 addresses.
FallbackTimeservers = 0.pool.ntp.org,1.pool.ntp.org,2.pool.ntp.org,3.pool.ntp.org

This is our default config ^ and we don't set UseGatewaysAsTimeservers anywhere in /etc/connman/main.conf

On boot (cold or warm) the initial datetime value in the kernel on any device with no RTC chip starts from the libc release date. Once the network is up and NTP runs the initial datetime value is corrected. This approach works fine unless something either blocks or manipulates NTP requests. Most consumer routers with a firewall don't support NTP in the DHCP scope, but pfsense has a deeper featureset and might be setting itself as an NTP source which would override defaults. When you set entries in the LE settings add-on you customise the defaults, but defaults will still be overridden by anything received in the DHCP scope.

Check the clock on the pfsense box; if this is incorrect (has drifted) it would result in propagation of wrong datetime via DHCP and that might explain future dates appearing. It's also possible that pfsense intercepts and responds to NTP requests traversing the firewall regardless of what you configure locally; except for the manual IP configuration use-case where you explicitly tell ConnMan to use a local subnet source; and since DHCP is not used it is not overridden through the scope.

ConnMan events (sources, corrections, etc.) should all be logged and visible in the systemd journal.

NB: The only way to guarantee correct time from the start of boot with an RPi board that has no RTC chip; is adding an RTC chip. As those are cheap and simple to add it's always a valid answer for some people's use-cases (esp. with offline usage).

The wiki article was correct at the original time of publishing because RPi4 launched with 2/4/8GB variants. The 1GB model has been added later to offset global RAM price increases and reduce the entry-level price point, but 1GB isn't enough for playback with most 4K media. As you've noticed/deduced, only low-bitrate 8-bit media can work within the CMA limits.

I've updated the wiki to note the limitation on 1GB models .. popcornmix is there any tweaking that can help?

Pick a current LE13 nightly and set the timezone in the LE settings addon (as it moved from Kodi in K22); not that timezone has anything to do with NTP and set wait for network. There is no need to set manual NTP servers unless your network or ISP blocks the ntp.org servers that we default to. “Nothing has been done” about NTP issues because there aren’t any issues to do anything about. NTP works fine for 99.999999% of users; the odd problem with ISP blocks or weird routers is seen but that’s all, and a rare event. Yes there are odd posts in the forum, but over a large userbase (and 80% RPi boards) that’s just statistics.

The kernel patches for older RK images are known broken for a while. I started to rework things but keep getting waylaid by other tasks; I also lack older RK hardware so it needs a load of guesswork. Right now I’m on vacation so there’s unlikely to be any change until later in the month.

Quote from hdmkv

Supports HD/object based audio? Quick AI query says yes; is it?
Supports 4K HEVC and HDR10, but not HDR10+ and DV? AI says correct; true?

Is the 4GB RAM Pi5 board good enough, or is 8GB necessary?

HD audio and 4K/HEVC and HDR10/HLG are supported but not dynamic formats like HDR10+ and DV

4GB is fine, 8GB not necessary unless planning to run other things in the background.

Quote from goofy84

Here is the log, i detected a dbus error in the logs:

The Upower dbus error is harmless and can always be ignored. It's present on 100% of LE releases.

LE has no plans to implement this because manual monitor selection from within the Kodi GUI is a Kodi (not LE) feature. Based on recent discussions it's something that Kodi might finally implement for Kodi v23 (Q*) .. but no guarantee.

Until then you can enable SSH to access the OS, then mount the boot partition and edit kernel boot params to disable the internal (normally LVDS) connector so that output defaults to HDMI instead of the internal screen.

See https://wiki.libreelec.tv/hardware/intel…generic/laptops

NB: Kodi does not support pre-execution configuration of the output device, which is what would be needed to configure anything from the LE settings add-on. Someone proposed it, but a) not quite the right way, b) the contributor didn't persist to see changes through so the PR was closed: https://github.com/xbmc/xbmc/pull/27412

Those changes are for ancient Intel Sandybridge chips so not relevant for this user on NUC8i3BEK hardware.

dtech has an LE 9.2.8 release for old hardware if you check his pinned thread.

Quote from HomerJau

Linux 7.2 has audio fix for Intel dropping HDMI audio

What fix? .. point to the specific commit please