Re: [vdr] VDR -> S2API: 2 questions
Klaus Schmidinger <[EMAIL PROTECTED]> wrote: > There should be only *one* DVB driver API - anything else is rubbish. > But it should be one that is actually *useful*! really strange POV. do you also think there should only be one audio API or only one video driver interface, a.s.o ? how do you think progress can ever be made when you don't allow diversity. what you call *working* and *useful* may be a dead end and obsolete in a few month/years. only time will tell. if dvb was not built into vdr core, then you wouldn't even have to bother. best regards ... clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR -> S2API: 2 questions
On 22.11.2008 20:26, Alex Betis wrote: > > ... > Lets not start that fire again, from my experience mostly innocent > people gets hurt from it. I'm not sure if it was such a wise decision to go S2API. An API that isn't even capable of telling an application whether or not a device can handle DVB-S2 shouldn't even carry "S2" in its name. > As someone new to DVB implementation who joined the ride when both S2API > and multiproto are already available I see some benefits and drawbacks > in both of them. From my perspective I see S2API best benefit is the > 'API' itself and its flexibility, while multiproto has its respectful > 'flight hours' and more implemented features. That's probably a matter > of time and efforts while more features will be implemented in S2API > that will make everybody happy. > It was decided already to move to S2API and as I see from the lists and > patches flying around many people are very interested in it. > We probably all agree that S2API is not mature enough for all the cases. > > I didn't look in the VDR code yet, but I think it might be a good idea > to have a layer that will handle the interface to the device and hide > all those changes to the rest of the application. Since VDR is written > in C++, that shouldn't be too complicate to achieve. And will allow easy > switch to S2API (or any other in the future), while still maintainging > the multiproto interface. There should be only *one* DVB driver API - anything else is rubbish. But it should be one that is actually *useful*! Ok, it has been decided not to use the working API, but rather use a non working one. Ok, that's politics, and I don't give a rat's ass about politics. The way it looks to me we're stuck with S2API, so now I'd say those favoring this API should see that it can tell an application whether a particular device supports DVB-S2 or not. I don't think that's asking too much, is it? > Regarding the resource decisions: > I see a strong point to move the decision to configuration file and not > rely only on device reported capabilities. > Here is an example: > Several cards are in one PC, all DVB-S2 from different vendors, while > one of them is not that good handling S2 streams (lets say a driver > problems that suppose to be resolved), so the user might want to force > that card to be used for DVB-S channels only, regardless the reported > DVB-S2 support. > To get even further with the example, stb0899 cards are known not to > lock on all DVB-S2 channels and not work well with different symbol > rates, so I might want to have per-channel decision configuration so > those problematic channels will be handled by another card, while all > other DVB-S and DVB-S2 channels would be handled by all cards. Sorry, but I disagree. If there is a problem, it should be solved in the driver, not in the application. And if a DVB device doesn't work as it should, return it to the shop an get your money back ;-) I have posted "How to determine DVB-S2 capability in S2API?" on the linux-dvb ML, but so far nobody has suggested how to do it. So I guess this really isn't possible. I really don't get it... Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR -> S2API: 2 questions
Alex Betis wrote: > On Sat, Nov 22, 2008 at 7:00 PM, Manu Abraham <[EMAIL PROTECTED]>wrote: > >> Alex Betis wrote: >>> On Sat, Nov 22, 2008 at 6:35 PM, Klaus Schmidinger < >>> [EMAIL PROTECTED]> wrote: >>> On 22.11.2008 17:25, Georg Acher wrote: > On Sat, Nov 22, 2008 at 06:21:51PM +0200, Alex Betis wrote: >> On Sat, Nov 22, 2008 at 5:14 PM, Klaus Schmidinger < >> [EMAIL PROTECTED]> wrote: >> >>> Maybe I'm totally missing something here, but I can't figure out how >>> an application using the S2API driver can tell whether a DVB device >> is >>> DVB-S or DVB-S2. Can somebody please point me in the right direction here? >> I run into the same question when made changes in scan-s2 application. >> The question I want to ask is why do you really need it? >> >> In a DVB-S2 demodulator, according to ETSI specifications, and according >> to the manufacturers, there are 2 demodulators, A DVB-S demodulator and >> a DVB-S2 demodulator. So with 2 demodulators, you have 2 distinct paths. >> >> With these 2 distinct paths, you need a flag, aka a delivery system >> notation, to select the path as well as a "holder" to hold common >> delivery system specifics. This is the whole difference between >> multiproto and S2API. >> >> S2API depends on a flat concept where it assumes a single demodulator, >> ie the concept of a delivery system doesn't exist there. >> >> Expect more fun when there are newer delivery systems which are going to >> define backward compatibility stuff, ie when vendors do start to >> implement backward compatible stuff in hardware, similar to DVB-S2 >> >> It is just a matter of time, till the more advanced features are >> implemented practically by more broadcasters, rather than the few >> experimental ones. >> >> I guess, there is more to come. >> > Guys, > > Lets not start that fire again, from my experience mostly innocent people > gets hurt from it. It is not about any fire, but about what really is at large. > As someone new to DVB implementation who joined the ride when both S2API and > multiproto are already available I see some benefits and drawbacks in both > of them. From my perspective I see S2API best benefit is the 'API' itself > and its flexibility, while multiproto has its respectful 'flight hours' and > more implemented features. That's probably a matter of time and efforts > while more features will be implemented in S2API that will make everybody > happy. > It was decided already to move to S2API and as I see from the lists and > patches flying around many people are very interested in it. > We probably all agree that S2API is not mature enough for all the cases. The problem is that, once an untested API makes it upstream, it is really hard after that. Don't know how many people realize that ... Regards, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR -> S2API: 2 questions
On Sat, Nov 22, 2008 at 7:00 PM, Manu Abraham <[EMAIL PROTECTED]>wrote: > Alex Betis wrote: > > On Sat, Nov 22, 2008 at 6:35 PM, Klaus Schmidinger < > > [EMAIL PROTECTED]> wrote: > > > >> On 22.11.2008 17:25, Georg Acher wrote: > >>> On Sat, Nov 22, 2008 at 06:21:51PM +0200, Alex Betis wrote: > On Sat, Nov 22, 2008 at 5:14 PM, Klaus Schmidinger < > [EMAIL PROTECTED]> wrote: > > > Maybe I'm totally missing something here, but I can't figure out how > > an application using the S2API driver can tell whether a DVB device > is > > DVB-S or DVB-S2. Can somebody please point me in the right direction > >> here? > I run into the same question when made changes in scan-s2 application. > The question I want to ask is why do you really need it? > > > In a DVB-S2 demodulator, according to ETSI specifications, and according > to the manufacturers, there are 2 demodulators, A DVB-S demodulator and > a DVB-S2 demodulator. So with 2 demodulators, you have 2 distinct paths. > > With these 2 distinct paths, you need a flag, aka a delivery system > notation, to select the path as well as a "holder" to hold common > delivery system specifics. This is the whole difference between > multiproto and S2API. > > S2API depends on a flat concept where it assumes a single demodulator, > ie the concept of a delivery system doesn't exist there. > > Expect more fun when there are newer delivery systems which are going to > define backward compatibility stuff, ie when vendors do start to > implement backward compatible stuff in hardware, similar to DVB-S2 > > It is just a matter of time, till the more advanced features are > implemented practically by more broadcasters, rather than the few > experimental ones. > > I guess, there is more to come. > Guys, Lets not start that fire again, from my experience mostly innocent people gets hurt from it. As someone new to DVB implementation who joined the ride when both S2API and multiproto are already available I see some benefits and drawbacks in both of them. From my perspective I see S2API best benefit is the 'API' itself and its flexibility, while multiproto has its respectful 'flight hours' and more implemented features. That's probably a matter of time and efforts while more features will be implemented in S2API that will make everybody happy. It was decided already to move to S2API and as I see from the lists and patches flying around many people are very interested in it. We probably all agree that S2API is not mature enough for all the cases. I didn't look in the VDR code yet, but I think it might be a good idea to have a layer that will handle the interface to the device and hide all those changes to the rest of the application. Since VDR is written in C++, that shouldn't be too complicate to achieve. And will allow easy switch to S2API (or any other in the future), while still maintainging the multiproto interface. Regarding the resource decisions: I see a strong point to move the decision to configuration file and not rely only on device reported capabilities. Here is an example: Several cards are in one PC, all DVB-S2 from different vendors, while one of them is not that good handling S2 streams (lets say a driver problems that suppose to be resolved), so the user might want to force that card to be used for DVB-S channels only, regardless the reported DVB-S2 support. To get even further with the example, stb0899 cards are known not to lock on all DVB-S2 channels and not work well with different symbol rates, so I might want to have per-channel decision configuration so those problematic channels will be handled by another card, while all other DVB-S and DVB-S2 channels would be handled by all cards. > Regards, > Manu > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR -> S2API: 2 questions
Alex Betis wrote: > On Sat, Nov 22, 2008 at 6:35 PM, Klaus Schmidinger < > [EMAIL PROTECTED]> wrote: > >> On 22.11.2008 17:25, Georg Acher wrote: >>> On Sat, Nov 22, 2008 at 06:21:51PM +0200, Alex Betis wrote: On Sat, Nov 22, 2008 at 5:14 PM, Klaus Schmidinger < [EMAIL PROTECTED]> wrote: > Maybe I'm totally missing something here, but I can't figure out how > an application using the S2API driver can tell whether a DVB device is > DVB-S or DVB-S2. Can somebody please point me in the right direction >> here? I run into the same question when made changes in scan-s2 application. The question I want to ask is why do you really need it? In a DVB-S2 demodulator, according to ETSI specifications, and according to the manufacturers, there are 2 demodulators, A DVB-S demodulator and a DVB-S2 demodulator. So with 2 demodulators, you have 2 distinct paths. With these 2 distinct paths, you need a flag, aka a delivery system notation, to select the path as well as a "holder" to hold common delivery system specifics. This is the whole difference between multiproto and S2API. S2API depends on a flat concept where it assumes a single demodulator, ie the concept of a delivery system doesn't exist there. Expect more fun when there are newer delivery systems which are going to define backward compatibility stuff, ie when vendors do start to implement backward compatible stuff in hardware, similar to DVB-S2 It is just a matter of time, till the more advanced features are implemented practically by more broadcasters, rather than the few experimental ones. I guess, there is more to come. Regards, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR -> S2API: 2 questions
Alex Betis wrote: > On Sat, Nov 22, 2008 at 5:14 PM, Klaus Schmidinger < > [EMAIL PROTECTED]> wrote: > >> Maybe I'm totally missing something here, but I can't figure out how >> an application using the S2API driver can tell whether a DVB device is >> DVB-S or DVB-S2. Can somebody please point me in the right direction here? >> > I run into the same question when made changes in scan-s2 application. > The question I want to ask is why do you really need it? > Even if the card is DVB-S2, you have to specify DVB-S delivery system when > you intend to lock on DVB-S channel. > I assume that specifying DVB-S2 delivery for DVB-S card should be rejected > by the driver. > So I don't see a real problem here. The application should follow the > channels file, the "S0" or "S1" parameter that specify the delivery system. Nah, there is an even larger problem: DVB-S2 implies a max Srate = 30MSPS and DVB-S implies max srate = 45MSPS. There are quite a load of nasty quirks like that with the current API. Another one is that, the user application will never know whether a tuning failed or not. Well, most of those application developers did want those quirks and hence we do have them. Interesting, isn't it ? Regards, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR -> S2API: 2 questions
On Sat, Nov 22, 2008 at 6:35 PM, Klaus Schmidinger < [EMAIL PROTECTED]> wrote: > On 22.11.2008 17:25, Georg Acher wrote: > > On Sat, Nov 22, 2008 at 06:21:51PM +0200, Alex Betis wrote: > >> On Sat, Nov 22, 2008 at 5:14 PM, Klaus Schmidinger < > >> [EMAIL PROTECTED]> wrote: > >> > >>> Maybe I'm totally missing something here, but I can't figure out how > >>> an application using the S2API driver can tell whether a DVB device is > >>> DVB-S or DVB-S2. Can somebody please point me in the right direction > here? > >>> > >> I run into the same question when made changes in scan-s2 application. > >> The question I want to ask is why do you really need it? > > > > Ressource allocation. If there is also a S-only tuner avaliable you don't > > want to waste the precious S2-tuner for S-stuff. Also it can be important > > for timer collision checking. > > Exactly. If a channel is DVB-S2, I don't even want to try a DVB-S only > card. Good point. Lets wait for someone on dvb list to answer. > > > Am I really to believe that S2API doesn't provide that information? > If so, what exactly does the "S2" in "S2API" stand for? ;-) > > Klaus > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR -> S2API: 2 questions
On 22.11.2008 17:25, Georg Acher wrote: > On Sat, Nov 22, 2008 at 06:21:51PM +0200, Alex Betis wrote: >> On Sat, Nov 22, 2008 at 5:14 PM, Klaus Schmidinger < >> [EMAIL PROTECTED]> wrote: >> >>> Maybe I'm totally missing something here, but I can't figure out how >>> an application using the S2API driver can tell whether a DVB device is >>> DVB-S or DVB-S2. Can somebody please point me in the right direction here? >>> >> I run into the same question when made changes in scan-s2 application. >> The question I want to ask is why do you really need it? > > Ressource allocation. If there is also a S-only tuner avaliable you don't > want to waste the precious S2-tuner for S-stuff. Also it can be important > for timer collision checking. Exactly. If a channel is DVB-S2, I don't even want to try a DVB-S only card. Am I really to believe that S2API doesn't provide that information? If so, what exactly does the "S2" in "S2API" stand for? ;-) Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR -> S2API: 2 questions
On Sat, Nov 22, 2008 at 06:21:51PM +0200, Alex Betis wrote: > On Sat, Nov 22, 2008 at 5:14 PM, Klaus Schmidinger < > [EMAIL PROTECTED]> wrote: > > > Maybe I'm totally missing something here, but I can't figure out how > > an application using the S2API driver can tell whether a DVB device is > > DVB-S or DVB-S2. Can somebody please point me in the right direction here? > > > I run into the same question when made changes in scan-s2 application. > The question I want to ask is why do you really need it? Ressource allocation. If there is also a S-only tuner avaliable you don't want to waste the precious S2-tuner for S-stuff. Also it can be important for timer collision checking. -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher "Oh no, not again !" The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR -> S2API: 2 questions
On Sat, Nov 22, 2008 at 5:14 PM, Klaus Schmidinger < [EMAIL PROTECTED]> wrote: > Maybe I'm totally missing something here, but I can't figure out how > an application using the S2API driver can tell whether a DVB device is > DVB-S or DVB-S2. Can somebody please point me in the right direction here? > I run into the same question when made changes in scan-s2 application. The question I want to ask is why do you really need it? Even if the card is DVB-S2, you have to specify DVB-S delivery system when you intend to lock on DVB-S channel. I assume that specifying DVB-S2 delivery for DVB-S card should be rejected by the driver. So I don't see a real problem here. The application should follow the channels file, the "S0" or "S1" parameter that specify the delivery system. Best regards, Alex. > > Klaus > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR -> S2API: 2 questions
On 22.11.2008 15:56, Klaus Schmidinger wrote:
> On 22.11.2008 15:47, Klaus Schmidinger wrote:
>> On 22.11.2008 14:17, Niels Wagenaar wrote:
>>>> -Oorspronkelijk bericht-
>>>> Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Niels
>>>> Wagenaar
>>>> Verzonden: zaterdag 22 november 2008 14:13
>>>> Aan: VDR Mailing List
>>>> Onderwerp: Re: [vdr] VDR -> S2API: 2 questions
>>>>
>>>> The patch from 7-10 is indeed the latest. There weren't any changes in
>>>> S2API in the last weeks, which would or could my VDR/S2API patch.
>>>>
>>> (Damn Send button!)
>>>
>>> Which would or could break my VDR/S2API patch ;-)
>>>
>>> BTW, only DVB-S, DVB-S2 and DVB-T is really tested by me (and with great
>>> success). The DVB-C code is theory and untested.
>> This part of your patch is a little irritating:
>>
>> - if (ioctl(fd_frontend, DVBFE_GET_DELSYS, &frontendType) >= 0) {
>> +// if (ioctl(fd_frontend, DVBFE_GET_DELSYS, &frontendType) >= 0) {
>> + dvb_frontend_info feinfo;
>> + fe_type fetype;
>> + if (ioctl(fd_frontend, FE_GET_INFO, &feinfo) >= 0) {
>> +fetype = feinfo.type;
>> +if (fetype == FE_QPSK)
>> +frontendType = SYS_DVBS;
>> +if (fetype == FE_OFDM)
>> +frontendType = SYS_DVBT;
>> +if (fetype == FE_QAM)
>> +frontendType = SYS_DVBC_ANNEX_AC;
>> +if (fetype == FE_ATSC)
>> +frontendType = SYS_ATSC;
>> +
>> const char **DeliverySystem = DeliverySystems;
>> cString ds;
>> + cString check;
>> for (int i = 0; i < 32; i++) {
>> if (frontendType & (1u << i)) {
>> numProvidedSystems++;
>>
>>
>> In the multiproto driver, frontendType was a flag variable, where each bit
>> indicated the presence of a particular frontend. That way DVB cards with
>> different frontends were able to report all the frontend types they
>> provide.
>>
>> In S2API this is apparently an enum type, so the subsequent flag checking
>> makes
>> no sense any more. Or am I missing something?
>>
>> How does a DVB device tell the application about its frontend types in S2API?
>
> One more thing:
>
> + // Following is a hack so that DVB-S cards don't get DVB-S2
> transports.
> + // If check has a value and is not NULL, it means that the card can
> handle
> + // DVB-S2 transports and frontendType is forces to SYS_DVBS2.
> + check = strstr(ds,"DVBS2");
> + if (*check)
> + {
> + isyslog("device %d forced to frontendType SYS_DVBS2\n",
> CardIndex() + 1);
> + frontendType = SYS_DVBS2;
> + }
>
> How would "DVBS2" ever get into the ds string?
> The flag checks are completely bogus, and the explicit setting of frontendType
> above only sets SYS_DVBS, and not SYS_DVBS2.
Maybe I'm totally missing something here, but I can't figure out how
an application using the S2API driver can tell whether a DVB device is
DVB-S or DVB-S2. Can somebody please point me in the right direction here?
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR -> S2API: 2 questions
On 22.11.2008 15:47, Klaus Schmidinger wrote:
> On 22.11.2008 14:17, Niels Wagenaar wrote:
>>> -Oorspronkelijk bericht-
>>> Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Niels
>>> Wagenaar
>>> Verzonden: zaterdag 22 november 2008 14:13
>>> Aan: VDR Mailing List
>>> Onderwerp: Re: [vdr] VDR -> S2API: 2 questions
>>>
>>> The patch from 7-10 is indeed the latest. There weren't any changes in
>>> S2API in the last weeks, which would or could my VDR/S2API patch.
>>>
>> (Damn Send button!)
>>
>> Which would or could break my VDR/S2API patch ;-)
>>
>> BTW, only DVB-S, DVB-S2 and DVB-T is really tested by me (and with great
>> success). The DVB-C code is theory and untested.
>
> This part of your patch is a little irritating:
>
> - if (ioctl(fd_frontend, DVBFE_GET_DELSYS, &frontendType) >= 0) {
> +// if (ioctl(fd_frontend, DVBFE_GET_DELSYS, &frontendType) >= 0) {
> + dvb_frontend_info feinfo;
> + fe_type fetype;
> + if (ioctl(fd_frontend, FE_GET_INFO, &feinfo) >= 0) {
> +fetype = feinfo.type;
> +if (fetype == FE_QPSK)
> +frontendType = SYS_DVBS;
> +if (fetype == FE_OFDM)
> +frontendType = SYS_DVBT;
> +if (fetype == FE_QAM)
> +frontendType = SYS_DVBC_ANNEX_AC;
> +if (fetype == FE_ATSC)
> +frontendType = SYS_ATSC;
> +
> const char **DeliverySystem = DeliverySystems;
> cString ds;
> + cString check;
> for (int i = 0; i < 32; i++) {
> if (frontendType & (1u << i)) {
> numProvidedSystems++;
>
>
> In the multiproto driver, frontendType was a flag variable, where each bit
> indicated the presence of a particular frontend. That way DVB cards with
> different frontends were able to report all the frontend types they
> provide.
>
> In S2API this is apparently an enum type, so the subsequent flag checking
> makes
> no sense any more. Or am I missing something?
>
> How does a DVB device tell the application about its frontend types in S2API?
One more thing:
+ // Following is a hack so that DVB-S cards don't get DVB-S2 transports.
+ // If check has a value and is not NULL, it means that the card can
handle
+ // DVB-S2 transports and frontendType is forces to SYS_DVBS2.
+ check = strstr(ds,"DVBS2");
+ if (*check)
+ {
+ isyslog("device %d forced to frontendType SYS_DVBS2\n", CardIndex()
+ 1);
+ frontendType = SYS_DVBS2;
+ }
How would "DVBS2" ever get into the ds string?
The flag checks are completely bogus, and the explicit setting of frontendType
above only sets SYS_DVBS, and not SYS_DVBS2.
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR -> S2API: 2 questions
On 22.11.2008 14:17, Niels Wagenaar wrote:
>> -Oorspronkelijk bericht-
>> Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Niels
>> Wagenaar
>> Verzonden: zaterdag 22 november 2008 14:13
>> Aan: VDR Mailing List
>> Onderwerp: Re: [vdr] VDR -> S2API: 2 questions
>>
>> The patch from 7-10 is indeed the latest. There weren't any changes in
>> S2API in the last weeks, which would or could my VDR/S2API patch.
>>
>
> (Damn Send button!)
>
> Which would or could break my VDR/S2API patch ;-)
>
> BTW, only DVB-S, DVB-S2 and DVB-T is really tested by me (and with great
> success). The DVB-C code is theory and untested.
This part of your patch is a little irritating:
- if (ioctl(fd_frontend, DVBFE_GET_DELSYS, &frontendType) >= 0) {
+// if (ioctl(fd_frontend, DVBFE_GET_DELSYS, &frontendType) >= 0) {
+ dvb_frontend_info feinfo;
+ fe_type fetype;
+ if (ioctl(fd_frontend, FE_GET_INFO, &feinfo) >= 0) {
+fetype = feinfo.type;
+if (fetype == FE_QPSK)
+frontendType = SYS_DVBS;
+if (fetype == FE_OFDM)
+frontendType = SYS_DVBT;
+if (fetype == FE_QAM)
+frontendType = SYS_DVBC_ANNEX_AC;
+if (fetype == FE_ATSC)
+frontendType = SYS_ATSC;
+
const char **DeliverySystem = DeliverySystems;
cString ds;
+ cString check;
for (int i = 0; i < 32; i++) {
if (frontendType & (1u << i)) {
numProvidedSystems++;
In the multiproto driver, frontendType was a flag variable, where each bit
indicated the presence of a particular frontend. That way DVB cards with
different frontends were able to report all the frontend types they
provide.
In S2API this is apparently an enum type, so the subsequent flag checking makes
no sense any more. Or am I missing something?
How does a DVB device tell the application about its frontend types in S2API?
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR -> S2API: 2 questions
> -Oorspronkelijk bericht- > Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Niels > Wagenaar > Verzonden: zaterdag 22 november 2008 14:13 > Aan: VDR Mailing List > Onderwerp: Re: [vdr] VDR -> S2API: 2 questions > > The patch from 7-10 is indeed the latest. There weren't any changes in > S2API in the last weeks, which would or could my VDR/S2API patch. > (Damn Send button!) Which would or could break my VDR/S2API patch ;-) BTW, only DVB-S, DVB-S2 and DVB-T is really tested by me (and with great success). The DVB-C code is theory and untested. Regards, Niels Wagenaar ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR -> S2API: 2 questions
> -Oorspronkelijk bericht- > Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Namens Klaus Schmidinger > Verzonden: zaterdag 22 november 2008 14:07 > Aan: vdr@linuxtv.org > Onderwerp: Re: [vdr] VDR -> S2API: 2 questions > > -- SNIP -- > > Looks like there is also a newer patch posted in > > [vdr] [PATCH] S2API for vdr-1.7.0 (07-10-2008 - quickhack for DVB- > S(2), DVB-T and DVB-C) > Correct. > on 07.10.2008 21:09 by Niels Wagenaar. > > @Niels: can you confirm that vdr-1.7.0-s2api-07102008-h264-clean.patch > is your "latest, greatest" S2API patch for VDR? > The patch from 7-10 is indeed the latest. There weren't any changes in S2API in the last weeks, which would or could my VDR/S2API patch. > Klaus > Regards, Niels Wagewnaar ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR -> S2API: 2 questions
On 22.11.2008 11:46, Goga777 wrote: >> ... >> - Is there a patch available that implements the S2API changes into >> VDR? I've seen some postings about such a patch, but IIRC it also >> containes several other things that are unrelated to the plain S2API >> change. > > for vdr 170 it's s2api patch from Niels Wagenaar > http://www.linuxtv.org/pipermail/vdr/2008-October/017964.html > it is working perfectly on my vdr 170 Looks like there is also a newer patch posted in [vdr] [PATCH] S2API for vdr-1.7.0 (07-10-2008 - quickhack for DVB-S(2), DVB-T and DVB-C) on 07.10.2008 21:09 by Niels Wagenaar. @Niels: can you confirm that vdr-1.7.0-s2api-07102008-h264-clean.patch is your "latest, greatest" S2API patch for VDR? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR -> S2API: 2 questions
> >> After quite a while away from VDR development, I've dedicated > >> this weekend to switching VDR to S2API (TS recording will be postponed). > >> > >> Just two quick questions: > >> > >> - Where do I find the ultimate, latest, greatest S2API driver source? > >> I would assume it is at http://linuxtv.org/hg/v4l-dvb, but with all > >> the recent patching and various repositories, I'm unsure... > > > > imho, http://mercurial.intuxication.org/hg/s2-liplianin/ also good choise. > > Igor has implemented some improvements in drivers, that's why with > > s2-liplianin possible to work with dvb-s/svb-s2 channels which have high > > and low SR. I don't know why these improvements didn't include in v4l-dvb > > tree. > > People using some STB0899 versions will have their demodulators burned > due to the demodulator running with a too high unsupported clock of > 135MHz. The STB0899 is rated to run at a maximum of 99 MHz only. > > The safe bet is to use http://linuxtv.org/hg/v4l-dvb Manu with http://linuxtv.org/hg/v4l-dvb is it possible to lock dvb-s2 8psk channels with sr=3 and dvb-s channels with sr>44 ? of course, the safety is first, nobody want to burn the dvb card. But which solution do you propose for owners of stb0899 cards and who want to see the dvb-s/dvb-s2 channels with low/high SR ? to sell stb0899 based cards and to buy cx24116 based card ? Goga ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR -> S2API: 2 questions
On 22.11.2008 12:04, Manu Abraham wrote: > Goga777 wrote: >>> After quite a while away from VDR development, I've dedicated >>> this weekend to switching VDR to S2API (TS recording will be postponed). >>> >>> Just two quick questions: >>> >>> - Where do I find the ultimate, latest, greatest S2API driver source? >>> I would assume it is at http://linuxtv.org/hg/v4l-dvb, but with all >>> the recent patching and various repositories, I'm unsure... >> imho, http://mercurial.intuxication.org/hg/s2-liplianin/ also good choise. >> Igor has implemented some improvements in drivers, that's why with >> s2-liplianin possible to work with dvb-s/svb-s2 channels which have high and >> low SR. I don't know why these improvements didn't include in v4l-dvb tree. > > People using some STB0899 versions will have their demodulators burned > due to the demodulator running with a too high unsupported clock of > 135MHz. The STB0899 is rated to run at a maximum of 99 MHz only. > > The safe bet is to use http://linuxtv.org/hg/v4l-dvb Thanks a lot, that's good to know! I'd hate to fry my DVB cards ;-) Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR -> S2API: 2 questions
Goga777 wrote: >> After quite a while away from VDR development, I've dedicated >> this weekend to switching VDR to S2API (TS recording will be postponed). >> >> Just two quick questions: >> >> - Where do I find the ultimate, latest, greatest S2API driver source? >> I would assume it is at http://linuxtv.org/hg/v4l-dvb, but with all >> the recent patching and various repositories, I'm unsure... > > imho, http://mercurial.intuxication.org/hg/s2-liplianin/ also good choise. > Igor has implemented some improvements in drivers, that's why with > s2-liplianin possible to work with dvb-s/svb-s2 channels which have high and > low SR. I don't know why these improvements didn't include in v4l-dvb tree. People using some STB0899 versions will have their demodulators burned due to the demodulator running with a too high unsupported clock of 135MHz. The STB0899 is rated to run at a maximum of 99 MHz only. The safe bet is to use http://linuxtv.org/hg/v4l-dvb Regards, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR -> S2API: 2 questions
> After quite a while away from VDR development, I've dedicated > this weekend to switching VDR to S2API (TS recording will be postponed). > > Just two quick questions: > > - Where do I find the ultimate, latest, greatest S2API driver source? > I would assume it is at http://linuxtv.org/hg/v4l-dvb, but with all > the recent patching and various repositories, I'm unsure... imho, http://mercurial.intuxication.org/hg/s2-liplianin/ also good choise. Igor has implemented some improvements in drivers, that's why with s2-liplianin possible to work with dvb-s/svb-s2 channels which have high and low SR. I don't know why these improvements didn't include in v4l-dvb tree. > - Is there a patch available that implements the S2API changes into > VDR? I've seen some postings about such a patch, but IIRC it also > containes several other things that are unrelated to the plain S2API > change. for vdr 170 it's s2api patch from Niels Wagenaar http://www.linuxtv.org/pipermail/vdr/2008-October/017964.html it is working perfectly on my vdr 170 Goga ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
