Posts by chewitt

  • nightlies for trn9 box

    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.

  • feedback for test build LibreELEC-RK3328

    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.

  • [x86-64] Help installing on Mac Mini (mid 2011)

    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.

  • Play Pause Question

    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).

  • xorg issue x86_64

    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.

  • (First Post) Help Getting Remote Control Working RPI3

    Code
    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"

  • Remote power trouble

    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).

  • Play Pause Question

    The default Kodi keymap uses the enter key in keymaps.xml so that you press enter while highlighting a movie to play, and during a movie if you press enter the OSD comes up with play/pause pre-selected so pressing enter pauses, pressing enter again unpauses.

    I'd set the harmony to be a normal MCE remote and it should "just work" with a standard-ish LE image using meson-ir that understands MCE command, or worst case you can create a custom keymap on the LE side that understands all the harmony keypresses. You won't be able to teach the harmony play/pause without something that sends play/pause.

  • xorg issue x86_64

    ^ the systemd journal clearly shows that udev detects an nVidia card so xorg-configure for nvidia-legacy is invoked according to:

    LibreELEC.tv/96-nvidia.rules at a8b6f4c35dec2a4efb59ba1257f5ec36f4fdcc0d · chewitt/LibreELEC.tv · GitHub

    So create /storage/.config/udev.d/96-nvidia.rules with the content below and then reboot and the updated rule file (which if present overrules the embedded one) should prevent the nvidia card from triggering the xorg-configure process:

    Code
    ACTION!="add|change", GOTO="end_video"
SUBSYSTEM=="pci", ATTR{class}=="0x030000", ATTRS{vendor}=="0x10de", GOTO="subsystem_pci"
GOTO="end_video"

LABEL="subsystem_pci"
GOTO="end_video"

LABEL="end_video"

    The next rule to be evaluated is 97-xorg.rules which should now match against the AMD card:

    LibreELEC.tv/97-xorg.rules at amlogic · chewitt/LibreELEC.tv · GitHub

    In theory..