VDR with S2API

  The attached patch is what I've gathered from various postings
regarding adapting VDR to the S2API driver API (thanks to
Igor M. Liplianin, Niels Wagenaar and Edgar Hucek - did I forget anybody?).

Since the S2SAPI doesn't provide a way of determining whether
a DVB-S device supports DVB-S2 (at least I didn't find any),
you need to apply the second attached patch to the driver
in order to impelement a new capability flag that reports
the availability of DVB-S2 support.

If you don't want to patch the driver, you can change the line

  case FE_QPSK: frontendType = (frontendInfo.caps & FE_CAN_2ND_GEN_MODULATION) ? SYS_DVBS2 : SYS_DVBS; break;

in dvbdevice.c to avoid FE_CAN_2ND_GEN_MODULATION. Either set frontendType permanently
to SYS_DVBS or SYS_DVBS2, depending on what you have.


So far DVB-S and DVB-S2 appears to tune fine.
DVB-C is completely untested.
With DVB-T tuning doesn't work, even though my TDA10046H based DVB-T card
does work with the S2API driver under VDR 1.6.0.

So for the moment I would appreciate if people could test DVB-T
tuning and check whether maybe I made some silly mistake in the
DVB-T tuning code.

Klaus
  

El Sábado, 6 de Diciembre de 2008, Klaus Schmidinger escribió:
> The attached patch is what I've gathered from various postings
> regarding adapting VDR to the S2API driver API (thanks to
> Igor M. Liplianin, Niels Wagenaar and Edgar Hucek - did I forget anybody?).
>
> Since the S2SAPI doesn't provide a way of determining whether
> a DVB-S device supports DVB-S2 (at least I didn't find any),
> you need to apply the second attached patch to the driver
> in order to impelement a new capability flag that reports
> the availability of DVB-S2 support.
>
> If you don't want to patch the driver, you can change the line
>
>   case FE_QPSK: frontendType = (frontendInfo.caps &
> FE_CAN_2ND_GEN_MODULATION) ? SYS_DVBS2 : SYS_DVBS; break;
>
> in dvbdevice.c to avoid FE_CAN_2ND_GEN_MODULATION. Either set frontendType
> permanently to SYS_DVBS or SYS_DVBS2, depending on what you have.
>
>
> So far DVB-S and DVB-S2 appears to tune fine.
> DVB-C is completely untested.
> With DVB-T tuning doesn't work, even though my TDA10046H based DVB-T card
> does work with the S2API driver under VDR 1.6.0.
>
> So for the moment I would appreciate if people could test DVB-T
> tuning and check whether maybe I made some silly mistake in the
> DVB-T tuning code.
>
> Klaus

For DVB-T in S2API the bandwidth must be in HZ.

http://www.linuxtv.org/pipermail/linux-dvb/2008-October/029556.html


Jose Alberto
  

On 06.12.2008 16:29, Jose Alberto Reguero wrote:
> El Sábado, 6 de Diciembre de 2008, Klaus Schmidinger escribió:
>> The attached patch is what I've gathered from various postings
>> regarding adapting VDR to the S2API driver API (thanks to
>> Igor M. Liplianin, Niels Wagenaar and Edgar Hucek - did I forget anybody?).
>>
>> Since the S2SAPI doesn't provide a way of determining whether
>> a DVB-S device supports DVB-S2 (at least I didn't find any),
>> you need to apply the second attached patch to the driver
>> in order to impelement a new capability flag that reports
>> the availability of DVB-S2 support.
>>
>> If you don't want to patch the driver, you can change the line
>>
>>   case FE_QPSK: frontendType = (frontendInfo.caps &
>> FE_CAN_2ND_GEN_MODULATION) ? SYS_DVBS2 : SYS_DVBS; break;
>>
>> in dvbdevice.c to avoid FE_CAN_2ND_GEN_MODULATION. Either set frontendType
>> permanently to SYS_DVBS or SYS_DVBS2, depending on what you have.
>>
>>
>> So far DVB-S and DVB-S2 appears to tune fine.
>> DVB-C is completely untested.
>> With DVB-T tuning doesn't work, even though my TDA10046H based DVB-T card
>> does work with the S2API driver under VDR 1.6.0.
>>
>> So for the moment I would appreciate if people could test DVB-T
>> tuning and check whether maybe I made some silly mistake in the
>> DVB-T tuning code.
>>
>> Klaus
> 
> For DVB-T in S2API the bandwidth must be in HZ.
> 
> http://www.linuxtv.org/pipermail/linux-dvb/2008-October/029556.html
> 
> 
> Jose Alberto

So you mean we should not use the driver's constants like BANDWIDTH_8_MHZ
etc., but use numerical values instead? Ok, if that's what it takes...

With the value in Hz (e.g. 8000000) I can now tune DVB-T channels - thanks a lot!

Klaus
  

? ????????? ?? 6 December 2008 17:06:40 Klaus Schmidinger ???????(?):
> The attached patch is what I've gathered from various postings
> regarding adapting VDR to the S2API driver API (thanks to
> Igor M. Liplianin, Niels Wagenaar and Edgar Hucek - did I forget anybody?).
>
> Since the S2SAPI doesn't provide a way of determining whether
> a DVB-S device supports DVB-S2 (at least I didn't find any),
> you need to apply the second attached patch to the driver
> in order to impelement a new capability flag that reports
> the availability of DVB-S2 support.
>
> If you don't want to patch the driver, you can change the line
>
>   case FE_QPSK: frontendType = (frontendInfo.caps &
> FE_CAN_2ND_GEN_MODULATION) ? SYS_DVBS2 : SYS_DVBS; break;
>
> in dvbdevice.c to avoid FE_CAN_2ND_GEN_MODULATION. Either set frontendType
> permanently to SYS_DVBS or SYS_DVBS2, depending on what you have.
>
>
> So far DVB-S and DVB-S2 appears to tune fine.
> DVB-C is completely untested.
> With DVB-T tuning doesn't work, even though my TDA10046H based DVB-T card
> does work with the S2API driver under VDR 1.6.0.
>
> So for the moment I would appreciate if people could test DVB-T
> tuning and check whether maybe I made some silly mistake in the
> DVB-T tuning code.
>
> Klaus

Thank You for VDR.
I really enjoy it.
  

???????????, Klaus

does your vdr-1.7.1-s2api.diff good for vdr 1.7.0 ?

> The attached patch is what I've gathered from various postings
> regarding adapting VDR to the S2API driver API (thanks to
> Igor M. Liplianin, Niels Wagenaar and Edgar Hucek - did I forget anybody?).
> 
> Since the S2SAPI doesn't provide a way of determining whether
> a DVB-S device supports DVB-S2 (at least I didn't find any),
> you need to apply the second attached patch to the driver
> in order to impelement a new capability flag that reports
> the availability of DVB-S2 support.
> 
> If you don't want to patch the driver, you can change the line
> 
>   case FE_QPSK: frontendType = (frontendInfo.caps & FE_CAN_2ND_GEN_MODULATION) ? SYS_DVBS2 : SYS_DVBS; break;
> 
> in dvbdevice.c to avoid FE_CAN_2ND_GEN_MODULATION. Either set frontendType permanently
> to SYS_DVBS or SYS_DVBS2, depending on what you have.
> 
> 
> So far DVB-S and DVB-S2 appears to tune fine.
> DVB-C is completely untested.
> With DVB-T tuning doesn't work, even though my TDA10046H based DVB-T card
> does work with the S2API driver under VDR 1.6.0.
> 
> So for the moment I would appreciate if people could test DVB-T
> tuning and check whether maybe I made some silly mistake in the
> DVB-T tuning code.
  

On 06.12.2008 17:55, Goga777 wrote:
> ðÒÉ×ÅÔÓÔ×ÕÀ, Klaus
> 
> does your vdr-1.7.1-s2api.diff good for vdr 1.7.0 ?

kls@hawk:/home/kls/vdr/vdr-1.7.0 > patch --dry-run < ../VDR/vdr-1.7.1-s2api.diff
patching file channels.c
Hunk #6 succeeded at 636 (offset -1 lines).
Hunk #7 succeeded at 643 (offset -1 lines).
Hunk #8 succeeded at 665 (offset -1 lines).
Hunk #9 succeeded at 685 (offset -1 lines).
patching file channels.h
Hunk #2 succeeded at 146 (offset -1 lines).
Hunk #3 succeeded at 203 (offset -2 lines).
Hunk #4 succeeded at 215 (offset -2 lines).
patching file dvbdevice.c
Hunk #7 FAILED at 265.
Hunk #8 FAILED at 323.
Hunk #9 succeeded at 407 (offset 11 lines).
Hunk #10 succeeded at 430 (offset 11 lines).
Hunk #11 succeeded at 493 (offset 11 lines).
Hunk #12 succeeded at 831 (offset 11 lines).
2 out of 12 hunks FAILED -- saving rejects to file dvbdevice.c.rej
patching file dvbdevice.h
patching file menu.c
patching file nit.c


Doesn't look too bad. You'll have to manually apply the failed hunks, though.
Whether it will actually work, I have no idea...

Klaus
  

???????????, Goga777
> ???????????, Klaus
> 
> does your vdr-1.7.1-s2api.diff good for vdr 1.7.0 ?
> 

ah, no


/vdr170# patch -p1 < vdr-1.7.1-s2api_from_Klaus.diff

patching file channels.c
Hunk #6 succeeded at 636 (offset -1 lines).
Hunk #7 succeeded at 643 (offset -1 lines).
Hunk #8 succeeded at 665 (offset -1 lines).
Hunk #9 succeeded at 685 (offset -1 lines).
patching file channels.h
Hunk #2 succeeded at 146 (offset -1 lines).
Hunk #3 succeeded at 203 (offset -2 lines).
Hunk #4 succeeded at 215 (offset -2 lines).
patching file dvbdevice.c
Hunk #7 FAILED at 265.
Hunk #8 FAILED at 323.
Hunk #9 succeeded at 407 (offset 11 lines).
Hunk #10 succeeded at 430 (offset 11 lines).
Hunk #11 succeeded at 493 (offset 11 lines).
Hunk #12 succeeded at 831 (offset 11 lines).
2 out of 12 hunks FAILED -- saving rejects to file dvbdevice.c.rej
patching file dvbdevice.h
patching file menu.c
patching file nit.c
  

> > does your vdr-1.7.1-s2api.diff good for vdr 1.7.0 ?
> 
> kls@hawk:/home/kls/vdr/vdr-1.7.0 > patch --dry-run < ../VDR/vdr-1.7.1-s2api.diff
> patching file channels.c
> Hunk #6 succeeded at 636 (offset -1 lines).
> Hunk #7 succeeded at 643 (offset -1 lines).
> Hunk #8 succeeded at 665 (offset -1 lines).
> Hunk #9 succeeded at 685 (offset -1 lines).
> patching file channels.h
> Hunk #2 succeeded at 146 (offset -1 lines).
> Hunk #3 succeeded at 203 (offset -2 lines).
> Hunk #4 succeeded at 215 (offset -2 lines).
> patching file dvbdevice.c
> Hunk #7 FAILED at 265.
> Hunk #8 FAILED at 323.
> Hunk #9 succeeded at 407 (offset 11 lines).
> Hunk #10 succeeded at 430 (offset 11 lines).
> Hunk #11 succeeded at 493 (offset 11 lines).
> Hunk #12 succeeded at 831 (offset 11 lines).
> 2 out of 12 hunks FAILED -- saving rejects to file dvbdevice.c.rej
> patching file dvbdevice.h
> patching file menu.c
> patching file nit.c
> 
> 
> Doesn't look too bad. You'll have to manually apply the failed hunks, though.
> Whether it will actually work, I have no idea...

btw - which patch are you using for h264 channels on your vdr 171 ?

Goga
  

On 06.12.2008 18:16, Goga777 wrote:
>>> does your vdr-1.7.1-s2api.diff good for vdr 1.7.0 ?
>> kls@hawk:/home/kls/vdr/vdr-1.7.0 > patch --dry-run < ../VDR/vdr-1.7.1-s2api.diff
>> patching file channels.c
>> Hunk #6 succeeded at 636 (offset -1 lines).
>> Hunk #7 succeeded at 643 (offset -1 lines).
>> Hunk #8 succeeded at 665 (offset -1 lines).
>> Hunk #9 succeeded at 685 (offset -1 lines).
>> patching file channels.h
>> Hunk #2 succeeded at 146 (offset -1 lines).
>> Hunk #3 succeeded at 203 (offset -2 lines).
>> Hunk #4 succeeded at 215 (offset -2 lines).
>> patching file dvbdevice.c
>> Hunk #7 FAILED at 265.
>> Hunk #8 FAILED at 323.
>> Hunk #9 succeeded at 407 (offset 11 lines).
>> Hunk #10 succeeded at 430 (offset 11 lines).
>> Hunk #11 succeeded at 493 (offset 11 lines).
>> Hunk #12 succeeded at 831 (offset 11 lines).
>> 2 out of 12 hunks FAILED -- saving rejects to file dvbdevice.c.rej
>> patching file dvbdevice.h
>> patching file menu.c
>> patching file nit.c
>>
>>
>> Doesn't look too bad. You'll have to manually apply the failed hunks, though.
>> Whether it will actually work, I have no idea...
> 
> btw - which patch are you using for h264 channels on your vdr 171 ?

I haven't gotten that far, yet.
So far I only watch "normal" MPEG channels.

Klaus
  

On Sat, 6 Dec 2008, Klaus Schmidinger wrote:

> If you don't want to patch the driver, you can change the line
>  case FE_QPSK: frontendType = (frontendInfo.caps & FE_CAN_2ND_GEN_MODULATION) ? SYS_DVBS2 : SYS_DVBS; break;
> in dvbdevice.c to avoid FE_CAN_2ND_GEN_MODULATION. Either set frontendType permanently
> to SYS_DVBS or SYS_DVBS2, depending on what you have.

Howabout just adding a FE_CAN_2ND_GEN_MODULATION define as a temporary 
workaroung into dvbdevice.c? It shouldn't interfere with the frontend 
capability enumeration and you'd have to patch only if you happen to 
have DVB-S2 hardware. I'm just guessing, but only a small minority of 
VDR users are having S2 capable hardware nowadays...

+ #define FE_CAN_2ND_GEN_MODULATION 0x10000000

BR,
--
rofa
  

On 07.12.2008 00:34, Rolf Ahrenberg wrote:
> On Sat, 6 Dec 2008, Klaus Schmidinger wrote:
> 
>> If you don't want to patch the driver, you can change the line
>>  case FE_QPSK: frontendType = (frontendInfo.caps & FE_CAN_2ND_GEN_MODULATION) ? SYS_DVBS2 : SYS_DVBS; break;
>> in dvbdevice.c to avoid FE_CAN_2ND_GEN_MODULATION. Either set frontendType permanently
>> to SYS_DVBS or SYS_DVBS2, depending on what you have.
> 
> Howabout just adding a FE_CAN_2ND_GEN_MODULATION define as a temporary 
> workaroung into dvbdevice.c? It shouldn't interfere with the frontend 
> capability enumeration and you'd have to patch only if you happen to 
> have DVB-S2 hardware. I'm just guessing, but only a small minority of 
> VDR users are having S2 capable hardware nowadays...
> 
> + #define FE_CAN_2ND_GEN_MODULATION 0x10000000

Sure, no problem.

Klaus
  

Just found a small flaw: the cDvbDevice::ProvidesTransponder() function
needs to be adapted to the fact that the delivery system is now an enum
and no longer a flag word:

bool cDvbDevice::ProvidesTransponder(const cChannel *Channel) const
{
  if (!ProvidesSource(Channel->Source()))
     return false; // doesn't provide source
  if (!cSource::IsSat(Channel->Source()))
     return true; // source is sufficient for non sat
  if (frontendType == SYS_DVBS && Channel->System() == SYS_DVBS2)
     return false; // requires modulation system which frontend doesn't provide
  return !Setup.DiSEqC || Diseqcs.Get(Channel->Source(), Channel->Frequency(), Channel->Polarization());
}

Maybe I'll map the SYS_DVB* stuff to a set of flags, so that these things
can be handled as comfortably as in the multiproto API...

Klaus