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...


vdr mailing list

Reply via email to