On 05.04.2010 20:55, Petri Helin wrote:
On 04/05/2010 12:57 PM, Klaus Schmidinger wrote:
On 05.04.2010 00:55, Teemu Rantanen wrote:
Hi,
There's a new version of the patch implemented as a plugin. It seems to work, but there are few things to notice:
- Plugin does not cache which devices are Reddo devices, instead it
probes sysfs every time QAM256 channel is being tuned into (on any device). It would be nice if cDeviceHook added a mechanism for a hook to store context for each device. Hooking into device probe (like full feature card plugin does) would be much nicer way, but it would interfere with other plugins which need the same mechanism.
The proper way of doing this is to check the modulation types in cDvbDevice::ProvidesTransponder(), as in the attached patch (which will be part of VDR 1.7.15). If the "reddo" driver doesn't set the FE_CAN_QAM_256 flag correctly, it needs to be fixed there.
I used your patch as an example and created a simple test patch for dvb-c (I think yours is for dvb-s(2) only) in order to test the approach.
You're right. I guess the attached version should cover all frontend types.
I also disabled FE_CAN_QAM256 from the driver. After that VDR no longer used Reddo for QAM256 channels as expected. The approach is very limited: It disables QAM256 for the every TDA10023 frontend, not just for Reddo's,
Well, then the driver needs to make a finer distinction and *properly* set FE_CAN_QAM256.
and it doesn't make VDR to prefer Reddo for non QAM256 channels, which would make sense in order to keep QAM256 channels available as much as possible.
First the driver needs to properly report whether a device can handle a given modulation type. Then VDR can decide whether to use that device for a channel requiring that modulation. *Then* we can talk sparing such devices for recordings ;-)
Klaus