Problem with vdr.backend and IR GPIO

Hi there, I've got a very strange problem I can't fix on my own

Running LE 7.0.3 on RPi3. I added a TSOP4838 as IR receiver on gpio 18 using lirc_rpi. All working well. I had VNSI client aiming to my remote VDR server. As I wanted to be able to record and view TV at the same time, I needed to add a second DVB-S receiver. This one, a TT-S3600, I connected to my RPi3 client, as I have only one sat cable at my server.

Ok, went and added vdr.backend addon, configured, added channels.conf from server (for to have same channel mapping), set VNSI to localhost instead of my server's address and rebooted.

So far, so good.

Problem now is:
If vdr.backend is running, the IR remote is lagging and keys are not received, so not sent!?
GUI is still responsive and I'm able to control kodi very fast with BT keyboard, but not with remote?

irw gives results, if keys are receipt. But they aren't receipt as they should!

Deactivating vdr.backend gives back full control with IR!

Thought of the USB receiver has its own IR receiver (rc_tt_1500) and tried to disable it, but I can't.
If I 'modprobe - r rc_tt_1500', I get a kernel oops, so no chance this way. 'modinfo dvb_usb_pctv452e' even has no param regarding IR, so I'm lost here.

Added '--lirc=/dev/null' to vdr.start to no avail either

Don't know what's interfering here...

Last I tried, as it felt like IRQ troubles, was to change TSOP from GPIO 18 to 22 (with corresponding changes to config.txt). Again, without vdr.backend (disabled), remote is working fine. With vdr.backend enabled, the remote is suddenly laggy, unresponsive and sometimes multiple keypresses aren't even recognized (seen with irw).

Switching USB ports didn't helped either.

So, what am I supposed to do, to get this beast pinned down?

P. S. Stumbled upon this one:
LIRC Remote Not Responding · Issue #246 · hyperion-project/hyperion · GitHub

It matters hyperion, but symptoms are quite identical!

Here you are (sprunge.us isn't working atm)
lb9e

Don't worry about the I2C errors, these belong to TTOO S2-3600 and they are there since ever

I tried 7.95.1 yesterday, but had kernel oops, like described here:
thread-3869.html

I'll fetch some logs of kernel oops and post it in the other thread.

The USB receiver worked well on my server, but that is running headless vdr, so no IR involved.

Here are some new logs. I had enabled dtparam I2C, I2S and SPI in the hope it changes something, but it didn't. So in the above dmesg you see I2C and IR fighting for gpio 18.

dmesg:
93wt

lsmod:
ic0v

For overview, here's output of ir-keytables

Found /sys/class/rc/rc0/ (/dev/input/event1) with:
        Driver (null), table rc-tt-1500
        Supported protocols: rc-5
        Enabled protocols:
        Name: IR-receiver inside an USB DVB re
        bus: 3, vendor/product: 0b48:3007, version: 0x0101
        Repeat delay = 1000 ms, repeat period = 125 ms

So you see this rc_tt_1500 module is the keymap of S2-3600's IR receiver

FYI, here's an issue regarding hyperion-project with exactly the same issues (v4l2?)
LIRC Remote Not Responding · Issue #246 · hyperion-project/hyperion · GitHub

I tried blacklisting rc_tt_1500 with no success!

The logs I posted already have that module blacklisted!

Don't know what language you speak, but here's a german thread dealing with problems around v4l2 and gpio pumping:
Alternative Pins für IR TSOP ?

I'll try to use some other gpio for IR, as the above thread states that some gpio are being used with spi when using v4l2. Even USB WiFi has problems...

My conclusion would be, as this problem seems to be of matters with hyperion, vdr, dvb, etc, it has something to do with v4l2...

As a note, even changing IRs in-gpio to 26 doesn't change anything, although it is not connected to spi like seen here:
RPi BCM2835 GPIOs - eLinux.org

Can't test with beta2 testbuild as the dvb module still causes a kernel oops... posted logs in the other thread

Ok, its working/solved with 7.95.2

VDR backend running with non blocking lirc using gpio (in my case gpio_in_pin=26)

Here's dmesg:
libreelec.local:8080

Ups, sorry
dXDj

I'm sad to say, that the problem isn't solved yet. It has been improved, but it's not fixed

Since 7.95.2 IR is working but with a huge 'lagging'. I need to keep buttons on remote pressed for longer for to make it come through. Before it wasn't even recognized most of the time.

I tried switching to minisatip instead of vdr to no avail. As soon as the service is stopped (be it vdr.backend or minisatip) the remote starts working as it should. When starting either service, it stops responding/becomes laggy
Kodi is responding as it should, as I am able to test with yatse as remote....

Any ideas where or what to check?

The above dmesg is with minisatip

PS as stated above, I'm still unable to blacklist rc_tt_1500 but I'm now able to modprobe - r the module without a kernel oops. This doesn't change anything, so it's not the built in ir from dvb receiver disturbing gpio, but it certainly has something to do with video (v4l2?).

Quote from CvH

could you reproduce it with LibreELEC-RPi2.arm-7.95.2-mb-latest.img.gz ? (it includes the 4.10 drivers)

Hi CvH,
with that version there's again a slight improvement, although not fixed

Thx @Hias for pointing out!
That what's stated there seems to reflect my experiences. So it's not a matter of video alone
My thoughts were to maybe check if another USB receiver could solve the problem, but from reading the github comments and explanations, I fear this will not solve the problem... I'm going to swap the receivers from server and RPi3 and see if it changes anything.
On raspberry forums I've read of another user having issues with a Technotrend receiver, so it's maybe something special in regard to that explicit module...

A question left is, if changing the gpio_in_pin could also help or if all possible pins suffer? Are there some gpios that are affected more than others?

I even thought of checking with piscope (pigpio library) for to see what's going on on gpios when activating vdr or minisatip, but haven't tried running gpiod until now and don't know if precompiled binaries are working with LE.