Hi Mauro,
First of all, there's no Linux DVB API v4. It was skipped, because
there
was a proposal for a v4, with was never adopted.
Alright, whatever, you have understood it was the post-V3 API, S2API,
you name it.
You should assign it a version number by the way.
Thanks for reviewing it!
Hi,
There is an ambiguity in the LinuxTV documentation about the following
ioctl's:
FE_SET_TONE, FE_SET_VOLTAGE, FE_DISEQC_SEND_BURST.
These ioctl's take an enum value as input. In the old V3 API, the
parameter
is passed by value. In the S2API documentation, it is passed by
reference.
M
> From: Andreas Oberritter [mailto:o...@linuxtv.org]
> Sent: Wednesday, January 19, 2011 7:12 PM
> To: Thierry LELEGARD
> Cc: linux-media@vger.kernel.org; Devin Heitmueller
> Subject: Re: [linux-media] API V3 vs SAPI behavior difference in reading
> tuning
> parameters
>
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
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 as used by
the driver and corresponding to the actual broadcast steam. On t
> One thing that would be good to do -- for someone who is in the
> area served by a transmitter -- rather than use «AUTO» for the
> FEC and Guard Interval values above, would be to perform a NIT
> scan on the appropriate frequencies.
>
> This should give as a result the actual transmitter frequen
g] De la part de
> Thierry LELEGARD
> Envoyé : vendredi 7 mai 2010 15:49
> À : linux-media@vger.kernel.org
> Objet : RE: cx88 pci_abort errors (Hauppauge WinTV Nova-HD-S2)
>
> Without knowing if this is appropriate or not, as a test, I replaced
> the 3 occurrences of &q
oposal. And it seems not to
be a final solution, but it just changed the behavior a little bit.
Any other idea ?
-Thierry
> -Message d'origine-
> De : linux-media-ow...@vger.kernel.org
> [mailto:linux-media-ow...@vger.kernel.org] De la part de
> Thierry LELEGARD
> Envoy
gine-
> De : Paul Shepherd [mailto:p...@whitelands.org.uk]
> Envoyé : jeudi 6 mai 2010 20:59
> À : linux-media@vger.kernel.org
> Cc : Thierry LELEGARD
> Objet : Re: cx88 pci_abort errors (Hauppauge WinTV Nova-HD-S2)
>
>
> On 06/05/2010 16:01, Thierry LELEGARD wrote:
>
Hello,
Does anyone experience pci_abort errors with the cx88 driver?
Many thanks
-Thierry
De : linux-media-ow...@vger.kernel.org
[mailto:linux-media-ow...@vger.kernel.org] De la part de Thierry LELEGARD
Envoyé : mardi 4 mai 2010 16:48
À : linux-...@linuxtv.org; linux-media@vger.kernel.org
Objet
Hello,
I recently added a Hauppauge WinTV Nova-HD-S2 into a Linux system.
I experience frequent packet loss and pci_abort errors.
Each time my application detects packet loss (continuity errors
actually),
I get the following messages in dmesg:
cx88[0]: irq mpeg [0x8] pci_abort*
cx88[0]/2-mp
> Pásztor Szilárd:
> With scan -vv I could find the video PIDs
> for the HD channels and indeed they were missing in my channels.conf (values
> were 0) as scan detected them as "OTHER", but with a "type 0x1b" addition with
> which I don't know what to do for the time being...
Stream type 0x1B prec
> De : Patrick Boettcher [mailto:patrick.boettc...@desy.de]
> Envoyé : mercredi 20 mai 2009 16:17
> À : Thierry Lelegard
> Cc : linux-media@vger.kernel.org
> Objet : Re: RE : Hauppauge Nova-TD-500 vs. T-500
>
>
> On Wed, 20 May 2009, Thierry Lelegard wrote:
> > 2)
> De : linux-media-ow...@vger.kernel.org
> [mailto:linux-media-ow...@vger.kernel.org] De la part de
> Devin Heitmueller
> Envoyé : mercredi 20 mai 2009 15:05
> À : Thierry Lelegard
> Cc : linux-media@vger.kernel.org
> Objet : Re: RE : Hauppauge Nova-TD-500 vs. T-500
>
&
dapter0/frontend0
is still there and useable in O_RDWR mode.
- Obligation to use O_RDWR mode for reading the characteristics of a device.
-Thierry
> -Message d'origine-
> De : linux-media-ow...@vger.kernel.org
> [mailto:linux-media-ow...@vger.kernel.org] De la pa
Hello,
Like many others, I have some problems with the Hauppauge Nova-TD-500.
I have been running a Fedora system with one Hauppauge Nova-T-500
(-T-, with one input connector, not -TD-) quite successfully for 2 years.
I just built another Fedora system and ordered two T-500 but I actually
receive
17 matches
Mail list logo
