Posts by chewitt

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.

Yup, my WP2 image: LibreELEC-AMLGX.arm-10.0.0-wetek-play2.img.gz which has the magic header in the 512th sector of the image, so if you write the image to an SD card using something like etcher it should boot (mainline u-boot) on the box.

There are two issues:

a) I'm still jetlagged and a bit distracted after vacation, which means I forgot something rather important

b) You've erased u-boot

GXL (S905X) and newer boxes look for a magic boot header in the 1st sector of emmc or 512th sector of emmc or SD or USB, but older GXBB boxes like WP2 only look for it in the 1st sector of emmc (or 512th sector of SD or USB). The problem is, the first sector is also where the MBR partitioning data lives, so you have the choice of partitions and no-boot, or boot and no-paritions. Amlogic "vendor" u-boot implements a custom offset-MBR partition scheme to workaround the design mistake (which is corrected from GXL onwards).

If you connect the UART cable (WeTek did ship them with the box) you'll see it endlessly looping with something like:

"GXBB:BL1:08dafd:0a8993;FEAT:EDFC318C;POC:3;RCY:0;EMMC:800;NAND:81;SD:0;READ:0;CHK:0;"

It's not bricked. It simply means it cannot find the magic boot header. The normal way out of this is to write the "wetek-play2" image to an SD card and leave it connected. It will then boot from SD and you can tweak things to store data on emmc if desired. In your case the SD slot will not permanently latch/retain the card, but you'll need to figure out a temporary way to hold/fix the card in for long enough to boot from SD and perform some remedial steps. I would start by zero'ing the emmc (the z option in emmctool) and then "dd" u-boot.bin.sd.bin-wetek-play2 directly to /dev/mmcblk1 (no offsets, seeks, etc.). This will put mainline u-boot and the magic boot header in the 1st sector, so the box will boot from emmc, and u-boot should find the "wetek-play2" image on a connected USB stick.

The alternative is putting the original vendor image back by writing Dropbox - backup-wp2.img.gz - Simplify your life directly to /dev/mmcblk1 and then rebooting. This is a raw backup of my box taken a couple of years ago .. but should work.

Apologies again .. I'd completely forgotten that GXBB has the extra hoop to jump through.

Please explain in technical detail how you have diagnosed the problem. I'm not disputing PMF might be involved, but we need to discern facts from enthusiastic opinions and hunches before we attempt to engage upstream Engineers.

Quote from Pindarm

Installed v. 10.0.0 on my Rpi4, but no sign of HDR playback. Did I misunderstand something? Can this version play HDR files?

HDR works fine here for 6+ months now so if you're having problems, it's a Layer-8/PEBKAC issue.

WP2:~ # modetest | grep connected
31    0    connected    composite-1        0x0        2    32
34    33    connected    HDMI-A-1           1600x900        27    33

^ from an Amlogic device .. "composite-1" is present. Allwinner also uses the kernel DRM framework so something similar should output. The Amlogic section in the wiki is not relevant (old kernels).

See if this commit works for playback ffmpeg: use JC branch (at working commit) for testing · chewitt/LibreELEC.tv@4325503 · GitHub (will need you to build your own image).

Backup only supports local storage. If you want to write to a remote share, setup a systemd kernel mount to locally mount the remote share, then write the backup to the "local" folder.

I think jernej has something in his Allwinner images for flashing things to emmc, but "emmctool" only exists in my Amlogic images; hence you cannot find it to use.

cd /storage
wget https://chewitt.libreelec.tv/testing/LibreELEC-AMLGX.arm-10.0.0-wetek-play2.img.gz
emmctool w LibreELEC-AMLGX.arm-10.0.0-wetek-play2.img.gz

^ that downloads the file, writes it to emmc, expands the storage partition, changes disk labels, then sets extlinux.conf to boot from the new disk labels (so SD boot still works).

I doubt the audience in this forum will have an opinion on Android support (not our focus). You'd be better off asking in the Radxa forum.

jock2 I'm not aware of any guides for writing wireless drivers, but I'm not sure anyone could do a worse job than the original