Posts by chewitt

Our distro packaging makes customising the skin complicated because Estuary is inside a squashfs file (SYSTEM) which is expanded into a virtual and read-only filesystem on each boot. You can clone the skin to /storage and then make changes to the clone, or you create a custom LE image that compiles the changes into the image.

LE is minimalist so we don't have git and change management tools in the filesystem. You could add them via a Docker container if you wanted to, with a clone of the Kodi repo to e.g. /storage/xbmc.repo acting as the source of the skin and symlinks between the root folder of the Estuary skin files and /storage/.kodi/addons/skin.MyEstuary making the skin appear locally. It has the advantage of being somewhat self-contained on the device. It requires quite a bit of setup/fiddling though (and there are no guides for it) and you need to reinvent the wheel when moving to another device. If the changes are not extensive; perhaps skip "doing it right" and just clone the skin files locally and apply changes; and rinse/repeat occasionally if needed.

The ultimate "doing it properly" is creating a custom image with the changes baked in. I have virtual machines and resources for that, and I'm using this workflow:

Fork https://github.com/xbmc/xbmc/ to your own GitHub account. Now clone your repo locally, git remote add an 'upstream' source for the Kodi repo, and git checkout -b a local topic branch to contain commits for your skin changes. You can now make changes and git commit them to the branch, and generate diff patches using git format-patch. Over time and if required, you can git fetch upstream Kodi changes from their repo and git rebase your local branch against them, and regenerate the patches.

Fork https://github.com/LibreELEC/LibreELEC.tv/ to your own GitHub account. now clone your repo locally, add an upstream remote for the LE repo, and checkout a local topic branch for your LE image changes. Add the diff patch(es) generated in the Kodi repo to packages/mediacentre/kodi-theme-Estuary/patches/ then commit them to the branch. You can now build a custom image that applies the diff patches to the skin. You can periodically fetch changes from our upstream repo and rebase your branch against them. and then rebuild the image.

No idea what works best for you .. it's about time/effort/resources/skills available

If the file glitches consistently in both LE and Kodi on Windows that might hint at a VAAPI hardware decoding issue. MPV is also a big fancy wrapper around libavcoded, but is probably using a different underlying version and/or is software decoding the file resulting in a different code path and capabilities. You can experiment in LE by disabling VAAPI hardware decoding. You can also experiment with an LE13 nightly which has newer kernel (drivers) and FFMpeg versions to see if newer is better (not always).

The extlinux.conf file is in a VFAT partition readable (and thus editable to change the dtb name) on any modern OS, even Windows.

Quote from bulk

Do you recommend another board that works better with LibreELEC than RPi5?

Nope. I have 40+ ARM SoC boards and RPi5 is the best (consistent and reliable) experience of them all. I don't ever use WiFi with any device though, and if forced to use WiFi i'd be using a USB device with a proper external antenna, or a WiFi bridge; not the onboard module which I've always found to be a bit rubbish for streaming use.

The error message is generated between kernel + iwd + ConnMan so isn't something we control and the key is something obscure and internal to 802.11 radio standards. If you're already using a WPA2/3 mixed mode network poor signal strength is probably the underlying cause.

There is no database or config file in Kodi that stores ROM/Emulator/Controller data but if you are using IAGL? it stores that kind of information under /storage/.kodi/userdata/addon_data/plugin.program.iagl/dat_files .. there's usually an XML file per target platform (being emulated).

Have you tried installing other emulators so there's a choice to use? (no idea if that might prompt something... just a guess).

LE13 has general rendering improvements over LE12 and older releases as @sarbes has spent time on optimisations.

Note: the patch I linked will do nothing for you on an x86_64 device as it's for the OpenGLES rendering path (used with ARM SoC devices) and Generic does not use GLES rendering. There's probably a similar point in the OpenGL code path where you can add something similar though.

The website/webserver is up and working fine, so if there's a problem, it's local to your environment or connection.

Quote from ghtester

Mostly due to unfixed issues with subtitles that I have reported a long time ago

One of the decisions made when doing a takeover of the project 18-months ago was ignoring the historic issues list and starting out with a clean slate. The historic issue list has ~1500 open tickets with no priority, most poorly reported, and most poorly investigated, and mostly no idea whether the reporting users are even around and still using Tvheadend. Why burden the 'new' team with a huge pile of old crap? .. it's a better use of very-finite human resources to focus on what's still current and cared about.

Anyone with a still-valid issue is encouraged to report it via https://github.com/tvheadend/tvheadend/issues - Follow the template and provide logs from tests with a current/recent release. Old issue reports are visible here: https://old.tvheadend.org/projects/tvheadend if there is any merit/value in linking some old data/info in the new report.

emelsky If you are able to boot some other OS, e.g. Ubuntu Live USB, the issue is the BIOS not liking our syslinux bootloader. If that's the case you can boot into Ubuntu and perform a manual install. In short; create a new GPT partition scheme with two EXT4 partitions (BOOT = 512MB or 1GB and STORAGE = remaining space). Copy the KERNEL and SYSTEM files to the boot partition then install and configireu the working bootloader, e.g. if the Live USB uses grub2, install that, along with a boot entry to auto-boot LE (crib the content from the syslinux.cfg file). It's probably a good idea to ensure you're using the latest BIOS/firmware for the T620.

The "invalid-key" error can be multiple things including poor signal (never a strong point of Pi boards) but another common iissue is having the network in WPA3 mode; which the broadcom WiFi module doesn't fully or properly support, so you need to use WPA2/3 mixed mode.

An example of what boot firmware is compiled from: https://github.com/LibreELEC/amlo…ter/khadas-vim2

The acs.bin file contains RAM timing data. The main challenge with Android STB hardware is they frequently use cheap (low-bin) RAM parts that are cheap because they are out of spec, so the box manufacturer 'tweaks' the default timing data to suit the chips used in a production run, and this effectively causes the ROM to become unique to that batch of devices. You can then roll dice on whether that ROM will/won't work with any other devices.

The AMLGX "box" image doesn't contain a working u-boot, it assumes vendor u-boot is present and working. You need to try what I'd call "board" files, e.g. VIM2, or such that have full boot firmware. If you can find one that works (not guaranteed) the advantage will be that you can write the image to eMMC and boot from there.

If you have working vendor u-boot on the device you should at least be able to use the "box" image to boot LE. Android boxes will normally boot from SD but if that's a problem and USB works; go with the flow.

Use the backup function in the settings add-on to preserve LE12 state, then update as normal. If you decide to roll back, then you need to clean install and restore the backup as Kodi does not support (and gracefully handle) downgrades.

It fails at the second stage of boot (BL2) and never reaches the third stage (u-boot) where vendor u-boot versions for Android have support for flashing with Amlogic burning tool etc. implemented. Possible causes:

a) You flashed a ROM image built with the wrong RAM timing data, triggering reset.

b) The eMMC chip on the board is failing and boot fails because more data cannot be read, triggering reset.

It's fiddly to recover from this situation as the first stage (BL1) always attempts to load BL2 boot from eMMC first, and in your case BL2 is found but then fails (boot loop). The couple of times I had to self-recover from this scenario I've shorted pins on the eMMC chip with a small screwdriver to disable the chip at power-on to ensure BL1 does not find BL2 code on eMMC, allowing it to be found on an SD card. I've then experimented with various LE images for GXL/GXM boards until I hopefully find one with compatible RAM timing so that boot reaches Linux userspace or at least the u-boot console; where I can run commands to erase the eMMC device ensuring the board will alway boot from SD card, which gives me a start point for further recovery.

For me the next stages are then simple because I'm only interested in booting LE and LE boot code can be flashed to both SD card and eMMC storage. Restoring Android ROM's is trickier because LE images use upstream u-boot which doesn't support proprietary stuff like Amlogic burning tool, and ROM files are packaged using proprietary tools that modern Linux doesn't support, and boot code in the images (once tools are found to extract/dump it out) is designed only for eMMC installation so you cannot test it easily from SD cards. Nothing is unsurmountable, but it becomes fiddly, there is no simple HOWTO guide writen up in the wiki, and most users do not have the aptitude for figuring things out themselves. I can't speak for others, but I'm not that interested in trying to spoon-feed instructions on this as it's never fun. If you do have the right aptitude; there's enough info and hints above ^ for you to make progress.

Amlogic's 3.10 codebase is full of very old, very ugly, and very fragile code. The moment you start "fixing" things you cause breakage in other areas. It doesn't matter how many times you hint, ask, beg, or plead. No developer with any common sense is going to start a quest looking for CEC issues because however well meaning the attempt, you quickly end up in some rat-hole and burn hundreds of man-hours, and people prefer doing fun things with their donated free time, not that. TL/DR: if CEC works for you that's great, and if it doesn't work for you, sadly it just doesn't. IMHO Kodi life is always easier when you avoid CEC.

WireGuard doesn't care whether the underlying transport is WiFi or Ethernet. In theory they work the same. In practice WiFi is never as reliable as Ethernet .. because radio isn't as reliable as a physical connection. You also need to factor in ye olde vendor codebase with old drivers. Whether your unique WiFi environment is fast enough for your needs; nobody knows

mount -o remount,rw /flash
nano /flash/config.txt

From the SSH console ^

See this patch: https://github.com/chewitt/LibreE…-for-vsyn.patch

In LE13 the Generic image has been switched from OpenGLES to OpenGL so this patch will not be relevant (as it's patching GLES) but you might be able to do the same thing with the GL context?

Start with a debug log that demonstrates the issue occuring. We will be interested to understand the system config and type of media being played, e.g. to see if it's 4K60 which requires more power (could be power issues) leading to undervolt warnings in the system log. It could also be the cables if not 'certified' ones. Regular causes of display problems also include micro-HDMI to HDMI adapters, Argon 40 cases, and a load more things. System temp is also something to be tracked.

In terms of releases/versions, I would update to an LE13 nightly image instead of downgrading to LE11. Nightlies cannot be tagged as stable due to Kodi not-yet-starting the Piers release cycle, but I've run them daily on an RPi5 for the last year and half .. they seem pretty stable to me