Posts by chewitt

Not all HDMI ports are equal specification. Some TVs only support specific input on specific connectors. Some support everything on all connectors. Most common on a modern TV is the hardware supporting everything but default software config forcing different specs on different inputs. Deep Colour or similar is normally required for 4K60 and 4:2:2 input.

Remove the EDID forcing because this will override EDID on the HDMI connector and enabling/disabling "Deep Colour" on the port will change the EDID output from the TV on HDMI.

Then configure Deep Colour ON, adjust refresh ON, ensure no 4096 modes and 3840@60/59.94/50/30/29.97/25/24/23.98 are in the list, reboot for clean logs, then share a debug log showing something with HDR content.

special I did some device-tree archaeology on the Linux 3.14.y sources (used in LE 9.x images) and HardKernel 3.16.y sources.

LE sources only describe the basic "highspeed" card mode and max-speed as 100MHz. HK sources support highspeed and UHS 50/104 card modes, but a lower max-speed of 85MHz. The upstream kernel describes highspeed and UHS 12/25/50 (and DDR50 for some reason) but not UHS104, with max-speed set to 100MHz.

The current image here: https://chewitt.libreelec.tv/testing/LibreE…droid-c2.img.gz aligns the upstream kernel controller capabilities and speeds with the HK vendor kernel (remove UHS12/25 and DDR50, add SDR104, reduce the max-speed to 85MHz). Please write to a card (the problem card) and see if that makes any difference?

The reason I was asking about SMBv1 is https://github.com/xbmc/xbmc/pull/25295 .. but that wouldn't be the case. It might be worth seeing if different chunk sizes resolve the issue. This is configurable in Kodi settings now.

Have a look for dtech threads with LE 9.2 images for some devices (no idea about that one). There's nothing newer - there's no real-world mainline kernel support for 8726MX chips.

If the caching defaults don't work with 2.5GB/1GB Ethernet you need to fix your broken network not fiddle with cache settings. I would remove that to reduce the potential scope of the problem.

I used RPi3 in the past but always preferred a NUC or Amlogic box that was faster, albeit the Pi board was always a bit more reliable with media. Then RPi4 came along and moved the goalposts; same reliability but now acceptably fast and with good 4K/HDR support for newer HEVC media that I've ripped. Then RPi5 came along; functionally the same but making the RPi4 feel like some ancient slow thing from a decade ago as it's NUC fast. RK3399 is fairly well supported in the kernel now (much better than Amlogic) and on-paper it has more codecs than RPi4/5 .. but software maturity isn't in the same top-league as RPi4/5.

Kodi suffers the problem of being "swiss army-knife" software so it has a ton of features and most skins are focussed on exposing those features with a pile of fancy graphics. Last time I looked, there wasn't a "simple" skin to choose from.

N2+ is a nice board but the poor state of hardware decoding for newer Amlogic hardware in upstream kernels has impact. H264 and VP9 work well enough but we're forced to software decode HEVC and that limits HEVC to 1080p. CE with vendor kernels runs better on the hardware although the number of people using LE on boards like N2/N2+ seems to be slowly increasing. Despite all the loud noise made in forums the silent majority still have comparatively simple 1080p oriented media collections (as proven by the massive number of users still using RPi3 hardware) so LE meets their needs.

RPi5 is the gold-standard for overall performance and support with LE and RPi4 is functionally the same in most areas and a good slightly-cheaper alternative. If I had RPi4 and was weighing up the decision to upgrade to RPi5 it's not a clear choice as the functional specs are so similar. However if you're shopping new, I'd go RPi5 as the CPU performance bump is rather noticeable.

LE12 branch is on an LTS kernel (Linux 6.6.y) and 6.6.30 is only .2 minor maintenance updates behind kernel.org, and mesa is on the latest 24.0 release. The general idea of a stable release branch is that you DO NOT chase bleeding edge versions all the time (as the bleeding edge gets bloody) so that's a pretty respectable and "current" position.

LE13 (master) is ahead and currently running Linux 6.9.y and mesa 24.1 if you think something newer is the magic cure-all for your issue that is presented here with `zero technical evidence. CE also runs a completely different codebase to LE so the comparison is compelling from your side but technically irrelevant from our side

Some "pastekodi" debug log files would be a good start.

Quote from yamcenutzer

I would be grateful if someone could also shed some light on why the raspi builds can't access files (videos, music) on smb:// type urls even when sources.xml contains the right link and password.xml contains the access details for the smb share.

No issues with SMB shares here. Do your shares require/use SMBv1 or SMv2/v3 ?

Quote from kinner

Why doesn't simply send HDMI sound out to the splitter/extractor so that I could then send it to my amplifier via SPDIF optical???

"because" Kodi audio output capabilities are determined by EDID data read from HDMI, which presumably isn't replicated or passed correctly from the TV via DP to the splitter to the HDMI port on the RPi and thus Kodi doesn't see an audio device to use. Connect direct and EDID is present and correct .. and you get audio.

Connect the RPi board direct to the TV, run "getedid create" to capture the EDID to file and force Linux to see it as always present, then connect everything back via the splitter again and it will probably work.

https://wiki.libreelec.tv/configuration/edid

If it completed without error, it generated a URL on your screen. Go to plan B..

If they are in the PVR add-on (I'm guessing at that) it would be a matter for the developers of that PVR add-on to consider. They hang out in the Kodi forums - most add-ons have a support thread.

NB: One of these days someone needs to create a "Kiosk" skin for Kodi, or at least share the changes made. You're not the first person to come looking. Code in GitHub that can be diffed agains the original sources would be useful.

2024-06-05 07:38:39.588 T:1027    debug <general>: [WHITELIST] whitelisted modes:
                                                   4096x2160 @ 30.000000 Hz
                                                   4096x2160 @ 29.970032 Hz
                                                   4096x2160 @ 25.000000 Hz
                                                   4096x2160 @ 24.000000 Hz
                                                   4096x2160 @ 23.976025 Hz
                                                   3840x2160 @ 30.000000 Hz
                                                   3840x2160 @ 29.970032 Hz
                                                   3840x2160 @ 25.000000 Hz
                                                   3840x2160 @ 24.000000 Hz
                                                   3840x2160 @ 23.976025 Hz
                                                   1920x1080 @ 60.000000 Hz
                                                   1920x1080 @ 60.000000 Hz
                                                   1920x1080 @ 59.940063 Hz
                                                   1920x1080 @ 50.000000 Hz
                                                   1920x1080 @ 24.000000 Hz
                                                   1920x1080 @ 23.976025 Hz

Forcing EDID will almost certainly achieve nothing because the current EDID is being read fine. However, removing all the 4096x2160 modes from the whitelist would be advised as 99.99% of 4K media aligns with the 3840x2160 modes.

It doesn't make a lot of sense to me and it's hard to comment as I've never had boot issues with C2 boards using eMMC modules or any of the random SD cards in my collection; other than deliberate experiments with patches that were likely to break boot.

cat /storage/.kodi/temp/name-of-crash.log | paste

If that doesn't work (edit the filename) the log is over 10MB or something craps out when sending it to our paste server. Plan B is to access the Samba logfiles share over the network; when you access the folder we run a task to capture logs and zip them up. You can then copy them to a Windows box and upload them in a normal browser.

Now that I'm not looking on a phone I can see those are in the PVR section. I would assume they are created by the pvr addon that you're using, so the place to edit will be under the add-on. The long-term challenge there will be that we push updates to add-ons and if auto-updating of add-ons is enabled (hint: it can be disabled) our changes will overwrite yours.

CE uses NTFS-3G to support NTFS devices, because the older (Amlogic BSP) kernels they use do not have in-kernel drivers. LE devices are not being mounted the same way, and thus experience different issues.