Posts by chewitt

The correct path for the firmware should be /storage/.config/firmware/rtw88/rtw8821c_fw.bin

LE is an OS for HTPC devices. You should run Kodi on Windows, the native OS for the tablet that supports all its hardware.

If you edit source files in the "build.LibreELEC.." folder(s) the next time you respin the build the changes will not be used (as we already built the package and nothing in the package.mk or related folders changed) and if you trigger a change by updating something in package folders and respin the build, we remove the existing unpacked sources in the build folders, then unpack and apply any diff patches, and rebuild the package. If you want to modify a package, you need to provide your changes as a diff patch against the original source that we use. Patches can live in numerous locations, but typically in a "patches" subdir of the package folder.

LibreELEC-AMLGX.arm-9.95.2-box.img.gz <= not boot tested on anything with vendor u-boot, and has a pile of changes inside so YMMV.

There are no file/disk recovery tools in LE, but with most hardware we are booting from USB/SD/HDD storage so the device can be removed from the HTPC and connected to a Desktop distro (Ubuntu, Fedora, etc.) where you can run disk recovery tools. I would advise not using the target disk, to avoid overwriting disk areas you want to recover files from.

RPi4 performance beats RPi3, but starting over with a clean install on RPi3 is the same effort.

IAGL has already been reworked for python3/K19. I've been using it since Feb. It might not have filtered through to the Kodi repo yet tho. You can get the repo installer from the developers GitHub.

The system-info screen is entirely cosmetic and has nothing to do with OS function. It's info pulled from device-tree, which presumably doesn't have much there.

An increase to cache size can solve micro-glitches in playback where (in a wireless network) the network drops completely. It cannot ever solve the issue of "there is not enough bandwidth to play my large ISO file" because you have to fill the cache over the network first, then the cache drains faster than you can refil it, and then playback stops until the cache refills; and increasing the cache size means you wait longer for play to resume than with a small cache size. The only cure for inadequate bandwidth is increasing the bandwidth.

The reason cache configuration add-ons don't exist and these controls are not in the Kodi GUI is simple. Cache fiddling causes more problems that it solves in 99% of user scenarios!

Channel switching is all about support for flushing in the hardware decoder, which is partially implemented in ffmpeg in my images. I can make sense of the other infos. I'll look into the MPEG2 issue, but I don't code so I can't fix the driver (where the issue probably is) and will need to focus on seeing if simply disabling hardware decoding for SD resolutions is an okay workaround.

Forget the S805 device, it was never supported by OE/LE in the past and modern kernel support is making positive but glacial progress and is a long way from being easily usable. The S905 box might be somewhat useable; the choice is CE which should offer best support, or you accept the very "work in progress" state of modern kernel support in LE images.

NB: Users are obsessed with running from internal storage but this complicates the bejesus out of testing images which may or may not work and provides only marginal performance benefit. You'll need to restore the correct vendor u-boot to make further progress. There are a very limited number of people supporting Amlogic hardware in these forums and I have subzero interest in install2internal issues; that script is a complete waste of personal time.

To be clear, I'm not an expert low-level developer, so access to hardware might not get me a lot further than we currently are.

Amlogic hardware has an IP block called "ge2d" which handles the tonemapping separate from the vdec. It's supported in the vendor kernel, and partially supported in the mainline kernel, but not currently in a useful way.

You can cross-grade from Nightlies to my images. You cannot cross-grade from Oleg's images (balbes150) due to different boot config. I'm interested to know what resolutions and codecs are problematic. I'm not interested in TVH logs (someone else's problem).

One of their devs confirmed that Dreambox One/Two use encrypted boot, so "FIPs" are no-go and you will need to continue chainloading u-boot, or you switch to the vendor kernel and work with CE sources rather than mainline kernel and LE. I also learned some things about the M4 chip used for MCU functions. They won't share schematics for the boards, but are happy to answer Q's and might share selected pages if we ask them specific questions. I don't have the skillset to debug much more about the boot issue without access to hardware.

tavoc The images in Index of /testing/ might improve some of the switching behaviour (improve, not resolve). I'm not sure how to disable MPEG2 but I can have a poke around. Sadly the vdec isn't in brilliant shape.

I asked Q's in the freenode channel. I'll see if I get replies..

See the file list here (VIM3 is also a G12B device): amlogic-boot-fip/khadas-vim3 at master · LibreELEC/amlogic-boot-fip · GitHub .. this is what we need to build a signed mainline u-boot.