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
> 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
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