Posts by chewitt

"If it works, don't fix it"

Kodi has "a" library (singular) for movies so even if you code it's a non-trivial change to implement multiple databases. The default Estuary skin also does not support adding new items in the top-level navigation menu. However, it's possible to add your own shortcuts similar to "recently added" or "genres" under Movies using the "node editor" addon. Using this you could add a "Home Movies" item that displays content using specific metadata or source as the node filter criteria. I believe some skins also support adding additional navigation items, which might allow you to do similar things (or leverage the nodes you added) but on the top-level menu (but I only use Estuary so I forget the names of the ones that do allow that). Worst case, and if you wanted to stick with the default Estuary skin, you can clone/hack the skin to manually hardcode the items. You need to clone /usr/share/kodi/addons/skin.estuary to /storage/.kodi/addons/skin-estuary-mod and then change the skin name in addon.xml to skin.estuary-mod to avoid a namespace clash. Or if you're more build-system minded; create a diff patch of the change and then build your own LE image (which is easier than it sounds) to always have your changes pre-built.

_emanuel_ I can add them back, but no plans to upstream them as long as there's no functional difference between v1/v2 boxes. I note that there's been some movement on MIPI-DSI support (due to the MNT Reform Laptop) so it could be interesting for you to see if the 3" display on the v2 box can be got working?

RPi4/5 can handle HEVC at 1080p resolutions but ultimately it's a Linux device so you'll experience whatever challenges and problems that Netflex chooses to inflict on the FOSS community via API changes and such. To eliminate that you need to use Kodi with an Android device with a Widevine L1 license. The device used by most Team Kodi staff is the nVidia shield; largely because nVidia shipped a load of them to be used as test devices a few years ago, but also because nVidia provides regular OS updates for the device over time unlike most Android boxes which are obsolete within minutes of shipping. The other would be Amazon firesticks and such which (again) have the DRM licenses needed for long-term easy access to the DRM protected services.

Have a read of https://wiki.libreelec.tv/hardware/amlogic .. there's a device-tree included in the AMLGX "box" image. Also read recent release notes to understand the current state of things. I'd have thought OSMC was the best OS to use on that device.

Have you read https://wiki.libreelec.tv/configuration/ir-remotes ?

The log shows no attempt to switch to HDR modes which implies HDR isn't exposed as an option through the kernel rendering system which implies the Intel GPU drivers in the kernel we are shipping (also the latest available) don't support HDR. Updating firmware doesn't change anything in the kernel drivers, and comparisons against other OS (with entirely different software stacks) aren't meaningful.

It would help to see the EDID info which is logged in kodi.log on startup; this doesn't show as you've enabled debug after boot.

The issue and latest findings should be reported upstream to the Pi devs via their GitHub tracker (as advised in post #62 back in March).

The upstream kernel switched IR keymaps to the "toml" format so I'd guess you need to make the same changes in your file. Have a look at the keymaps in /usr/lib/udev/rc_keymaps/ to crib the format changes (not hard).

Your Q was already answered: https://github.com/LibreELEC/LibreELEC.tv/issues/8322

If the same file being played by the same K21-b1 version of Kodi on Windows works, the issue is likely to be Intel drivers, in which case our normal course of action is to simply wait for Intel to finish adding support for their latest/recent chips.

WiFi is conected via the SDIO bus which supports device discovery, so even if the device-tree file you're using describes a Broadcom wireless module (as is the case with all the generic reference designs) the bus is probed and if a Realtek device ID is found the correct driver will run, and as long as the firmware is available WiFi will work. BT is different; it's a serial UART device and requires device-tree to correctly describe the hardware, and if a Broadcom chip is the 'compatible' hardware described a Realtek chip doesn't work. The solution to that is creating a dedicated device-tree file for the box. It's not a particularly complicated process (fairly easy to copy/paste) but still requires you to then create kernel patches and self-build an LE image and most users aren't interested in having a go.

I replied in the other thread.

https://github.com/LibreELEC/LibreELEC.tv/pull/4566 <= That's the PR that dropped support for Slice boxes. In there you'll find the original add-on that FiveNinjas created and LE buildsystem package.mk files that tell you where the drivers are. Compile the drivers for your OS and then use the add-on (or use it for inspiration on how to control the LEDs). The only barriers to doing things are time and effort.

The percentage of x86_64 users peaked around 30% in the early years of OpenELEC then gradually declined to a stable 10% figure in recent years. For a long time the main driver was probably Pi boards being cheap and good value. These days they're a lot less cheap; but then the alternatives have also risen in price so the status quo has persisted.

1080p or 1080i media? .. interlaced media needs different settings enabling (read https://wiki.libreelec.tv/configuration/4k-hdr)

echo "0b05 18f0" > /sys/bus/usb/drivers/<module>/new_id

The kernel probes for USB hardware and the dongle is visible on the USB bus, but the driver is not being loaded; so the driver in that (rather old) 4.19 kernel doesn't support the card. The ^ above approach used to be supported for adding unknown IDs to a driver from userspace but I didn't use it in years so no idea if it still works. You need to replace <module> with the module name. NB: In current kernels (Linux 6.6) the correct module name is "r8188eu" not "8188eu" but this is likely the newer in-kernel module and not some older realtek vendor driver (prob. with a different module name) that might be in older LE images.

I'd start with a current LE12 nightly image as that kernel should support the card. If you then need to go backwards in time for better RPi2 hardware support move to LE 9.2.8 and retest again. I have no recollection now of what LE release used 4.19 kernels.

Ahh, that explains then. Thanks for clarifying. We're contemplating where we go with changes..

Copying binaries between different LE major versions or from other distros occasionally works but is never guaranteed. I'm going to have a look at Ubuntu 18.04 and what it's doing (need to find something with an Intel CPU for this though). I'm wondering if they have udev rules that run ntfs or they aliased a script that runs ntfsfix to fsck.ntfs. I'm 100% sure the util-linux tools support FAT/VFAT but do not support (and never have supported) NTFS; so the output from the fsck command needs explaining.