[nickr]

I just downloaded one of those images and tried to get it working in virtualbox, but no luck.

---

I am guessing that you got a new kernel with the latest openelec and some devices nodes have changed. I assume you are using the commands in http://forum.xbmc.org/showthread.php?tid...pid1547157

Take a look around in /sys/bus/acpi/devices/ and see where the node lies now (assuming it is there).

Yes, this is a new kernel (3.12.1) and it looks like what has happened was modprobe -r got butchered off of the end of the script file I'm using somewhere along the way. Stupid user error <sigh>

The Intel thread above was started by lmyllari regarding this issue, using the code in his support posting worked but looking closely it differed only slightly than what I'd found here and had used on Frodo. I think the original code will work. Chasing my tail it seems!

Code:

#!/bin/sh

# Work around NUC CIR issue
# see http://forum.xbmc.org/showthread.php?tid=176718&page=17 and
# https://communities.intel.com/thread/46259 for more information

modprobe -r nuvoton-cir
echo "auto" > /sys/bus/acpi/devices/NTN0530\:00/physical_node/resources
modprobe nuvoton-cir

What's interesting is that just now after a reboot this didn't actually work even running it manually and I had to try this from the Intel support post to get it working, running the script above from a shell din't bring the CIR up.

Code:

modprobe -r nuvoton-cir && echo "auto" | tee /sys/bus/acpi/devices/NTN0530\:00/physical_node/resources && modprobe nuvoton-cir

Functionally these appear to be the same thing so this makes no sense. Right now my system is up, remote works, sound works, and it appears to have found my SQL server so my watched marks are synchronized - insert SnoopyDance. I'm going to try rebooting it a few times with the original script and try to be sure of my results.

P.S. I'm on lmyllari's latest build. My thanks to him and others for their work on this!

Yes and no they are the same thing. The && between the commands ensures that the previous command has completed successfully before the next executes - if any one fails execution stops. But I am not sure why that is making a difference?