Posts by chewitt

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.

There are no (reliable) tools for clearing dirty NTFS filesystems, only on Windows.

Crash logs are normally in /storage/.kodi/temp/ .. upload a zip somewhere (but ideally not here) if needed.

Have you read https://wiki.libreelec.tv/configuration/4k-hdr?

RPi4 and RPi5 do not support 4K@60 4:2:0 output, and some TV's (or specific HDMI ports on the TV) only support 4K60 4:2:0 input, so when the RPi outputs e.g. 4K@60 in 4:2:2 the TV cannot display that format. On some TV's the solution is to enable "Deep Colour" or some kind of special/extended/enhanced modes on that port (there is no standard terminology so vendors invent their own weird namings) or to move the RPi connection to another HDMI port that supports 4:2:2.

Are you using adjust-refresh + whitelist to play [email protected] content at [email protected], or is it being forced to 4K@60?

NB: RPi4/5 have identical HDR capabilities. DRMPRIME must be enabled with the Direct-to-Plane settings (not EGL). Also ensure that on the RPi side the HDMI cable is connected to port 0 nearest the PSU connector.

These are "nodes" in Kodi terminology. Have a look at the Node Editor add-on in the Kodi repo.

It looks like the /storage partition was not expanded to 100% after the initial writing of the image, although when that fails we would normally see a 32MB partition not 160MB (as the 512MB image has a 32MB /storage partition). I would boot from an SD card so the internal storage is not the boot device, then unmount any auto-mounted /dev/mmcblk1p* partitions. Now you can use 'parted' to resize the partition and 'resize2fs' to grow the filesystem.