Since the December update I have a battle at boot time between my XBOX remote and my IQ Audio sound card. After a reboot I find I have no remote although it remains enabled. I suspect strongly that this is closely related to the message that appears under My OSMS --> Settings - Pi --> hardware Support “Warning - GPIO remote default pins incompatible with Hifiberry and (something off the screen).”
To restore everything I have to disable the audio, re-choose the remote, power restart to get the remote recognised again, rechoose the iqaudio, restart again, change Kodi audio to use IQaudio, etc. This actually often takes several power cycles to settle down with both working. I never had the problem before December with any OSMC or RBMC version.
Today really rubbed it in with the January update which disabled the IQAudio completely. Luckily the solution of adding “dtparam=audio=off” to config.txt given elsewhere seems to have solved that issue, I thought turning off LIRC GPIO support would fix this, as I don’t need it - the IR receiver is a USB device. But for some reason that also stops the remote from working after the next reboot.
My config.txt now ends as follows:
dtparam=audio=off
dtoverlay=lirc-rpi
dtparam=gpio_in_pin=18
dtparam=gpio_out_pin=17
dtoverlay=iqaudio-dac-overlay
Everything is currently working, though to be honest after spending the best part of an hour getting all back again I am scared to turn anything off. Any suggestions how I can rearrange things to stop this problem happening again
If you are using a GPIO connected sound card you will need to put your IR receiver on different pins and configure this in config.txt.
GPIO in 18 and out 17 is the default pin assignments for an IR receiver but is also used for many sound cards - hence the warning that the Pi config module gives you.
You won’t get both the IR receiver and sound card working at once if there is a pin assignment conflict.
Thanks for the reply. I agree that the error message highlights a potential conflict. As I don’t use the GPIO for the IR receiver (it’s USB) I assumed I could just turn LIRC GPIO Support off. But when I do that the remote stops working! I’ve also tried reassigning the pins but that doesn’t seem to remove the error message.
The biggest problem seems to be when the system is restarted. It appears to me that at cleanup time preceding shutdown the error condition is noted, and config.txt is actually rewritten to remove the offending entry. So then, when the reboot completes the remote is disabled again.
My clumsy workaround at present is to put back the “good” version of config.txt at bootup time but it’s pretty frustrating to have to do that. I guess I’m mostly interested to know what change in the December release triggered this issue - it didn’t appear before then.
I can think of absolutely no reason why this would be the case. Turning off lirc GPIO support removes the dtoverlay entry in config.txt.
This causes the kernel not to automatically load the rpi_lirc kernel module on boot. This has absolutely nothing to do with support of remotes connected via USB, especially if said remotes do not use lircd.
Your config.txt file is never touched during shutdown. The only time it will ever be written to is when you exit either the Pi Config or Overclock modules in My OSMC.
Are you certain that config.txt is being changed during shutdown ? Again, I cannot see how this could be the case.[quote=“stevee6nz, post:3, topic:13008”]
My clumsy workaround at present is to put back the “good” version of config.txt at bootup time but it’s pretty frustrating to have to do that. I guess I’m mostly interested to know what change in the December release triggered this issue - it didn’t appear before then.
[/quote]
Without full debug logs we can only guess. Please post a full debug log, and if the config.txt seems to be changing, please post the before and after versions.
Also, are you running the very latest update or are you still on the December release ?
You are right - config.txt is not written at shutdown as I surmised. What I have found is that although the remote doesn’t use the GPIO pins, it is still necessary to enable LIRC GPIO support in My OSMC. To avoid any possible conflicts I changed the used pins to 24 as shown below though that isn’t really necessary. The bottom of my config.txt file now reads:
dtparam=audio=off
dtoverlay=lirc-pi
dtoverlay=iqaudio-dac-overlay
dtoverlay=lirc-rpi
dtparam=gpio_in_pin=24
dtparam=gpio_out_pin=24
The two lirc entries are a bit puzzling, but the key is that this config is stable and survives SW reboots. Power cycles are trickier, as the remote fails afterwards, but returns after another SW reboot. I have just updated to the release of a few days ago with no problem other than that.
I’ll consider it solved. Thanks again for the help.
Well I don’t consider it solved, because there is no explanation for why your solution could possibly work. As I said, all the setting controls is whether the kernel module for GPIO IR loads or not - this has no bearing on USB devices, so you have not found the real cause of the problem.
Again, without proper log files we can only speculate.