Posts by chewitt

Add "ssh" to boot params so the daemon is forced to start and then you can SSH into the box to look at (and share) dmesg and Kodi logs. The box doesn't hang at the boot splash, it's simply never overwritten with Kodi so remains visible.

It's possible for bad cards to cause problems, but since the entire OS (kernel and userspace) are essentially in two compressed files; if the card media is damaged it generally results in nothing booting (not partial boot). If you have a spare card you're welcome to try another, and also experiment with https://chewitt.libreelec.tv/testing/LibreE…80.0-box.img.gz (LE12).

Upstream kernels rely on EDID data on the HDMI connection to determine the resolutions available. So one of the following applies:

a) TV has bad EDID data

b) TV has bad HDMI sockets

b) HDMI cable has a problem

c) WP2 box has an HDMI hardware problem

The AMLGX image shows 1080p/4K resolutions fine on my WP2 box so I'm confident there's no software problem. You can try forcing the kernel DRM layer to output at 1080p with "video=HDMI-A-1:1920x1080M@60" in kernel boot params, but that's not a proper solution since you'll be forced to play everything at 60Hz (which doesn't give great results).

To prove whether the box, TV, or cables are at fault .. connect it to another TV, use a different socket, HDMI cable, etc.

NB: If the TV shows "DVI" I'd start with using a different HDMI socket.

Quote from limmes

So you're saying that for 4K video with resolution out of list above screen resolution will always be set to 1920x1080 ?

No, he's saying READ THE LINKED WIKI ARTICLE that explains how things work and how to configure Kodi.

Assuming H618 is a derivative of H616 (which is a reasonable assumption) the upstream kernel and u-boot need to gain support for the SoC before we can think about creating LE images for the board. Something can probably be done with downstream vendor sources, but that's for the Sunxi community to do; we have low/no interest in working with vendor sources.

In the non-RPi world (Allwinner, Amlogic, Rockchip) the boards that need active cooling dut to SoC chips that run hotter tend to have thermal properties in device-tree which allows the kernal to control a pwm fan automatically; there are simple thermal ramps/steps or simple on/off mechanisms. In the RPi world things are generally done from userspace "because it's more tinker friendly" but IMHO it would be better for a case vendor like Argon to push a device-tree overlay into the RPi kernel sources (which are more receptive to such things than true upstream) so that users can enable similar thermal support at kernel level in the same way HAT devices are enabled. Then any distro being used by e.g. an Argon case user has nothing to do in userspace and it's a one-line cmdline.txt change kernel side. NB: The latest RPiOS (Bookworm) release is deprecating lots of hackier GPIO libs/methods in favour of upstream tooling that follows upstream standards. It will take a while for those changes to ripple through the Pi ecosystem, but it's some long-overdue spring cleaning that will help rationalise the number of ways things can be done from userspace and lead to better documentation and consistency. Of course, in forums you'll mostly just see users bitching that various tools have been thrown under the bus. Progress always entails ruffling a few feathers.

To return to your request: it's one of those topics where the idea is simple but the technical implementation is far-from; due to the myriad of ways that box and board manufacturers 'could' implement fan support from userspace. The only consistent thing is, there's no consitency on how it's done. Thus creating a universal "simple" fan control app for LE is a mountain of work, and that's probably why nobody has ever leapt at the chance to create one. LE is staffed entirely by volunteers, and that means people inherently work on the fun things they enjoy or use themselves. AFAIK nobody on staff uses an Argon case, so there isn't much interest among staff to own support for those boxes. And that's another reason why the best people to implement a simple add-on for Argon cases is .. Argon.

I'm going to stop/lock this thread on the simple principle that all forum threads I've ever seen that claim to list supported and unsupported hardware are instantly out of date and rarely maintained by the original user-with-grudge over time; thus ensuring the thread hangs around giving outdated bad advice to users for the rest of time. It's better to not have those threads and force people to ask fresh questions and get current answers.

NB: Argon cases aren't particularly loved by the staff here as a result of the number of support issues we've seen, but users showing up with problems is the inherent purpose of a support forum; so our perspective is likely biased. Argon seem to sell their cases in large volumes so plenty of other users presumably aren't seeing issues and are happy with their purchases. And I have no idea what a "Desktop Pro" is, so I rather doubt that information is much use to anyone else either.

systemctl stop kodi
mv /storage/.kodi /storage/.kodi-old
mkdir -p /storage/.kodi
cp -R /mnt/oldcard/STORAGE/.kodi/userdata /storage/.kodi/
systemctl start kodi

^ that will deliberately not import add-ons (which will need to be updated) but does get all their settings and any other userdata config so anything you've configured should restart using the pre-existing configuration. Databases will be updated on first restart, assuming they aren't corrupted (which is a possibility). If a file is corrupted and Kodi hangs you can "tail -f /storage/.kodi/temp/kodi.log" and see which DB file things hang on, then stop kodi, delete the offending DB file and then restart Kodi again and if there's an older/earlier DB file it will attempt to import that one instead. Art content like thumbs is best left to download again as the resulting cache is smaller and more efficient.

ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", RUN+="/usr/sbin/hdparm -B 63 -S 36 /dev/%k"

Put that ^ in /storage/.config/udev.rules.d/62-hdparm.rules and reboot to see if it improves things? NB: The -B value is power management aggressiveness between 0 (disabled) and 127 so we're setting it half-way, and the -S value is the power-down delay in multiples of 5 seconds, e.g. 36 = 5 mins.

I'd have a look for updated BIOS/firmware for the box, and perhaps think about running "getedid create" once the HDMI connection is up and working as this will force the kernel DRM subsystem to see the TV as connected all the time (even if it's not) which might help with HDMI stability (or it might not). I'd also think about trying other HDMI ports on the TV if it has some?. Also note that Kodi only outputs progressive so even if 1080i resolutions in EDID data they aren't usable. If you need to play interlaced material: enable adjust-refresh with the mode whitelist configured for 1080p @ 60/59.94/50/24/23.976 and enable refresh rate doubling so 25Hz material plays at 50Hz. With interlaced media this allows Kodi to render each interlaced half-frame in its own progressive single-frame.

Quote from HiassofT

a manual "cross grade" on RPi4 (copy RPi5 tar/img.gz to the /storage/.update folder and also create a ".nocompat" file there, then reboot to install it) should work fine.

Note that this ^ is a one-way upgrade as the RPi5 kernel that LE is using will not boot an RPi4. It's not impossible to recover from (mount and overwrite some files with the RPi4 image equivalents) but .. that's fiddly.

Go read post #7 again

It's hard to know what the issue is without seeing proper system or Kodi logs, but most likely something has gotten corrupted on the SD card. In that situation I'd recommend starting out with a clean install with LE11 (or an LE12 nightly) using a fresh SD card. This should get you back to a working (if not configured) system. From there you can connect the borked SD card using a USB > SD card adapter and see if the /storage partition on the card mounts to /mnt/<cardname>/storage or similar. If it does, restoring the general state of the previous setup is relatively simple and acheived by stopping Kodi, copying old userdata (database files, sources config and add-on settings) to the relevant location on the new card, starting Kodi up again, and (re)installing the add-ons that you were using. If you're familiar with some basic Linux fileystem and copy commands it's probably 5-10mins work to recover things. If you're not, it takes longer. If the old card fails to show up, then we need to see the system log to see what error messages are being generated. In that scenario it's probable that basic filesystem checks aren't going to get the card mounted and more complicated recovery processes might be required .. in which case "sorry, but now you understand the need for backups in the future!" is likely where we'll take a pause.

RPi4 on LE 9.2 has a 64-bit kernel and 32-bit userspace so that's not the problem or the solution. I'd suggest starting with an update to LE 11 or an LE 12 nightly to avoid all the issues found/fixed since the last LE 9.2 release (around two years ago).

I'm not sure if that's an error about finding libpcloudcc_lib.so or libpcloudcc_lib.so is dynamically linked against other things which are missing and thus it fails to open the file which it found. There's no harm in experimenting with LD_LIBRARY_PATH so give it a try. You can also share the output from "ldd /storage/backup/libpcloudcc_lib.so" to see whether it's linked against anything missing.

Have you tried copying the existing binary over to /storage and see if it runs?

Quote from aptalca

I just need confirmation from someone with an rpi and LE 11 so we can make sure it's not specific to amlogic.

All my things are updated to LE12/aarch64 so not volunteering to test .. but there's nothing special about the AMLGX image; it's functionally the same as RPi4 and other SoCs like Allwinner.

Quadro P400 (2017) is not the same as Quadro 400 (2011)

There are several reasons:

a) Kodi no longer supports OMXplayer and MMAL decoding as part of the general move to drop all proprietary codecs to focus on modern kernel standards (GBM/V4L2).

b) The Pi graphics pipeline in the newer kernel used by LE10 has been rewritten around modern kernel standards (GBM/V4L2) so "assisted" decoding would need to be reimplemented from scratch in both kernel and ffmpeg. The original patches amount to 100,000 lines of code and authoring that (and then maintaining is downstream) is a large effort.

c) Only a couple of distros (mainly LE and OSMC) have been daft enough to allow 100,000 LOC patches into their codebases so the audience that would benefit from a large reimplementation effort in 'B' is small.

d) RPi4 and up support hardware HEVC decoding (although to be clear, forcing hardware upgrades on users has never been a goal). It does mean over time the issues reduces in size along with the RPi2/3 user population.

e) Nobody is forcing users to update from LE9.2 which continues to have the feature.