RetuneMonitor generates significant load with DVB cards without hardware i2c support

[yeasah@…]

Janne Grunau's original description of the problem:

The cause is the FE_READ_STATUS ioctl in RetuneMonitor?. It blocks for approximately 10ms on cards with a cx88 or bt8xx pci bridge and the pluto2 device. These devices have no hardware i2c support. For the cx88 it's just not implemented yet. They use i2c bit banging instead.

This wouldn't be a problem if the signalmonitor is only for tuning checks before channel changes. But it isn't that good for the active eitsccanner.

I believe it's time for the !FE_CAN_RECOVER retunes to go away (such a short life!) -- the only DVB driver which required this has since been fixed, and since the rotor completion implies a retune anyway, it only helps if you have the older broken driver AND you have an incorrect rotor configuration (i.e. the angular speed set in the DB is higher than the motor actually moves)

I'm particularly concerned that the retunes might conceal problems with the new diseqc code not being reliable (though it could conceal a wide variety of tuning problems too), so I'm actually rather keen to get it out of there.

Attaching a patch that removes the periodic retune stuff from the dvb signal monitor and channel objects.

[Stuart Auchterlonie]

This patch successfully removes the 10% loading per card during the eit active scan.

[Stuart Auchterlonie]

(In [10643]) Closes #2099. Removes ReTuneMonitor?

ReTuneMonitor? was causing 10% cpu load per card during eit active scanning. This removes the ReTuneMonitor? as it is no longer needed.

It was only useful iff you had a specific card and using a buggy driver and had your configuration incorrect. Configurations can be fixed and the driver bug has also been fixed.