systemctl mask is essentially the same as symlinking a unit to /dev/null
LibreELEC stores the systemd user configuration in /storage/.config/system.d instead of /etc/systemd/system - therefore there's nothing in the (read only) /etc
so long,
Hias
systemctl mask is essentially the same as symlinking a unit to /dev/null
LibreELEC stores the systemd user configuration in /storage/.config/system.d instead of /etc/systemd/system - therefore there's nothing in the (read only) /etc
so long,
Hias
111 is rpcbind. If you don't plan to use NFS you can disabling it by masking rpcbind.service and rpcbind.socket
so long,
Hias
Bug reports, especially with detailed info, are always welcome.
For issues in milhouse builds it's best to post in his threads on the kodi forum so everything's in one place.
The dmesg output helped me track down a bug lingering in the pcm512x driver for a long time, I've sent a fix upstream and it's already scheduled for inclusion in the next 5.6 kernel (and will then find it's way into earlier kernels)
ASoC: pcm512x: Fix unbalanced regulator enable call in probe error path - Patchwork
As posted in the milhouse thread I suspect the actual error is with the clock driver of the Hifiberry card (which Hifiberry folks need to look into, I don't have the hardware here to test myself) which then triggered the bug in the pcm512x driver.
so long,
Hias
The original remote is broken, I was thinking of using a second one with this IR reciever. So, I must get another IR reciever ?
Yes. I'd recommend getting an (HP branded) MCE USB receiver, which is very well supported in Linux (and LibreELEC).
so long,
Hias
The logs look fine,
The Ortek IR receiver shows up as keyboard+mouse input devices and isn't handled by the rc-core subsystem so it won't show up in ir-keytable and you can only use it with the remote it was bundled with.
I did a quick test here on RPi4 with the remote+receiver and it worked out of the box.
so long,
Hias
The default RPi4 image has not been changed, reducing CMA memory is a bit risky (it could break "heavier" skins that otherwise work fine on the 2 and 4 GB models), so if you are affected by that issue please reduce CMA memory manually for now.
To be future proof I'd definitely recommend getting a 2GB (or 4GB) model.
so long,
Hias
It might be easier to just use the latest nightly build from Index of / , they are built from the LE master branch (so kernel 5.4 and kodi 19) and you can find both img.gz and tar files there. Write the img.gz to a USB pendrive and give that a try.
so long,
Hias
With gpio-ir-tx it's similar as for gpio-ir, you can use gpio_pin=XX to use a different GPIO.
Actually, it'd be best to connect the IR transmitter to GPIO 18 (and use a different one for receive), then you can use pwm-ir-tx instead of gpio-ir-tx (pwm-ir-tx uses the PWM to generate the carrier frequency and is therefor e more precise and less cpu intensive than the bit-banged gpio-ir-tx).
With these 2 overlays loaded you'll get two /dev/lircX devices and you'll need to add some udev rules to create eg /dev/lirc-transmit and /dev/lirc-receive symlinks - it's not guaranteed that eg /dev/lirc0 will always be receive, this may change.
As you already have a working lircd setup you can use that for receive - just change the device in lirc options to the /dev/lirc-receive one.
To use lircd for transmitting you'd need to setup a second lircd instance (separate lircd.socket and lircd.service systemd units plus separate lirc options and lircd.conf files), which is a bit tricky. Also lircd has some nasty bugs when transmitting (I reported that aeons ago but it hasn't been fixed) - so better avoid lircd.
You can use ir-ctl instead for sending, it doesn't require a background daemon and you can simply specify the lirc device and protocol+scancode (or alternatively a raw file which you can capture with ir-ctl -r, if the protocol isn't natively supported by ir-ctl). To find out the scancode+protocol simply run ir-keytable -p all -t on the receiving device and push buttons on the remote which you want to simulate.
Also search this and the raspberry pi forum, I posted several more infos about IR there (search for my username and/or ir-ctl, gpio-ir, ir-keytable).
so long,
Hias
With an IR transmitter connected to your RPi you could simply use irexec to execute irsend when a specific button is pressed.
irexec is available in LE but not run by default - you'll need to start start it via autostart.sh or a systemd service.
You'll probably need to delay the irsend call a bit (eg do it via a shell script and add a sleep 1 before), otherwise the IR signal from your remote (where you are pressing the button) will interfere with the IR signals transmitted by the RPi.
so long,
Hias
NOOBs (and I think also PINN) support the installation of custom/locally created images.
I used that successfully when testing RPi4 noobs installation of LE about half a year ago but can't remember the details. IIRC you need a tar file for each partition or sth like that - just check the NOOBs docs or the thread on the RPi forum.
so long,
Hias
Don't use BerryBoot, it has been known to break LibreELEC for a long time. If you want a multiboot setup use NOOBS or PINN.
so long,
Hias
It's a bit odd that the Xbox remote doesn't work. I checked the driver code and it should support all variants of the NEC protocol.
Getting an (HP branded) MCE receiver is the best option. The IR receiver in these DVB dongles isn't too great, it reacts quite sluggish and I often had issues with it as well in the past (even with the Hauppauge RC5 remote that came with it).
so long,
Hias
Are you sure your Harmony is set up right? In general it's recommended to configure the Harmony remotes to use the Microsoft Media Center (MCE) remote profile (NOT the MCE keyboard profile!), then it'll work out of the box with LE (you only need to add the dtoverlay=gpio-ir line to config.txt).
If in doubt simply run ir-keytable -p all -t, that'll show scancodes of all supported protocols that the IR receiver saw. If you don't see anything from your Harmony remote, look at the Harmony config.
so long,
Hias
First of all I'd recommend updating to LE 9.2 - 8.2.5 is quite old.
To change the protocol simply use ir-keytable -p ... (leaving out the -d device) or specify the rcX device with -s rcX.
Your IR receiver is a bit limited as it contains a hardware decoder that only supports a few protocols. It should work fine with the remote that came with it but it- could well be the remotes you tried use a protocol that this receiver can't understand.
For further info also check the Wiki: Infrared Remotes [LibreELEC.wiki]
so long,
Hias
Odd, haven't seen a hang on reboot here yet. The hangs reported in the linked thread were caused by early versions of the USB firmware updater (which updated the firmware while the system was running), LibreELEC ships with a later version where updates are performed by the bootloader (recovery.bin to be more specific).
In LibreELEC settings you can't reflash the firmware if they are up to date, but you can do it manually via ssh if you like. LibreELEC includes the rpi-eeprom-update tool (same tool as on Rasbian) and you can also use it to install beta firmwares (do that at your own risk though).
To re-flash the USB firmware use the "-u" option of rpi-eeprom-update
so long,
Hias
You seem to have put a lircd.conf file into /storage/.config so lirc is used - make sure the file matches the remote you are using.
You can also try running ir-keytable -p all -t, if that outputs lirc scancodes when you press buttons it means the IR protocol is supported by the kernel (the output will show you which protocol that is) and you can drop the lircd.conf file and use ir-keytable / rc_maps.cfg configuration instead (which is a lot less error-prone than using irrecord to create a lircd.conf file).
so long,
Hias