Posts by chewitt

I'm not sure how time could impact on Kodi starting or SSH login which is what your comments hint at. Not least because this is a box with an RTC chip so while time might not always/initially be accurate (ahead according to the boot log; the last line shows time being corrected) it shouldn't ever be so far off it causes problems, and a single working boot (Linux or Android should keep time current.

Can you run "journalctl | paste" and share the URL; this will mostly show the same log out but with timestamps.

I understand people still want to use WP2 boxes due to the DVB cards, but IMHO most users would be better off using them as a pure head-end (server) device and an RPi4 or RPi5 board as the client device as the software support is sooo much better.

The one other thing you can try is adding "textmode" to boot params. This boots the box to a text console (not Kodi) allowing you to poke around in the OS to look for problems using a USB keyboard. If the issue is still related to Kodi specifically it's not going to be seen (as Kodi isn't started) but... you might spot something.

Otherwise I've no idea what the issue could be. I've installed AMLGX images on a couple of things using the same batch of files in my testing share earlier today and they all run without any major issues.

To see more, we really need to see the systemd journal log and/or kodi.log to see what's causing the issue.

Package description fix PR https://github.com/LibreELEC/LibreELEC.tv/pull/8243

Both "dvbscan" and "w_scan" are included with the "DVB Tools" add-on in the LE repo. The description for the add-on only mentions w_scan but looking at the package sources we bundle everything in the dvb-apps package so the description needs fixing/updating:

LibreELEC.tv/packages/addons/tools/dvb-tools/package.mk at master · LibreELEC/LibreELEC.tv

Just enough OS for KODI. Contribute to LibreELEC/LibreELEC.tv development by creating an account on GitHub.

github.com

For the record, here's the same logs from my WP2 box (connected to a Marantz AVR > LG-B7V TV) which has no problem with EDID data, and thus we have confidence it's not a general software problem (there's also a moderate number of active WP2 installs).

dmesg: http://ix.io/4JK0

modetest: http://ix.io/4JJZ

IMHO if users want a NAS they're better off aiming for a lower-spec Synology box like DS223J which is purpose-built and easy to expand in the future to include a second drive for data redundancy. The cost difference vs. an RPi4 + PSU + Case really isn't so big and it'll be easier to use and maintain than a homebrew RPi device, and there's no rats-nest of cables and PSU's to deal with. If you do want to go down the RPi route look at OpenMediaVault or similar (NAS distro) unless you plan to use the other RPi for playback too.

Quote from konrul

But as you might know already, RPi4 does not support h264 very well.

I'll call phooey on that statement ^ .. RPi4 has no issues with any of the H264 media I've tested with.

What application or service provides the IPTV server?

Plug something else into the same HDMI socket on the TV (PC or other HTPC or .. something). Any issue? If no issue, perhaps the HDMI socket on the WP2 is damaged. These are old boxes now (8-years) and faults like dry solder joints start to show up among users.

Otherwise ..

The modetest output shows no EDID data. Either the TV doesn't advertise any, or there's a fault with the cable, or the box has a problem so it's not recieved. HDMI 1.4 cables will (or should) still pass EDID info.

Quote from belaid38

Did this affect my device? Did I lose any other licenses?

Ask someone who cares about Android (not me).

HDMI audio depends on EDID data. No EDID = No way for Linux to know what audio capabilities are supported. Fix the TV or Cable or Socket.

mount -o remount,rw /flash
cp /flash/uEnv.ini /flash/uEnv.original
sed -i 's/quiet/quiet video=HDMI-A-1:1920x1080M@60/g' /flash/uEnv.ini
mount -o remount,ro /flash
reboot

^ That should force output to 1080p@60 .. or you'll get a black screen maybe

Run "dmesg | paste" and "modetest | paste" first, and share the URLs.

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.