Posts by chewitt

I haven't pushed any changes that would/should improve or regress anything for Amlogic devices for a couple of weeks, so current nightly testing probably has more placebo than technical effect

As long as you backup the eMMC using "dd" first it shouldn't be too hard to restore it again if things go wrong. GXL devices boot the same from eMMC and SD card so once you've erased eMMC it's simple to test u-boot(s) from SD and when you've proven it works, you can write the boot stuff to eMMC. In the event you do screw up and need to erase eMMC the worst-case scenario is shorting pins on the eMMC chip to stop it being checked during boot, and then the SOC finds u-boot on SD or USB again.

IIRC there are some capabilities that OSMC runs from the secure world (BL32) to prevent them being copied (Dolby Vision?) so any mainline u-boot will lose those (not that upstream supports DV anyway). I can ask Sam for the boot FIPs (minus the BL32 bits I'd expect) and then it's a straightforward process to create a complete image. It's not something I'd have interest in adding to LE as the "box" approach with vendor u-boot works fine, but the ability to TFTP boot can be useful for testing.

RPi4 has no real to-do items remaining unless you care about 3D support - it's my daily driver and very reliable. The only negative might be the lack of native VP9 support for 4K YouTube .. but 1080p streams run fine for me with software decode so it's not an issue for me. N2+ is less supported by LE images at the current time; Amlogic upstream code is a bit experimental in places and 10-bit VP9/HEVC cause issues. CE will be a better choice for an N2 than LE right now.

Support for V4L2 deinterlace methods needs to be proven over a wider range of SoC hardware before we send things upstream. The other patches already have PR's open on the Kodi git repo, but as everything involving colourspace has an unholy level of complication it will take time to get them merged.

I would have low interest in adding this to LE images as the driver is not in-kernel, but it appears to be supporting Android 11 so the driver can probably be compile on a modern kernel. Let us know if it works?

At this point in the Kodi 19 lifecycle the only add-ons that we see "many add-ons not working" reports around are pirate shitware. Feel free to educate us otherwise with a Kodi debug log for help to continue.

Quote from Ilvy99

I am surprised that this requires optimization, since the LE9 code seems to be working great.

You appear to be missing the point that LE11 uses the upstream Linux kernel and an entirely new/different codebase. There is probably less than 1% code in common with the legacy kernel used in older LE images.

The HK forums have a lot of similar reports; though to play devils-advocate the inherent nature of support forums is you attract users with problems (we see the same here) so that's to be expected.

I have access to a German TVH installation for testing so if this is the original broadcast format it's probably not needed, but can you create a much larger sample; ~2 seconds is too short. NB: The "fix" will need someone to pick up a keyboard and do rework and optimisation on the HEVC codec. Right now it's in a state where I was able to dust off Maxime's known-unfinished code and get it compiled, but that's all. Sadly that's the limits of my coding abilities.

Quote from DoktorX

I have enable ssh and can connect with box but i cant find correct remote config files

Run "kodi-remote" to navigate in the GUI via SSH, and read https://wiki.libreelec.tv/configuration/…figuration-hard to create a remote config (despite the title it's not that hard).

You can have a look at the LE 9.2 images dtech is releasing or experiment with LE11 nightly images.

Ilvy99 the HEVC codec is not very optimised at the current time. It might help to enable adjust-refresh and set the whitelist to use 1080p @ 24/50/60Hz with 'doubled' modes working. The TV doesn't appear to have 23.976 or fractional rates like 29.97 or 59.94 but that shouldn't be an issue with PAL media; 25Hz should use 50Hz is doubling is on.

Quote from Ilvy99

I have pasted my kodi and tvheadend log files to

It's not a Kodi debug log.

Quote from Ilvy99

Is this a tvheadend client or an LE11 problem? How could I find out?

I consulted my magic 8-ball, and it said "could be" .. for a better answer you might need to share debug log files so we can see what media is being played; specifically what codec is being used and whether hardware decoding is active or not.

It's best to use an "era appropriate" version of Ubuntu to build images or the docker template we ship in distro sources else weird toolchain issues can cause issues. All official LE 9.2 images were built with Ubuntu 18.04 - so I'd use that.

I'm not able to test anything related to DVB cards/drivers, so no idea. I also disable the driver-addons (so we don't ship them) as I'm using a kernel that's always ahead of support for compiling them, so the only option in AMLGX is the in-kernel drivers. I generally suggest people run DVB cards on a separate device so you can use whatever kernel/driver combo works reliably on the headend and a latest version of LE on the client device.

Two options:

a) Fix the cert problem, see RE: Cannot Install/Update Addons

b) Grab a spare SD card and bump to an LE11 nightly https://test.libreelec.tv/ .. search on c2

mo123 the number of "developers" truly working on each SoC type is measured in fingers not hands. The support for upstream is probably there in u-boot now, or with only minor gaps, but it needs someone to go-through each of the major SoC generations and run proper tests or coordinate the testing with people who have the hardware. It's not an insurmountable task, but people have limited time. All volunteers and input on the topic would be welcome