According to the technical reference, there is a I2C bus  for the ARM CPU & all tuner ICs:

• pin 81 (SCL) & pin 82 (SDA) on the MT5820 CPU
• pin 6 (SCL) & pin 7 (SDA) on the LNBH29EPTR IC (this seems to be the DISEQc driver)
• pin 22 (SCL) & pin 21 (SDA) on the M88DS3002 IC (SAT tuner)
• pin 16 (SCL) & pin 17 (SDA) on the MXL601 (DVB-T tuner, in my case a M88RS6000, maybe with a different pinning)
• pin 42 (SCL) & pin 41 (SDA) on the MT5135 IC (CI controller)
• pin 30 (SCL) & pin 29 (SDA) on the TAS5721 (audio amplifier)
• pin 5 (SCL) & pin 6 (SDA) on the keypad connector (unused in my TV; but the best possibility to hook on)

I dig out my OpenBench Logic Sniffer and let's see whats happening on the I2C bus.
Unfortunately, I didn't get any useful signals from the keypad connector. Either there are no I2C pins on this connector or the logic sniffer doesn't work as expected.

After some unsuccessful attempts to get I2C bus data, I discarded this approach for now.

Obviously, the firmware was not able to find/initialize the tuner IC and has no retry counter -> endless loop...

As I have the firmware binary, there must be some hint on the tuner initialization. Maybe there is the possibility to ignore the tuner at all?

Until now, I never used any disassembler to examine binaries (shame on me :-)).
The most commonly known disassembler is IDA. No freeware version to examine ARM binaries, so I needed an alternative (IDA would cost more than the TV :-)).
The NSA released their Ghidra toolchain, let's go with that.

These analyzer software has a steep learning curve, but after some searching and randomly clicking, I got the analyzed binary with the assembler code & C routines.

By searching in the program memory for "6000", following locations will show up:

If you click on the string, you will jump to location in memory, where you can see all callers/references as well).
Most of the functions return 0 nevertheless. But at location 0x000531f0, there is a function where the return value depends
on the success of the tuner setup. The return value loading is done at 0x00053294 by "cpy r0,r4".
Most of the developers use 0 as return value for success, so maybe we can modify the binary in a way that this function always returns 0?
Maybe it is possible to simply load 0 here (mov r0,#0x00)?

To be honest, I can use hex editors, but I have no idea if it is possible to simply replace a machine command in an ELF file (hashes, location in the binary file,...).

Still, very interesting to have a deep look into the firmware.