Posts by chewitt

I'd guess there is an issue with the kernel DRM driver or perhaps the device-tree needs adjusting to reflect changes in the driver. I built the 10.88.0 image to keep the codebase sort-of updated but I never booted it on anything so there are probably bugs. It really needs someone with a bigger interest in Meson8 hardware (and who has some boxes) to report issues to Martin Blumenstingl and work through the testing with him. Martin is super helpful but in the absence of regular user feedback he tends to focus on other projects.

Legacy images use different boot-scripts and boot files to the AMLGX image so you MUST invoke recovery mode boot so the vendor u-boot searches for aand finds/loads/stores updated boot-scripts that tell it what files to use. If this is not done u-boot is looking for boot files that don't exist and .. it isn't going to boot. Similarly if you have been running AMLGX and want to revert to the legacy image you need to do the same else u-boot is looking for the AMLGX boot files and won't find/use the legacy ones.

I'm not completely against having an Argon add-on in our repo, but IMHO the better approach would be for Argon to host their own repo so they can maintain the add-on and push updates to their users from a central location.

Since LE11 we use the exFAT drivers in the kernel (no more need for FUSE) but you'll need to share the URL from "dmesg | paste" with the drive connected for anyone to comment.

LibreComputer are funding someone to work on the HEVC driver (which does HEVC, VP9 and H264 on newer hardware) but we have recently learned that developer's approach/effort for the last three months has ended in a dead-end; which is both annoying and rather predictable since they didn't share their WIP code with people who'd have pointed out the wrong move earlier. Hopefully in the mid-term future there is something to share as the rest of the codebase is quite usable.

RPi4 isn't the higest-spec board, but everything on it works and the ongoing software support we receive from Raspberry Pi is the gold-standard that all other SoC vendors fail to achieve. Now that supplies seem to be resolved, it's worth considering. Or you can stick with the CE image; it might be cluttered and over-tweaked in places, but if it works..

You probably need to share a Kodi debug log for anyone to comment on what might be happening. As someone using an RPi4 for the family daily driver and with all media stored on a Synology NAS accessed over SMB .. I can state that don't see large delays in playback start (it's near instant) so it's something odd and specific to your environment.

RPi4:~ # cat /storage/.kodi/userdata/passwords.xml 
<passwords>
    <path>
        <from pathversion="1">smb://NAS/MEDIA</from>
        <to pathversion="1">smb://username:password@NAS/MEDIA</to>
    </path>
</passwords>

^ The authentication process has evolved and you probably need to create a file like that so that older library references that don't include the authentication data are mapped to include it.

video=DSI-1:800x480@60,rotate=180

^ I believe this needs to be appended to boot params in cmdline.txt so it impacts the kernel driver (the new way) not config.txt which controls pi firmware (the old way). Many pi firmware commands are deprecated with the move to the kernel DRM graphics pipeline.

I can't remember the last time that I booted a Cubox-i board (almost certainly not this year) .. so I doubt anything changed.

One of the Kodi mirror servers is borked. It's being worked on, but no ETA.

RPi4 will be a nice increase from the Slice CM1 (RPi1) or CM3 (RPi3) performance. It will be easier to do a clean install at the latest version and then selectively import bits of old config as needed. Kodi often benefits from the clean(er) start or spring-cleaning.

GXBB:BL1:08dafd:0a8993;FEAT:EDFD718C;POC:3;RCY:0;EMMC:0;READ:0;CHK:F3;SD:800;USB:8;LOOP:1

^ This is good, it means eMMC is fully erased (and the board is not bricked, it's simply missing software). You can now boot the board from an SD card .. as long as the SD card has a working u-boot in the correct places. The LE "hub" board image has everything needed although the catch22 will be that you're likely to hit the same problem with serial UART noise. Perhaps try writing the factory image backup written to SD and see if that's found (it might not be since it's an eMMC backup and S905 puts magic boot headers in different offsets for eMMC and SD) but even if it fails at booting into Android it might get you to a recovery console or perhaps the vendor u-boot console.

If the AMLGX image works for you, that's great. If it doesn't work for you, don't expect anything to change. I've done zero work on Amlogic hardware since April and have no plan to change that until someone shows up with new hardware decode drivers. Comparisons with CE are irrelevant due to 100% of the media driver code being different.

Uncompression can fail due to random Windows crappiness and lack of space on the /storage partition. Otherwise there is no need to unpack the file. Issues with copying files around are avoided by doing what I suggested: SSH into the box and wget (download) the file directly into the update folder. See https://wiki.libreelec.tv/support/update

Quote from jopereira

Is this to be expected at this stage? Where can I find a "known bugs" list?

Maybe, it all depends on the media being played .. and in the release notes that I write and nobody reads.

Read: https://kodi.wiki/view/Scrapers

You need to connect a USB > serial UART cable to the board. If you don't have one they are dirt cheap from Amazon.

https://wiki.odroid.com/odroid-c2/application_note/gpio/uart <= where to connect the cable board side. You also need a 'serial' app for your normal desktop/laptop computer OS .. there are lots of videos on YouTube for that.

The output will show whether the board boots at all, or boots and gets stuck somewhere.