Posts by chewitt

# 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

The mainline kernel codebase that LE uses lacks hardware deinterlacing on all hardware. Kodi implements bwdiff software decode which is tolerable for normal TV shows, but it's not so great for sports and anything with fast panning shots.

The vendor codebase implements it, but that's CE and not LE.

Install a current LE13 nightly to the Dell box. Assuming that doesn't magically fix things, next boot the Linux Mint install in 'Live' mode so you can mount the boot partition of the internal drive and edit syslinux.cfg to append ssh to kernel boot params. Now when you boot the problem LE install again the SSH daemon is forced to start on boot so you can SSH into the box to run pastekodi and share the log URL that's generated; which hopefully shines a light on what the underlying problem is. In the absence of some logs/info we are blind to what the issue might be.

Quote from Silver

CoreELEC versions tested

CE = someone else's problem

Their forum is the appropriate place to ask for help, not here.

I'm aware of those PR's/changes and I've understood them to resolve past issues with content appearing in the top-left corner of the screen; hence asking you to run a current LE13 nightly. That said, the general design/test assumption is that users run the desktop at 1080p to give a better navigation experience and switch to 4K only when needed. You've confirmed that works, but i'd guess some of the logic or code-maths is still broken for the less common 4K switching to 1080p when needed case. I'll flag it to the dev who's looked at those cases.

Incomplete log .. You've trimmed all the useful info

Power up the projector. Power up the C2. As long as the screen is showing SSH in and run getedid create then power the projector off, reboot the C2, wait a minute, then power on the projector and you should see Kodi? (and this should be persistent). In short, this captures the EDID data from the active HDMI connection and hard-codes the kernel (and thus Kodi) to always see the HDMI device (the projector) as connected.

B2 (imminent) > RC1 (soon) > maybe RC2 > release. I'd expect release in Autumn. There's a strong desire to get something shipped sooner than later else we'll keep queuing changes and go nowhere.

Please provide a Kodi debug log from the latest LE13 nightly that demonstrates the problem.