I would advise to start with a new install, to get rid of unwanted crap.
i’ve tested 3 BT remotes, none had problems.
(see Added support of bluetooth remote G20BTS PRO to my Volumio on RPI4 - #26 by Wheaten)
There is no logic programmed (besides functionality for the GUI).
So I have no clue what is happening on your system as both BT and IR act up.
Maybe you can check your log if you run into undervoltage, causing strange behaviors.
Dear @Wheaten ,
thanks so far for your kind assistance.
A “fresh” install is already there 
- I’ve just started few days ago so no huge amount of crap should be present.
Anyway your thoughts about “triggerhappy” led in “kind of” right direction.
I was able at least to figure out that some of the seen actions seemed to be triggered from this tool. I’ve at least added some wanted actions to the config file and for now the remote works (nearly) as intended.
I still have a problem with one key triggering a Google popup window which cannot be closed - I have posted a question in the corresponding thread.
I can imagine that the differences between your any my remote(s) is in the build …
I have (in both cases) an “air-mouse” and not a typical remote. So the device is partially interpreted as keyboard - which triggerhappy covers …
(my “blonde” explanation …).
Anyway: HUGE thanks for your kindness and effort!
Warmest regards,
Ralf
Still not sure what is happening on your system.
I’ve tested with this remote below, Even though triggerhappy is installed by default, none of the buttons are interfering with Volumio, unless I program them. Also the home buttton (KEY_HOMEPAGE) doesn’t open a new instance of the kiosk as what happens with yours.
REALLY interesting…
I would assume that at least some of your keys were catched by triggerhappy…
Strange!
But in my system the behaviour seems to be at least consistent.
If I use
sudo thd --dump /dev/input/event0
Some of the KEY_STROKES are catched.
BTW: In this moment I realize that the other mappings may result from /dev/input/event1 or /dev/input/event2 …
Have just checked this,
event1 delivers the “air mouse” functionality, so mouse-pointer movements.
event2 is empty.
event3 shows up the missing KEY_MAPPINGS
There is “KEY_VOLUMEUP”, “KEY_VOLUMEDOWN” and “KEY_HOMEPAGE” …
cool.
At least identified.
Finally I’ve tried to get rid of the google kiosk page and added a KEY_MAPPING to KEY_HOMEPAGE (toggle command)…
Guess what happens?
Works. BUT: Does not replace call of kiosk page but ADD play/pause to the same key…
I’m clueless …
I’m really curious where this call comes from (definitely NOT from /etc/triggerhappy/triggers.d/audio.conf ).
Anybody an idea where may the defaults are defined for triggerhappy?
I cannot find any other *.conf file which contains KEY_HOMEPAGE
Thanks so far.
Warm regards,
Ralf
I told you this
Dear @Wheaten ,
currently I do not use the python program.
Just triggerhappy.
This catches all my events, I need (unfortunately for some reasons not super reliable - but “works”).
So I’ve decided to stay with triggerhappy to avoid eventually occuring interferences …
The IR stuff is still present (works de facto more reliable…).
So I may end up with the apple remote and IR sensor.
Have to figure out where the sensor can me mounted.
The whole thing is planned as kitchen-“radio” so the display will be mounted in a wardrobe-side and the Pi and cables inside the wardrobe…
Regards and many thanks for your thoughts!
Ralf