Posts by HiassofT

Quote from Da Flex

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

Quote from Da Flex

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

Quote from userfame

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

dtoverlay=gpio-fan,temp=40000

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

Quote from jasn

In order to try the fix how would I remove the "blacklist" used from this command?

Code

echo "blacklist snd_soc_skl" > /storage/.config/modprobe.d/blacklist-snd-soc-skl.conf

Use this command:

rm  /storage/.config/modprobe.d/blacklist-snd-soc-skl.conf

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:

systemctl stop kodi
systemctl stop 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

Quote

In "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.

Man page of DNSMASQ

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

Well, you should have substituted /dev/videoX with the actual device node shown for your grabber (/dev/video0 in your case).

As /dev/video0 is already the default simply run v4l2-ctl -n.

so long,

Hias