Posts by chewitt

RPi4 2GB and up .. because it's a simple playback device and the Foundation provides the best vendor support of all hardware we run on.

Is the ! character the first character in the passphrase, or somewhere later?

Quote from scaesare

Any ideas?

You either need to implement support for /storage/.config/xorg.conf.d/ mapping to /usr/share/X11/xorg.conf.d .. or (easier) patch the files that we get from xf86-input-libinput package with a custom image or (easiest) overwrite them with a file in projects/Generic/filesystem/use/share/X11/xorg.conf.d with whatever you like. All of the above require a custom image.

Just wondering if you're trying to use a passphrase that's too long.

Add-ons > Add-on Browser > My Add-ons > Information Providers > (pick category) > (disable everything apart from local info)

Rinse/repeat for other data types as needed.

Even if the GUI does not come up, the rest of the OS is probably running fine. Cold boot the box, then SSH in and run "journalctl | paste" and share the URL so we can see what is detected and what boot errors might be present in the system log/journal.

LE10/11 have deinterlacing support, but using all-new driver code (the entire video pipeline is different) so it's completely possible to have different results. Can you create some sample files to share so we developers can have a look?

Ping popcornmix ^

What exactly is your definition of a "complex password" ???

Quote from roykaandorp

Probably a issue with an addon, I had to remove pvr.hts in ~/.kodi/addons/ . You could remove it before you update. When you're in safe mode you could remove it from /storage/.kodi.FAILED and reboot. In the log you could see which addon fails to start.

Known issue due to gnutls changes; remove the add-on files and zip from the package cache then update and reinstall the add-on (using a new build of the add-on).

MT7601U has been enabled in kernel config since pre-LE days (OE) and should just work as I remember adding it. Most Atheros/Railtek chips are upstream and also supported, but perhaps are missing firmware. Occasionally the USB device IDs aren't mapped in the driver (hence it doesn't load) but that's not common on older chipsets as the IDs have mostly been added upstream long ago.

Do the USB ports work if you connect a keyboard (checking for dead ports)?

If yes, run "dmesg | paste" after a clean boot and connecting devices to USB ports, so we can see what the kernel logs - if anything - and share the URL(s) generated.

I'm not that familiar with RK images, but I'm wondering if the CPU serial is exposed? .. in which case we could adapt the process we use for Amlogic devices to force a persistent MAC address:

LibreELEC.tv/ethmactool-config at master · LibreELEC/LibreELEC.tv

Just enough OS for KODI. Contribute to LibreELEC/LibreELEC.tv development by creating an account on GitHub.

github.com

LE does not support USB tethering. Appreciate you said 'no' to it, but WiFi would be the easiest option.

Turn everything off and unplug all the HDMI cables. Go make a cup of tea. Come back, reconnect the cables and power everything on. Has the problem gone away? .. as random as that sounds, some variant of "turn it all off/on again" often works to clear CEC weirdness.

The i2s encoder (which packs audio frames for HDMI) supports 16/24/32-bit output as can be seen here: https://github.com/torvalds/linux…r-i2s.c#L71-L76

However, it looks like 24 is padded to 32, see: https://github.com/torvalds/linux…r-i2s.c#L48-L59

And it outputs 2-channel or 8-channel, see: https://github.com/torvalds/linux…r-i2s.c#L61-L69

So I would make an educated guess that the hardware supports 24/32 bit output over 2-channels, but only 16-bit in 8-channel mode. This is also hinted in this comment in the code: https://github.com/torvalds/linux…oder-i2s.c#L118

That also aligns with the OSMC forum post, and this alsa conf from the legacy kernel which ensures HDMI is using 16-bit LE packing: https://github.com/LibreELEC/Libr…8AUDIO.conf#L39

So I'm right (24-bit is supported) and so is the other guy (HDMI is 16-bit). Enjoy

LE11 uses upstream (Linux 5.19.y) kernels so there is 0% driver code in-common with the legacy image you found. AFAIK all S905 and later hardware supports 24-bit output (and you claim the image you found does, which would support that). Go test.

Install the older 9.0 image (last official emmc install image for Hub) and then update to 9.2.8

I'm not aware of anything in the upstream codebase that should prevent 24-bit audio being used, but it's not something I can easily validate, so you will need to do some testing. LE11 test images: https://test.libreelec.tv/11.0/Amlogic/box/

There is partial support for S905X3 devices; the OS is stable but hardware decoding is an issue. If you only need 1080p output you can disable hardware decoding and everything works. If you want 4K, not happening. No support for S905X4 at the current time.

1. Known .. the HEVC decoder isn't in as good shape as H264/VP9 ones (no VP9 on S905 tho). It's not likely to change anytime soon due to the lack of developers interested in working on the Amlogic VDEC. All historic work has been done by commercial developers who'd be happy to continue working on it - if someone pays them to do it. There might be some changes to that, but early days.

2. I've not seen random reboots with a WP2 (which should behave the same) .. hard to comment without more specific info.

3. No, we are using extline and mainline u-boot not the prehistoric vendor u-boot, so no boot.ini.

4. OS contains "ledfix.service" which deliberately sets all LEDs with a heartbeat config to 'none' as flashing LEDs are annoying on an HTPC device. You can disable/mask the service to stop that and see the system heartbeat again. To change from a system heartbeat you need to change the device-tree to use a different trigger.