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

...

...

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=30000 and dvb-s channels with sr>440000 ?

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

-----Oorspronkelijk bericht----- Van: Klaus.Schmidinger@cadsoft.de [mailto:vdr-bounces@linuxtv.org] 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

On 22.11.2008 14:17, Niels Wagenaar wrote:

...

-----Oorspronkelijk bericht----- Van: n.wagenaar@xs4all.nl [mailto:vdr-bounces@linuxtv.org] 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

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: n.wagenaar@xs4all.nl [mailto:vdr-bounces@linuxtv.org] 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

On Sat, Nov 22, 2008 at 06:21:51PM +0200, Alex Betis wrote:

On Sat, Nov 22, 2008 at 5:14 PM, Klaus Schmidinger < Klaus.Schmidinger@cadsoft.de> 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.

On Sat, Nov 22, 2008 at 6:35 PM, Klaus Schmidinger < Klaus.Schmidinger@cadsoft.de> 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 < Klaus.Schmidinger@cadsoft.de> 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

On Sat, Nov 22, 2008 at 7:00 PM, Manu Abraham abraham.manu@gmail.comwrote:

Alex Betis wrote:

...

On Sat, Nov 22, 2008 at 6:35 PM, Klaus Schmidinger < Klaus.Schmidinger@cadsoft.de> 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 < Klaus.Schmidinger@cadsoft.de> 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

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

Alex Betis wrote:

On Sat, Nov 22, 2008 at 5:14 PM, Klaus Schmidinger < Klaus.Schmidinger@cadsoft.de> 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