Here's the default config.txt for RPi4: LibreELEC.tv/config.txt at libreelec-9.2 · LibreELEC/LibreELEC.tv · GitHub
When editing it on a PC make sure you configure the editor to use Unix line endings, not windows line endings.
so long,
Hias
Here's the default config.txt for RPi4: LibreELEC.tv/config.txt at libreelec-9.2 · LibreELEC/LibreELEC.tv · GitHub
When editing it on a PC make sure you configure the editor to use Unix line endings, not windows line endings.
so long,
Hias
Sure? Isn't it an MCE remote, which needs LIRC?
No and No.
First of all MCE has become a rather generic term and a lot of remotes that don't use the original MCE remote protocol and scancodes have been marketed under that term.
The original MCE remotes (plus scancodes) are supported out of the box with in-kernel/ir-keytable decoding via the rc6_mce keymap.
The Xbox 360 remote uses the rc6/mce protocol as well but uses different scancodes so it needs a separate keymap (to map scancodes to keycodes) - see LibreELEC.tv/xbox_360 at libreelec-9.2 · LibreELEC/LibreELEC.tv · GitHub
To make things easier for users we use a special multi-keymap by default so that the original Microsoft MCE remote, Xbox 360 and Xbox One keymaps are used instead of only the default rc6_mce keymap - see LibreELEC.tv/options at master · LibreELEC/LibreELEC.tv · GitHub
Lirc is only needed for a few, rather odd, remotes that aren't supported by in-kernel decoding (which will become even fewer in LE10 where we support BPF protocol decoders via ir-keytable).
so long,
Hias
No, it's essential. You don't need config.txt options to start LIRC. Download your fitting lircd.conf here.
uh, no. No lirct.conf should be needed, the xbox 360 remote should be supported by in-kernel decoding out of the box.
so long,
Hias
I'm more confused now after reading the wiki because It talks about a lot's of confusing things but doesn't tells me how I could use my remote which already worked out of the box in the past
The wiki page contains a very detailed step-by-step troubleshooting section Infrared Remotes [LibreELEC.wiki].
Please follow the steps there and post the details what exactly doesn't work. Creating a poll but not providing any info isn't helping much in your case (unless you only want to rant).
so long,
Hias
If you use kernel-level IP configuration you have to pass in all settings (netmask, gateway, DNS/NTP server etc). See the documentation of the ip= setting in linux/nfsroot.txt at rpi-4.19.y · raspberrypi/linux · GitHub
Connman interferes badly with disk/storage on NFS so it is disabled automatically in LE 9.2.1 when kernel ip configuration is used.
so long,
Hias
ssh in and delete /storage/.kodi/userdata/profiles.xml, then reboot, the file got corrupted.
BTW: the profiles.xml corruption error should (hopefully) be fixed in LE 9.2.1, so it's best you upgrade your installation.
so long,
Hias
Can you test if this addon version (for x86) works better?
visualization.projectm-2.3.5.2.zip
This contains an updated version of projectM, 3.1.2, as used in official kodi addons (we were still at 3.1.1-rc4).
so long,
Hias
Just add the dtoverlay line to config.txt Raspberry Pi Config.txt [LibreELEC.wiki] adjust the temp parameter as needed. If you use a different GPIO than the default 12 you also have to add gpiopin=GPIONUMBER
The second link (to the gpio-fan-overlay.dts file) shows how the transistor should be hooked up and also contains a link to the RPi forum with more details Overlay for GPIO connected fan - Raspberry Pi Forums
so long,
Hias
You can't control the fan if you didn't add the transistor.
Pins 4/6 are +5V and GND so the fan will be constantly running as long as your RPi is powered up.
The python script you posted expects a transistor connected to GPIO 17.
BTW: a much simpler alternative to using a python script is to use the gpio-fan DT overlay. GPIO number and temperature can be passed in as parameters. eg
see also here linux/README at rpi-4.19.y · raspberrypi/linux · GitHub and here
linux/gpio-fan-overlay.dts at rpi-4.19.y · raspberrypi/linux · GitHub
so long,
Hias
Use this command:
so long,
Hias
This was not a debug log so unfortunately pretty useless.
I'd suggest you do a different test, to check if the IR receiver sends proper input events (that's the lowest level we can look at).
First install the "System Tools" addon from the LibreELEC repository (it's in the "Programs" section).
Then ssh in and stop both kodi and eventlircd:
Now run evtest which should print a number of input devices together with their description. You probably have 3 from your Spinel Plus IR receiver, start with the "Keyboard" one, and test the other ones later.
Then press a "working" button, you should get some output on the screen like this:
Event: time 1584797019.747427, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70052
Event: time 1584797019.747427, type 1 (EV_KEY), code 103 (KEY_UP), value 1
Event: time 1584797019.747427, -------------- SYN_REPORT ------------
After that press a non-working button, you might also see some screen output - please post it plus the info which button you pressed.
If you didn't get any screen output on a button press then it may be that it's delivered via one of the other input devices, so check them, too with evtest.
so long,
Hias
Please test the build linked in this post Latest LibreElec on Intel NUC and audio and report back if it works.
so long,
Hias
To anyone affected by the NUC audio issue:
could you please drop your current workarounds (i.e. re-enable DSP support in BIOS or delete the modprobe blacklist file) and test if this build works?
LibreELEC-Generic.x86_64-9.2-devel-20200320214349-16919f7.tar
This is LibreELEC 9.2.1 plus the proposed fix (default snd_soc_skl blacklist) alsa-lib: add modprobe.d file to work around NUC audio issues by HiassofT · Pull Request #4260 · LibreELEC/LibreELEC.tv · GitHub
If we get confirmation that this works we'll add it to LibreELEC and create a new official build with the fix.
so long,
Hias
Your USB receiver (0471:20CC is a Philips spinel plus) is hardwired to the remote it cane with and can't be configured via ir-keytable (or lirc).
So just use keymapping in Kodi, there's not much else you can configure.
If that doesn't work we need a debug log that shows you pressing working and non-working buttons.
so long,
Hias
Again, it's not a bug in LibreELEC but with the way you set up netboot and your DHCP server.
For netboot you need manual allocation ("static" DHCP leases), not dynamic allocation. Manual allocation doesn't require the lease to be renewed.
See also the explanation in the DHCP RFC RFC 2131 - Dynamic Host Configuration Protocol
QuoteIn "manual allocation", a client's IP address is assigned by the network administrator, and DHCP is used simply to convey the assigned address to the client.
so long,
Hias
According to the dnsmasq manual infinite lease times are supported - you may want to use that for your netboot clients.
so long,
Hias
While I agree that full DHCP conformance would be nice, kernel ip autoconfiguration, especially in combination with netboot/nfsroot is a rather special case. The assigned IP addresses have to be static and permanent.
Consider what would happen if the DHCP server wouldn't renew your lease or give you a different IP. Basically all the client could do in that case is panic - you can't just shutdown network (as the rootfs would be lost) or unmount the NFS root and set up a new IP (when your NFS root is gone so are ifconfig, mount etc).
It's best to see the kernel DHCP implementation as a nice shortcut so you don't have to manually specify the network parameters in the ip=... kernel option, more like BOOTP or RARP.
See also the discussion in the predecessor of the linked PR connman: ignore kernel-configured netdev and improve resolv.conf handling by HiassofT · Pull Request #3883 · LibreELEC/LibreELEC.tv · GitHub
so long,
Hias
This is the expected behavior when the kernel uses ip autoconfiguration. Make sure you set up a static DNS entry in addition to the static DHCP lease.
so long,
Hias