Posts by chewitt

This is a TV underscan problem and not an HTPC hardware or software problem.

HDMI ports are not always equal. If the TV has other ports, move the cable around and see if any of them work better? See if any are configured for 'PC' use and if possible set them to 'normal' (or some other) mode. You can also see if changing the default desktop resolution from 1080@60 to 1080@50 in case this generates a better outcome?

The option of last resort is to 'calibrate' the output via Kodi settings > System > Display > Calibration. It's the worst option because unlike a CRT tube where calibration mechanically adjusts the spread of the electron beam to better fit the screen, this change is digital and done in software. Calibration forces Kodi to squee``ze e.g. 1920 x1080 pixels into 1900 x1060, with the remaining pixels to make up 1920 x 1080 rendered black. It's a lossy process and 'squeezing' the image can lead to other visual artefacts in playback.

No worries. We're just happy it's not an actual bug

If you have a repeatable way to recreate the issue please file a detailed bug/issue report on the Kodi GitHub repo.

Then nothing is probed and visible to the kernel; hence GUIDS cannot be found and boot failed.

Have a look in dmesg. If you want us to comment, copy/paste the entire log to pastebin.

It's a minimal environment so there's nothing other than what's needed to run the init script. See if blkid is there?

I've dropped the patch and pushed an updated 'box' image (and .tar) to my share. Can you test and confirm this (with the right dts file) then works the same as your own image?

Connect a USB keyboard when it drops to the initramfs debug shell and you can run console commands and poke around. Check the system log for error messages. See if you can manually mount the required boot/disk partitions and then run "boot" to continue. It has failed for a reason ..

Quote from birdybird

boot=UUID=1308-5505 disk=UUID=539ccadb-0a89-4cf5-92a9-d7e45e11fe1b quiet console=tty0,ssh

None of the other boot params are comma separated, and my instruction doesn't include one, so why have you added one?

HarryH might be an idea to PR a correction to the add-on decription that indicates it's not required on v5.

info <general>: CAddonMgr::FindAddons: visualization.fishbmc v21.0.2.2 installed
info <general>: CAddonMgr::FindAddons: visualization.goom v21.0.2.2 installed

You are running LE13 (K22) which uses OpenGL graphics but you still have LE12 (K21) visualization add-ons installed and these are compiled for OpenGLES. It's a wrong and probably crashy combination.

Force a repo refresh and make sure you're running 'Piers' versions of add-ons. AFAIK there should be v22 versions of everything.

Add ssh to the line

As you previously posted that the WP2 image worked on your U1 box I suggest you continue to use that. Or (better) go install the very old CE image again, and then this is the wrong forum for you to throw insults and demand support in.

Add "ssh" to boot params in cmdline.txt and the SSH daemon is forced to start on boot.

If the box has previously been used with CE images, recovery boot (toothpick etc.) MUST be re-invoked else vendor u-boot looks for the wrong filenames and LE images simply won't boot. So one possibility is that you haven't quite gotten the hold/release timing to invoke that correct yet. Some manufacturers tweak the timings so it can be a fiddly and failure-prone process.

The p281 or Tanix TX3 mini device-trees should boot the box as they're basically the same. The TX3 device-tree also describes the VFD display on the front so p281 would be recommended, but even if yours doesn't have a VFD display (or perhaps a differently wired one) that difference is harmless to boot. Other 'S905X' device-trees will likely boot the box too, but S905W would be preferred as the W chip runs slower so 'overclocking' can cause lock-ups.

You can also see if appending video=HDMI-A-1:1920x1080M@60D to boot params in uEnv.ini makes a difference? - This forces the initial HDMI state to 1080p in-case the box is trying to negotiate some other unsupported (sometimes 4K) mode with the TV.

The "box" image here: https://chewitt.libreelec.tv/testing/ has been boot tested on a TX3 mini in the last couple of days (due to upstreaming work on support for VFD displays) so I know the image is good. The codebase of the image is newer the LE11/12 images that you tried, but from a boot-files perspective nothing changed.

The only thing that's really useful in this scenario is the UART boot logs that show what the box actually did, but most users don't have a UART cable, and most cheaper Android STBs don't have the UART pins wired on the board, so normally we can only guess at problems

iperf3 --no-delay -c 192.168.1.10 --bind-dev eth0 --interval 0 --parallel 1 --time 30

Have you bound iperf3 to a specific interface? e.g. ^

Also, can you share the following:

- Original Android dts file

- Original Android boot log

- LE system log using the current AMLGX image from https://chewitt.libreelec.tv/testing/

Perhaps the add-on needs adjusting to the Python version that LE uses then? although LE12.0 is not 'current' or 'recent' now so I rather doubt that's the issue. Regardless, it's not our add-on or our code. Please report the issue to the add-on author(s).

It looks like something changed on the MLBTV side and the add-on needs changes to accomodate. It's best to report the issue (or check for info) on the add-on support thread in the Kodi forum.

I've no idea. Go download an old image and boot it to find out.