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@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
