Posts by chewitt

The Nest requires signed firmware and you don't have Google's signing keys, so you can build kernel, u-boot and everything needed, but you will not be able to reimage it to run what you built. There are lots of cheap S905X2 devices with better connectivity and factory boot firmware that is easily persuaded to run modern Linux. If you also want to run upstream u-boot (on Amlogic hardware) you need the signing FIPs for Amlogic boot firmware. This is simple with SBC devices which will provide full sources. It is less simple with tvbox devices which often use cheap bottom bin (lower quality) RAM chips which need tweaked RAM timing data to work; which means you typically need the specific boot FIPs (tweaked for the batch of RAM used) to get successful boot.

Amlogic GXBB has 8-bit internal and 8-bit output regardless of media content. GXL is internally 10-bit but outputs 8-bit. GXM is the first SoC that can handle a full 10-bit pipeline but now software comes in; the upstream kernel will currently only output 8-bit (some plumbing is missing) where the vendor kernel can do 10-bit, and it's the same for newer G12A, G12B and SM1 hardware. GXM (Midgard) uses "Amlogic" framebuffer compression to reduce the internal bandwidth needed with 4K media. G12A and newer (Bifrost) devices use "ARM" framebuffer compression (similar but different). Onto this you overlay all the RGB/YUV colourspace stuff that/s involved with SDR/HDR; the upstream kernel has cleaner and better organiseed plumbing for this but is further behind the vendor kernel which has horrible plumbing and lots of preset defaults but will mostly end up at the right combination of frequently neeeded settings.

I'll pass the observation that the best way to solve issues with TVDB is .. making edits to TVDB. If you ensure content (re)scrapes correctly it helps you; and anyone else trying to use it.

The poster Q is probably best asked in Kodi forums.

Your post is confusing. However:

a) If the skin works on Matrix, it works on Matrix. If you manually upgrade from Leia to Matrix you still end up on Matrix. There is no reason why you cannot remove the Leia version of the skin (reverting to Estuary) and then update and install the Matrix version and start using it.

b) If you backup a Leia install and then do a clean Matrix install and restore the 'Leia' backup you pollute the Matrix install with Leia stuff. You will need to a selective restore of only the things that don't cause conflicts (e.g. add-ons).

c) LE is packaged with the entire OS in two files: KERNEL and SYSTEM. This means you cannot update "Just Kodi" because our OS packaging dictates that you update everything at the same time .. but if you are self-compiling you can update to an image that contains only whatever Kodi change you want to make. If you are thinking to use the Leia OS base that you customised but with "Kodi Matrix" .. it's not impossible but nobody around here is likely to spend a month on forum posts to explain how, so you either know how, or it's best not to ask.

RPi4 (2GB) is not the cheapest device or best spec, but the quality of software support wins hands-down, which translates to less time fiddilng with the board and more time watching movies. Allwinner and Rockchip support continues to improve but I couldn't name a specific device that I'd personally recommend.

Chase the vendor for the correct ROM image to restore the box, or their u-boot sources (which are GPLv2 .. but good luck with that) or keep experimenting with u-boot(s) from ROM images (as you've been doing, from SD card).

We haven't published add-ons for the LE11 codebase yet, so there is no repo to connect to.

Not possible. The device has a Hisilicon Hi3798mV100 SoC chip which has zero upstream Linux kernel support (only an ancient Linux 3.18 vendor kernel) and a GPU with zero mesa GL/GLES support.

There is an "RK3328" device in our buildsystem, but no "3328" device, so add-on requests are doing exactly what you coded, which is wrong.

The u-boot you found only partially works. It looks to be compatible with the RAM, but there is some form of chip detection going on (from the error) so it's probably been created for another type of GXL device, e.g. S905X not S905W. The one good thing is .. you are experimenting from an SD card. Keep doing this, because if you flash the wrong u-boot to eMMC it becomes a major pain to recover the box (not impossible, but complicated).

The only mainline u-boot(s) that I have pre-compiled are here: Index of /testing/u-boot/ .. vim/lafrite/lepotato are all GXL devices (S905X, S905X) but the mainline sources don't really have device detection like vendor sources so from SD card they will either work or fail cleanly.

Quote from mega-samu

Also now Armbian supports this Rockchip: CSC Armbian for RK3318/RK3328 TV box boards - Rockchip CPU Boxes - Armbian forum

From a forum post in that thread you linked: [15:00:37.296] OS: Linux, 4.4.213-rockchip64, #5 SMP Fri Apr 16 17:25:31 UTC 2021, aarch64

This means the Armbian image is using the Rockchip 4.4 vendor kernel. LE has no interest in that kernel. I'll let others comment on whether there is any usable mainline kernel support.

Either you rebranded the distro name to something other than "LibreELEC" or (more likely) you haven't overriden the URL for accessing the add-on server, so it will fall back to looking for a project/device combo that genuinely doesn't exist on our server: LE has never shipped an "RK322x" device so we have never built add-ons for that image. You'll need to link to something binary compatible.

Do a force refresh on the LE repo. The add-ons are there.

Nothing stops you from booting from an SD card and storing media on a NAS drive or USB disk.

Panfrost is awesome! .. (drops mic)

It is possible to install the WC image to emmc, but I honestly forget how this is done or what the special image filenames are, and WeTek staff are no longer present/active in the forums; so should you attempt it and anything goes wrong please don't ask for help

I excluded 1080p @ 25/29.97/30 because with "double rates" allowed Kodi will switch to 1080p @ 50/59.94/60 instead and this also allows Kodi to better handle interlaced content: Kodi ONLY outputs progressive so to handle 1080i @ 25 (PAL) you need 2x progressive frames to render each 1x interlaced frame. This works at 50Hz, and drops 50% of frames at 25Hz. You can also whitelist 720p (and SD) modes if you want, but Kodi handles 1080p scaling well (as well as most TVs) so it's not normally needed. In the case of 4K media most TVs handle 1080p > 4K scaling better than Kodi, and the Kodi GUI is much snappier for navigation at 1080p (as 1/4 the data is being processed) so it's better to leave Kodi desktop resolution at 1080p (TV scales to 4K native panel resolution) and use the whitelist so Kodi switches to 4K modes only when actually needed for (hardware decoded) playback.

Connman (Connetion Manager) manages connections, so it also manages Ethernet. This commit connman/connman.git - Connection Manager might help you understand more about how the current feature works. The change it implements is not in current shipping LE, but will come next time Connman cuts a release and we bump to it. If you are into self-building LE images it's pretty trivial to bump to the latest commit for testing.