Posts by chewitt

Selling the laptop (eBay or local equivalent of..) and putting the earned funds towards a Raspberry Pi will avoid the forced learning excercise on compiling distro images (fun that it can be). An RPi3B+ or even a much older RPi2 will greatly outperform any 16-year old laptop and can still run current software.

[    3.682808] mmc0: tuning execution failed: -5
[    3.682820] mmc0: ddr50 tuning failed
[    3.682838] mmc0: new ultra high speed DDR50 SDHC card at address 0001
[    3.684028] mmcblk0: mmc0:0001 SD32G 29.1 GiB
[    6.330769] mmc0: tuning execution failed: -5
[    6.330793] mmc0: ddr50 tuning failed
[    6.332062] blk_update_request: I/O error, dev mmcblk0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[    6.332124] Buffer I/O error on dev mmcblk0, logical block 0, async page read
[    6.335152] blk_update_request: I/O error, dev mmcblk0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[    6.335165] Buffer I/O error on dev mmcblk0, logical block 0, async page read
[    6.335197] ldm_validate_partition_table(): Disk read failed.
[    6.337727] blk_update_request: I/O error, dev mmcblk0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[    6.337738] Buffer I/O error on dev mmcblk0, logical block 0, async page read
[    6.340279] blk_update_request: I/O error, dev mmcblk0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[    6.340290] Buffer I/O error on dev mmcblk0, logical block 0, async page read
[    6.340321]  mmcblk0: unable to read partition table
[    6.344660] blk_update_request: I/O error, dev mmcblk0, sector 61069184 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[    6.347382] blk_update_request: I/O error, dev mmcblk0, sector 61069184 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[    6.347397] Buffer I/O error on dev mmcblk0, logical block 7633648, async page read

^ To me it looks like a bad SD card, or perhaps a power issue making the board unstable, but that's unlikely if the older CE image runs fine.

The codebase of our master branch (tagged as LE11) is likely to be forked into an LE 10.2 release at some point .. depending on how long the wait for Kodi 20.0 is.

The version of Kodi in OE 5.0 (Helix?) is now too old to be useful for anything but playing local media; anything online is not going to run with the ancient packages in the image, and updating "a few" packages will cascade into compile dependencies; getting Kodi to run in the image is a choreographed dance that involves a lot of packages. For that reason lrusak comment is valid; it will be much easier to rework our current codebase (where all the packages have working sources that match the buildsystem) than resurrect OE 5.0.

Commits · chewitt/LibreELEC.tv · GitHub

^ This is a branch based on LE 7.0 which reverts the removal of i386 support in order to run LE 7.0 on a mk1 AppleTV. By now this branch will also be full of packages that are outdated with broken source URLs, but it at least gives you a clue on what was needed back in ~2017 (when I last built that branch). You want a subset of the changes; there are things for AppleTV (which has an old nVidia GPU) that you don't need.

NB: IIRC there's a thread in these forums from a user that created an i386 build for an Intel GPU with Kodi v17 .. and in the threat he links to GitHub sources. I'm being lazy to look .. but I did find it on GitHub in the past.

Quote from ChrisChris23

It seems this new version is not available in auto update

LE (and OE before) have *never* supported auto-update between Kodi major versions. It's available as a manual update, although if you are running LE 9.x please note that we strongly advise a clean install due to the Python2 > Python3 add-on changes in Kodi.

I'm not sure we bothered to create one, because it needs changes which I never got around to submitting before the release was cut. I'm not sure I will have time to do much in the next couple of weeks, but I will see if I can remeber to dig my Cubox-i out and test again.

NB: Right now there's not a huge difference between LE 10 and LE 11 nightlies (apart from the number) .. go see what happens.

C2 has issues with USB generally (even in the old vendor kernels) so YMMV with USB booting.

What GPU is in the laptop? .. this will be the main factor that limits your options with newer images (depending on what's inside)

Add "TimeoutSec=30" to the [mount] section and see if that works? .. i'm not sure what the defaults are.

If that doesn't work, the alternative would be to create a bash script with a working sequence of mount commands, then execute the script from a systemd .service file with right before/after dependencies for Kodi use.

Quote from blackride

Can I fix the dtb file?

In the old forum thread you found the user has a generic S912 image where you must configure the correct dtb file for the box to boot. In the LE10 C2 image I shared everything is correctly preconfigured so the dtb does not need "fixing" to work.

See if "boot=/dev/mmcblk0p1 disk=/dev/mmcblk0p2" work (edit the exlinux.conf). If not, I have no idea what the problem is.

blackride The bootloader is unable to find a partition with the label "LIBREELEC" to load the SYSTEM file. It has nothing to do with the device-tree being used. The LIBREELEC label is used with the FAT16/VFAT partition on the .img file we use for imaging SD cards and eMMC modules for the C2 board and the configuation is defined in extlinux.conf where we set boot=LABEL=LIBREELEC and disk=LABEL=STORAGE. If you have swapped between Olegs images (which used non-standard u-boot bootscripts and locations/naming sometimes) and mine or LE10 nightlies the extlinux.conf might be wrong (see if UUID or /dev/device works instead of LABEL). Sometimes sudden power-off without shutdown will result in card corruption; normally fixable with fsck. It's hard to comment without knowing the history of the device, e.g. what was originally installed, from where, and when, and what update was performed.

NB: I've run boot tests with LibreELEC-AMLGX.arm-10.0.0-odroid-c2.img.gz on SD card and an eMMC module and (from a boot/install/run perspectice) the image works fine for me.

It looks like a bug in our settings add-on. The workaround is to login via SSH and run "bluetoothctl" and pair the device from there; it's the same process just a different interface.

Quote from gadget_guy

If i lower resolution to 1080 than everything plays fine, but obviously defeats the purpose of buying a 4k TV!

Set the desktop to 1080p and then use the whitelist to facilitate 4K playback when it's needed. Your TV will do a better job of upscaling 1080p and 480p SD media to the native 4K panel resolution than Kodi (on an ARM SoC) will.

The feature request is: User saves bookmark in browser and this populates a link to the "favourites" list in Kodi, so in future user can click the favourite and go directly to the URL in Chrome. In the sense that "it's only code, everything is possible" .. it's possible. Back in the real-world I don't see anyone volunteering to code it though, especially since we plan to ditch X11 which kills the current add-on.

The command output shows you not following instructions

You've noticed the "u" option in emmctool, which writes u-boot to the 1st and 512th sectors on the emmc storage. If you stopped at this point it would have worked. Then you "w" the LE image to emmc which overwrites it with an image containing MBR structures in the 1st sector and u-boot in the 512th sector. This would work on GXL and newer devices which check the 512th sector on emmc, but not a GXBB device which only checks 1st sector. Then finally you dd u-boot directly to emmc again which puts it in the first sector again.

The image has some audio issues. I'm unable to get 48KHz media to output unless I force Kodi to resample it to 44.1HKz. I don't see this on GXL/GXM devices using the same image. There is also a "machine gun noise" buffer underrun which occurs. You'll know it when it happens because your ears will bleed - You need to toggle the audio source in Kodi to fix it. In both cases I have no clue where the problem resides - and I'm not really a coding developer with the skills to investigate.

I don't do the beers thing. The project accepts paypal and open-collective donations though.

Three suggestions - in order of best to least-best:

a) Switch to Ethernet

b) Switch to Ethernet connection to a wireless bridge

c) Fix the network so it doesn't have dropouts (harder than it sounds sometimes)

In B .. because the Ethernet link to the bridge device remains up at all times you don't see a dropout which results in the connman 'teardown' that you see when the link is lost on the wireless connection.

Start a thread, provide debug logs.

One's a scheduled nightly. One's probably a test build someone spun for something.