Hi list,
There's a new version of the DVB API wrapper patch that adds fallback compatibility to the current stable DVB API without multiproto support.
The new version also fixes a bug with the default DVBFE_MOD_AUTO modulation on DVB-S.
Also, the patch for VDR-1.5/1.6 that allows to read a channels.conf from 1.7 is now available on that page.
Support for DVBFE_SET_DELSYS will follow in next version.
Get it: http://www.udo-richter.de/vdr/patches.en.html#dvb-api-wrapper http://www.udo-richter.de/vdr/patches.html#dvb-api-wrapper
Cheers,
Udo
On 04/13/08 23:06, Udo Richter wrote:
Hi list,
There's a new version of the DVB API wrapper patch that adds fallback compatibility to the current stable DVB API without multiproto support.
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?
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.
Just my thoughts, no offense intended, and of course it's your decision to maintain such a patch ;-)
Klaus
Also, the patch for VDR-1.5/1.6 that allows to read a channels.conf from 1.7 is now available on that page.
Support for DVBFE_SET_DELSYS will follow in next version.
Get it: http://www.udo-richter.de/vdr/patches.en.html#dvb-api-wrapper http://www.udo-richter.de/vdr/patches.html#dvb-api-wrapper
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 difficult.
Cheers,
Udo
-
Klaus Schmidinger -
Udo Richter