Posts by chewitt

As per the wiki article, you need to invoke recovery mode boot on the box (toothpick method or similar) to ensure it looks for LE boot files not CE ones. If that's not the issue, we'd need to see UART logs of early boot to see where things go wrong.

Have you installed an online subtitles (source) add-on?

FLAC

run "dmesg | paste" and share the URL .. WiFi should work on most devices depending on what chip is inside.

no issues with copy/paste here (on macOS)

Second boot from a hung board requires power cycling so it's technically no different from the first boot. The gibberish looks like a buffering issue to me, i.e. rubbish drivers for whatever USB UART cable. Using Windows? .. If using macOS the "Serial" app is the one to use (non-free, but worth it).

The only time I've seen boards boot and get stuck here is on some (but not all) WeTek Hub boards. The current suspicion with them is that noise on the UART connection (perhaps related to dry solder joints) is interpreted by u-boot as keyboard input and thus it drops to the console (although then the console must have some other issue to not be accessible).

I'm going to create a one-off image with the u-boot console compiled out or compile differently to see if that allows the device to boot. That might take a day or two to get around to, but I'll post a link when done.

CE should detect the installed image as "S912.arm" and image to update to as "AMLGX.aarch64" and since they do not match (and you have not manually overriden the update check) the update process should fail with an error message on screen, before erasing the (incorrect) update file and rebooting.

If you manually start trying to rename files on SD cards then it's possible to break stuff in other ingenious/exciting ways

Interesting, it's stopped at the u-boot console prompt. Are you able to run commands at the prompt, or has it locked up?

The better advice would have been to update to an LE12 nightly that has the same fix included. You are now on LE13 so while Kodi database file are currently same-version (we haven't bumped to Kodi P in master branch yet) the LE and Kodi-binary add-ons are numerically bumped to LE13 and will need to be removed and reinstalled if you want to downgrade to the next stable LE release (12.0.1) when it arrives. Note that removal/reinstall doesn't mean you lose settings.

Yes, that process.

The old methods require OMXplayer/MMAL decoding and these were removed from Kodi (c.2018) in a purge of vendor proprietary decoding methods as Kodi moved forwards with open standards (GBM/V4L2, VAAPI, VDPAU). RPi devs have reimplemented the video pipeline for older RPi0/1/2/3 boards using GBM/V4L2, but the end goal of that effort was to upstream all their kernel driver code instead of hoarding ever-more in the downstream RPi kernel fork. The CPU+GPU approach, while clever, was always a big hack that would never be allowed upstream, and as it would be architecturally hard to reimplement (rewriting from scratch) under GBM/V4L2 the work has never been done. Around the same time RPi4 also launched bringing native HEVC decoding. There was no intent from RPi devs to "drive RPi4 upgrades" by not reimplementing the CPU+GPU approach, but it did reduce the need.

Having never used PINN, I can't really say whether downgrades are possible, but going back to 9.2.8 (or I think 9.2.6 for RPi3 as 9.2.8 was a respin solely for RPi4 support) is a big jump, so best to reimage and start over clean.

Read: https://wiki.libreelec.tv/hardware/amlogic .. it will probably boot with the Q201 device-tree.

The meson-gxm-q200.dtb device-tree should work, assuming the boot loop isn't caused by flashing the wrong ROM to the device resulting in broken u-boot (can only be diagnosed with a UART cable attached to show what u-boot is doing .. or not).

Also read this first as the boot process changed: https://wiki.libreelec.tv/hardware/amlogic

Two probable scenarios:

a) You're using an under-spec PSU (something less than 5V/3A) and this causes power/stability issues.

b) The SD card has gone terminal and needs replacing.

I'd image another card and see how that works first, before thinking about anything else.

RPi3B+ supports H264 hardware decode. It does not support HEVC hardare decode. Older LE releases (up to LE 9.2) have patches to share the decoding effort between CPU and GPU to improve HEVC decoding. It is normally possible to play low-bitrate 1080p files.

After LE10 the RPi3B is using a newer GBM/V4L2 display pipeline and this does not support the CPU+GPU decoding method. The board can still software decode HEVC, but without the GPU offload the maximum resolution is reduced to SD and 720p media.

Your options are:

a) Use handbrake/ffmpeg to re-encode files from HEVC to H264 ($0).

b) Use handbrake/ffmpeg to re-encode files to SD or 720p ($0).

c) Use an older LE 9.2.8 release ($0).

d) Change the RPi3 for something that supports native HEVC decode, e.g. RPi4, or RPi5 ($$).

As Linux does not support HDR10+ or Dolby Vision, your choicees for Kodi are an AppleTV or an nVidia Shield, and further discussion is best done in the Kodi forums as neither of those devices are supported here.

LE 9.2.8 is the last image to support "display_rotate" in config.txt, but this will not boot on current RPi5 hardware (only the original boards) as newer hardware requires newer firmware. This is not impossible to solve, but LE 9.2.8 is starting to look old now and most RPi5 boards won't boot LE 9.2.8 without some effort. LE 10/11/12 use a completely different display pipeline which does not currently support display rotation.

Quote from lordairivis

I have noticed that it happens when Radarr or Sonarr attempts to run a library update after a new file is downloaded.

I'll remind you of forum rules, and wish you good luck in finding someone to help you (in some other forum).