Marcel Siegert wrote: > hi klaus, > >>I thought that when (if?) these new PC DVB cards come >>out, they would be able to receive both DVB-S _and_ DVB-S2. >>So from VDR's point of view this would just be one single >>device and the device would decide, depending on the parameters >>given to it when tuning, which method it actually is. > > as different tuning parameters are needed, how to decide when structures/ioctls > do keep backwards compatibility? From VDR's point of view I wouldn't mind if it would take some changes in VDR to be able to work with DVB-S2 capable devices. My actual concern was that it shouldn't be necessary to access like frontend0 for DVB-S and frontend1 for DVB-S2. It should remain one frontend. VDR of course will know whether a given channel is DVB-S or DVB-S2 and can send different ioctl()s to the frontend in each case. >>Of course the current method used to distinguish the device >>types in VDR (FE_QPSK = DVB-S, FE_QAM = DVB-C and FE_OFDM = DVB-T) >>wouldn't work any more, so other criteria might be necessary. >>But basically a DVB-S device would be just one single device >>(with only one single frontend), whether it can only do the >>"old" DVB-S, or both DVB-S and DVB-S2. >> >>At least that's how I would hope this would behave in the future. > > afaik dvb-s2 is backwards compatible to dvb-s > > have a look at my mail some minutes ago, there's an example > for a _maybe_ solution - also to keep old versions of vdr/neutrino/enigma/whatever working. Well, whatever parameters or structs it takes to access a DVB-S2 capable device isn't the problem for VDR, it will have to be adapted to support those channels, anyway. It's just that there should be only one single frontend. Maybe I misunderstood the whole discussion in this thread. I just read about different frontends and was worried this could go into a direction I wouldn't be happy with ;-) Klaus
