Posts by chewitt

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

You can't download it, you need to build it:

https://wiki.libreelec.tv/development/build-basics

https://wiki.libreelec.tv/development/build-advanced#debug-images

Top won't be very enlightening as it shows no detail on what threads are active. For that you'll need other tools and a debug version of Kodi that includes symbols; we strip them from the binary after compile to save space.

Have a read, it's not entirely about 4K/HDR: https://wiki.libreelec.tv/configuration/4k-hdr

========== /flash/cmdline.txt ==========
boot=UUID=2001-4441 disk=UUID=30f5d869-400e-4a82-8b7b-a5173e9001ba quiet console=ttyAMA10,115200 console=tty0 drm.edid_firmware=HDMI-A-1:edid/edid-HDMI-A-1.bin,HDMI-A-2:edid/edid-HDMI-A-2.bin video=HDMI-A-1:D video=HDMI-A-2:D

I'm wasting my time ^ .. Good luck.

video=HDMI-A-1:1024x600M@60

Remove everything from config.txt, and append that ^ to cmdline.txt

Better?

Quote from libreAU

But I can definitely tell the difference between 8 and 12 bit hdr.

Well, you think you can, but since your source media is either 8-bit or 10-bit, you can only tell the difference between 8-bit and 10-bit media; which is more than enough, hence broadcasters don't bother with 12-bit media.