On 01/19/2011 06:03 PM, Thierry LELEGARD wrote:
> OK, then what? Is the S2API behavior (returning cached - but incorrect -
> tuning
> parameter values) satisfactory for everyone or shall we adapt S2API to mimic
> the
> API V3 behavior (return the actual tuning parameter values as automatically
>
age-
> From: linux-media-ow...@vger.kernel.org
> [mailto:linux-media-ow...@vger.kernel.org] On
> Behalf Of Thierry LELEGARD
> Sent: Friday, January 14, 2011 5:44 PM
> To: linux-media@vger.kernel.org
> Cc: Devin Heitmueller; Andreas Oberritter
> Subject: RE: [linux-media]
> -Original Message-
> From: Andreas Oberritter [mailto:o...@linuxtv.org]
> Sent: Friday, January 14, 2011 5:32 PM
> Albeit, DVB-SI data isn't perfect and misconfiguration at the
> transmitter happens (e.g. wrong FEC values), especially where most of
> the parameters are signaled in-band
On 01/14/2011 04:12 PM, Devin Heitmueller wrote:
> On Fri, Jan 14, 2011 at 8:35 AM, Thierry LELEGARD
> wrote:
>> But there is worse. If I set a wrong parameter in the tuning operation,
>> for instance guard interval 1/32, the API V3 returns the correct value
>> which is actually used by the tuner
On Fri, Jan 14, 2011 at 8:35 AM, Thierry LELEGARD
wrote:
> But there is worse. If I set a wrong parameter in the tuning operation,
> for instance guard interval 1/32, the API V3 returns the correct value
> which is actually used by the tuner (GUARD_INTERVAL_1_8), while S2API
> returns the "cached"
Hello Thierry,
On 01/14/2011 02:35 PM, Thierry LELEGARD wrote:
> Dear all,
>
> I would like to report an annoying behavior difference between S2API and the
> legacy DVB API (V3) when _reading_ the current tuning configuration.
>
> In short, API V3 is able to report the _actual_ tuning parameters