Klaus Schmidinger wrote:
>> The new version also fixes a bug with the default DVBFE_MOD_AUTO 
>> modulation on DVB-S.
> Is this fix also relevant for the original VDR 1.7.0?

No, its just a wrapper bug: After importing a DVB-S channels.conf from 
1.6.0, VDR uses DVBFE_MOD_AUTO as modulation, and after the next channel 
update, VDR uses DVBFE_MOD_QPSK. Previous versions of the patch did not 
accept AUTO.

> BTW: just curious, but what exactly is the reason for this "API wrapper"?
> Shouldn't we rather encourage people to switch to the multiproto driver?
> After all, I did release a stable version 1.6 for those who don't want to
> (or can't) switch to the multiproto driver. Now we're at a new *developer*
> version, which should *focus* on making the switch to multiproto.

VDR 1.7 can (and will) enforce the multiproto development, and thats ok. 
The DVB-S2 movement alone will make sure that multiproto won't get stuck 
for long.

I made the patch mainly for personal reasons: I'm running a VDR binary 
currently on 4 different systems, a 5'th is in planning. I'm not really 
interested in building kernels and drivers for all of them, and probably 
having to update these often too. (One is a Knoppix base, replacing the 
kernel wouldn't even be easy.)

Also, I'm not sure what will happen first: All distributions using stock 
kernels with multiproto support by default, or VDR 1.8.0 being ready. In 
the end, it might be necessary to have fallback support anyway, at least 
for distribution packages. And wrapping these few ioctl calls isn't that 



vdr mailing list

Reply via email to