Posts by chewitt

tune2fs -L STORAGE /dev/mmcblk0p2

^ run that and it should boot normally again

The ability to compile on the target is fine for distro's like Armbian where you're only ever recompiling the kernel or building a couple of esoteric packages you need for a specific use-case. LibreELEC has ~380 packages and requires approx. 20GB disk space and 6GB RAM minimum to compile an RPi image. An educated guess based on CPU alone is 48 hours to compile an RPi image on an overclocked 3B+ and maybe 36 hours on an RK3399 board. In comparison the 7yr old quad-core i7 chip in my MacBook takes 3.5 hours if sources are pre-cached. That level of time difference guarantees only masochists would ever use the capability (project staff never would). It's a moot point though, because the average 2GB RAM limit on most ARM boards ensures you'd never get a successful build. Some of the packages that come later in the build sequence like *lots* of RAM.

@5chatten @The_Coolest I have some openvfd package changes prepared for mainline that need to be tested on the older image - I've set a legacy image build running and will look this evening - then will PR if all is good.

See driver: add openvfd package · chewitt/LibreELEC.tv@248185c · GitHub

caveat: the editable nodes are the square boxes at the top of the RHS content view (actors, titles, etc.). Creating a new line of thumbnails similar to "in progress" requires core code changes, so that's not possible from node editing.

Quote from Kwiboo

Building LibreELEC is mainly done on x86_64 hosts and not on the target devices.

I also think some of the rkbin tools used to generate bootloader/u-boot blobs only exists for x86_64.

^ building LibreELEC is *only* done x86_64 hosts

@Ae3NerdGod .. either tone down your behaviour towards others (quit ranting) or you are banned. Final warning.

You can install the Library node editor addon from the Kodi repo and define a custom node. I'll warn you that it's not the most simple thing to figure out and the best place to ask for help with that is the Kodi forums (where its creator and others more familiar with it hang out).

Presence of something in GitHub means someone booted one once, it does not equal official support (which is a term we want to eliminate to avoid appearances of endorsement for specifc vendors). In the near future we need to rework all the boot stuff so there's a single image for each SOC type and not 10+ device specific images. I'll mention the request to one of the CI team but it might have to wait until we simplify things, so no promises.

Kodi moved archive support to an addon some time ago so you need to install the binary addon for "archive support" (zip) or "rar archive support" (rar) from the LibreELEC binary addon repo; assuming whoever created the C1 image provides a repo for the image (as we have never officially supported the C1 so there's nothing in our repo).

Multichannel audio support needs an alsa plugin creating. It's on the to-do list, but it's a major piece of work so it makes more sense to do this on a mainline (modern) kernel codebase where it will also benefit Amlogic and Allwinner hardware instead of sinking the effort into the older (current) Rockchip 4.4 kernel codebase which we view as temporary and not a long-term solution.

TL/DR; better audio support will come, but not for a while yet.

Older EFI firmware mac's are crap at USB booting. It's easier to burn an Ubunto ISO to CDROM and boot from that, and do a manual install of LE to the internal drive. It's years since I did one, but basically you need to create a GPT partition scheme with two EXT4 partitions for boot and storage and then copy the files from the first partition of a "Generic" USB image to the first (boot) partition on the drive. Then install a bootloader (syslinux or grub) and possibly rEFInd as a boot manager.

Microsoft "Media Centre Edition" was a short lived version of some older Win release. Lots of manufacturers shipped "MCE" compatible remotes with their boxes and Harmony can replicate the standard remote. I can't give more specific instructions about configuring Harmony devices as I have never owned one (nor do I plan to get one).

I've no idea what triggers udev to match on nvidia-legacy rules (and why nvidia rules are evaluated separately and before other GPU rules is lost in the history of the project somewhere), but clearly it does match, so overriding the file should work and avoids anyone needing to learn new things about udev. It's either an exceptionally rare kernel/udev bug or there's something odd about your specific hardware. I'd guess the latter. It's not a scenario I recall seeing before and I've been hanging around various incarnations of the project since ~2011.

wget https://raw.githubusercontent.com/denilsonsa/udev-joystick-blacklist/master/51-these-are-not-joysticks-rm.rules -O /storage/.config/udev.d/51-these-are-not-joysticks-rm.rules
reboot

^ run those commands and see what happens. If nothing changes you need to find the USB device ID's with "lsusb" and crib the format to add them to the rules in the file (only one rule is needed, for your ID's).

untested file found in 10 seconds by searching Google with "51-these-are-not-joysticks-rm filetype:rules"

It's unlikely to be a LibreELEC specific issue so please report the issue to the Kore developer via their forum thread in the Kodi forums.

If the LE box has a wireless card that supports AP mode, enable the wireless hotspot and connect the phone to that instead of the mobile router. Or get a normal wireless router/bridge and connect to the Cable network. DO NOT CONNECT LibreELEC TO THE INTERNET.

Quote from noxx

i had installed CoreELEC-S912.arm-8.95.3.img on my H96 Pro+ with a Black Mainboard.

You're asking questions to the wrong forum then. We stopped supporting their stuff when they fcuked off to do their own thing and stopped contributing to our codebase (not necessarily a bad thing).