Posts by chewitt

You can use meson-gxl-s905l-p271.dtb to boot the AMLGX image: https://wiki.libreelec.tv/hardware/amlogic

N2PLUS:~ # mv box.dtb box.dump
N2PLUS:~ # dd if=box.dump of=box.dtb bs=1 skip=2048
N2PLUS:~ # dtc -I dtb -O dts -o box.dts box.dtb

After renaming the file, carving out the dtb, then decompiling the dtb: https://paste.libreelec.tv/amazing-oyster.log

This shows the box is an S905L (p271) board, which is a cost-reduced version of S905W for the Chinese market. It omits VP9 support and uses a Mali 450-MP2 GPU instead of the Mali 450-MP3 used with S905W/X boards. You MUST boot using the p271 dtb file. If you boot with any dtb that describes a Mali 450-MP3 the kernel hard-faults and boot fails.

Computeraar If the problem is "Kodi won't start" a textmode boot log isn't going to show anything useful because Kodi isn't being started. Create /storage/.kodi/userdata/advancedsettings.xml with this content to put Kodi in debug mode:

<?xml version="1.0" encoding="utf-8" ?>
<advancedsettings version="1.0">
  <loglevel hide="false">1</loglevel>
</advancedsettings>

• Then touch /storage/.config/safemode.disable to ensure that safe.mode doesn't kick in
• Then tail -F /storage/.kodi/temp/kodi.log > log_dump with capital F and tail will wait/watch for the file appearing
• Then systemctl start kodi and allow it to fail a couple of times before stopping the service
• Then cat log_dump | paste and share the URL
• Then systemctl | paste and share the URL

If we're lucky the logs might have some clues on what the problem is ..

FATAL ERROR: Blob has incorrect magic number

NB: the dump/blob shared is not a dtb ^ (cannot be decompiled) so you'll need to use a tool like binwalk to figure out the offset to where the dtb data is located in the file, and then carve it out using dd.

NB: with the second one, leave video=HDMI-A-1:1280x720M@60D in kernel boot params as the board is going to see a monitor that can do at least 1080p output and Kodi will want to run at 1080p.

Quote from Protx

Armbian have a dts file/patch for their "edge" 6.18 kernel

From the amount of /delete-node/ and /*commented*/ items in the file I'd guess it either forward-ports a device-tree file that was originally written for the vendor kernel or is a hand-rolled attempt from an inexperienced developer. It probably works(ish) but six months has elapsed since it was created so (as normal for Armbian patches) the author clearly has no intention of trying to submit support for the board upstream, and that's probably because this dts is too much of a hatchet job to be accepted.

https://github.com/armbian/build/pull/8348 <= The "VPU (Unable to test due to lack of VAAPI support)" comment is amusing

The Armbian PR also confirms the board needs an out-of-tree Ethernet driver to work. For both board and Ethernet support I'll be happy to cherry-pick patches submitted to kernel mailing lists, or items from known kernel contributors (who are trusted to follow-through on upstreaming them) but that's my minimum threshold.

NB: The LE13 nightly image will have an audio issue (will be fixed over the next few days) but that doesn't affect iwlwifi ..

The log contains a prominent kernel splat from the iwlwifi driver and Google (re)searching on that throws up a large number of bug reports from a large number of distros over a long period of time. I didn't find anyone really getting to the bottom of things but the recurring theme is "PCI issues" and some users report success when disabling some features of the kernel driver.

I'd suggest updating to the latest BIOS/firmware for the board then retesting with an LE13 nightly dating from tomorrow (as this will have the Linux 6.18 kernel update merged earlier today).

If that doesn't magically solve anything, something like this might be needed https://www.edu4rdshl.dev/posts/fixing-i…ashes-on-linux/

Two things to try:

a) Run "getedid delete" then add video=HDMI-A-1:1280x720M@60D to kernel boot params and use the HDMI port nearest to the PSU connector. This forces the initial kernel DRM state of the connector to 720p output which sometimes resolves handshaking issues.

b) Run "getedid delete" (to remove the possibly bad van EDID) and connect to the working monitor and run "getedid create" then power up with it connected to the van and see if anything shows up on the display?

Quote from ghusto

Libreelec is not an embedded system, and "we" can take advantage of that fact

I've quoted the "we" for emphasis ^

Kodi devs made a serious proof-of-concept for a Kodi-internal browser 3-4 years ago. This proved that it was a non-trivial feature to bring to Kodi. The prototyping showed a mountain of platform-specific code was needed (Kodi supports 6+ platforms) and it would also need frequent updates to manage the inherent security issues of a browser; the underlying browser engine (Chromium) is in a state of constant change for the same reason. The team concluded that adding a browser is technically possible, and we all see the value of having one, particularly to ease the challenge of accessing streaming platforms. However the overall level of effort required to implement and then maintain an in-Kodi browser doesn't align with how Kodi is [under]staffed since forever or the anarchic way the project operates itself.

Quote from ghusto

I feel a lot of hostility towards actual users when they have reasonable requests like this.

I'm normally aiming for sarcasm more than hostility, but "we" get bored of new users showing up and expecting us to treat their reasonable suggestion differently to all the previous times the same reasonable suggestion was already reasonably answered.

Please update to an LE13 'Generic' (not Generic-Legacy) nightly and see if that works better?

DVB support in the 3.14 vendor kernel generally requires an image that targets a specific box/device. There are quite a few different tuner/demod component combinations in circulation and device-tree describes most (but not all) of the required hardware variables used in drivers, so the individual drivers for a particular manufacturer are hacked to compile a working monolithic dvb-frontend that only works for that box. afl1 made a start on abstracting the missing device-tree bits to untangle code mess, but he went radio-silent one weekend (and has never been heard of since) so the effort stalled and nobody else ever picked up the challenge. The 4.9 kernel codebase is largely a forward-port of the same bad code used in 3.14 (which is a forward-port from 3.10) but newer hardware from that era tends to copy the Amlogic reference designs closely so less variation of tuner/demod combinations and a small amount of code improvement results in a single (still hacked-together) image working for a wider range of no-name boxes.

TL/DR; You likely need the original kernel sources for the box(es) to make a working image because the device-tree files on their own only contain part of the detail needed to make the hardware (as implemented in that box) work properly.

rdorsch slideshows are probably using shaders which might have a connection to e.g. the mesa version, but in general it sounds like something that needs to be investigated from the Kodi side; especially with Piers technically still in a pre-alpha state. It's worth seeing if the feature works on another distro or platform.

Attach a keyboard and press 'i' when this is playing and it should go away, and then only reappear (briefly) when the track changes.

It sounds like the core OS boots and runs fine but something fails/faults with Xorg so the Kodi home screen doesn't show and then Kodi is restarted (ad infinitum).

If you have an AMD GPU the first thing I would do is reinstall with the Generic (not Generic-Legacy) image. I would also use a current LE13 nightly to have the latest drivers (not that this guarantees anything). If the Generic image does something similar, e.g. the boot splash shows but the Kodi home screen then doesn't overwrite it, you can access the 'Logfiles' Samba share over Ethernet and either upload the zip file or (better) pastebin the system and kodi logs so we can maybe see what went wrong.

Quote from vbs

isn't what you describe (ignore dynamic metadata and use the static metadata) already happening right now?

Yup. Current LE images are using ffmpeg 7.1 and 8.1 is queued up for LE13 nightlies. What you described as some future thing we need to add .. is something we've been doing for ages already.

The upstream Motorcomm driver is enabled in RK images but code shows "Motorcomm 8511/8521/8531/8531S/8821 PHY driver." so I would assume it doesn't support YT6801 and something downstream will be needed. The challenge here is that a) downstream drivers are normally written for old Android kernels and are garbage quality, b) in the last year LE finally exorcised the last out-of-tree vendor driver from our codebase, and that effort took a decade, so we aren't going to enthusiastically add/allow more of them back into the codebase again. I'll entertain the idea of backporting submissions to kernel mailing lists that show promise of being merged (and thus patches can be dropped in a future kernel bump) but out of tree things are a firm no these days.

There's plentiful information on how to build custom images in the wiki. Learn how to search for driver names using "git grep" to discover references to them in packages and config files within the codebase.