> > I'll try to find a "budget" card. Seems like those are a
> bit more stable, isn't it?
>
> Yes. At least there is no closed source firmware on them.
> And they are capable of capturing full transport streams
> for analysis.
>
>
> Johannes
All,
I received my brand new Hauppauge WinTV NOVA-S
Hi,
> But what is that:
>
> printf("No data within twenty seconds. Reseting the ARM\n");
> if(ioctl(frontEnd,74,NULL)==-1) {
> ERROR("Cannot reset the ARM");
> exit(-1);
> }
That was a test I did to force an ARM reset. But it didn't help. I forgot to remove
this piece of
On Tue, Apr 06, 2004 at 03:55:11PM +0200, Valsecchi Patrick wrote:
>
> A) A critical ressource is not well protected and the kernel loses
> some information about the frontend filedescriptor after some weird
> combination of operation. It's maybe due to CONFIG_PREEMPT=y.
I'm using CONFIG_PREEMPT
On Mon, Apr 05, 2004 at 08:22:22AM +0200, Valsecchi Patrick wrote:
>
> In my kind of application (monitoring) I don't really care if I loose
> some packets. Would it be possible to reset the firmware when that
> happens? That's what I wanted to try to do by closing the firmware and
> re-opening it
Oliver Endriss wrote:
> On Friday 02 April 2004 18:11, Gregor Lawatscheck wrote:
> > Yes it's possibly a firmware bug introduced after 0.9.4 because that
> +
> > release doesn't show the behavior or at least not within 1000 channel
> > chang
On Thursday 08 April 2004 08:49, Valsecchi Patrick wrote:
> > It has to be either the lack of DISEQC or is specific to your
> > card type. Oh,
> > or it could be 2.6 I suppose. Target kernel for me right now
> > is 2.4.25. I'll
> > get 2.6 going on that machine as well.
>
> This morning, I tried 2.
On Thursday 08 April 2004 08:49, Valsecchi Patrick wrote:
> > It has to be either the lack of DISEQC or is specific to your
> > card type. Oh,
> > or it could be 2.6 I suppose. Target kernel for me right now
> > is 2.4.25. I'll
> > get 2.6 going on that machine as well.
>
> This morning, I tried 2.
On Thursday 08 April 2004 07:08, Valsecchi Patrick wrote:
> > To clarify in this case, the FE_SET_FRONTEND succeeds, but
> > calling select on
> > the demuxer fails?
>
> Exactly. And I tested with the drivers in 2.6.4 and that specific problem
> doesn't happen on that version. What's weird is that
On Thursday 08 April 2004 08:49, Valsecchi Patrick wrote:
> > It has to be either the lack of DISEQC or is specific to your
> > card type. Oh,
> > or it could be 2.6 I suppose. Target kernel for me right now
> > is 2.4.25. I'll
> > get 2.6 going on that machine as well.
>
> This morning, I tried 2.
> It has to be either the lack of DISEQC or is specific to your
> card type. Oh,
> or it could be 2.6 I suppose. Target kernel for me right now
> is 2.4.25. I'll
> get 2.6 going on that machine as well.
This morning, I tried 2.4.25 with the snapshot you gave me. The two re-openning bugs
canno
> To clarify in this case, the FE_SET_FRONTEND succeeds, but
> calling select on
> the demuxer fails?
Exactly. And I tested with the drivers in 2.6.4 and that specific problem doesn't
happen on that version. What's weird is that I don't see where the dvb_frontend_poll
function may return an er
> 1) frontend lost (cannot tune) if I re-open it from the same process
> after dvb_shutdown_timeout. 2) frontend lost (operation not permitter on
> "select") if I re-open it from a another process before
> dvb_shutdown_timeout. 3) frontend lost (cannot tune) after around 1000
> tune-read cycles
[...]
> 2) frontend lost (operation not permitter on
> "select") if I re-open it from a another process before
> dvb_shutdown_timeout.
To clarify in this case, the FE_SET_FRONTEND succeeds, but calling select on
the demuxer fails?
[...]
--
Info:
To unsubscribe send a mail to [EMAIL PROTECT
> You shouldn't be able to break the driver from userspace
> though; I'll take a
> look if the snapshot I just sent you doesn't help.
Nope, exactly the same behaviour: first iteration works as a charm, second iteration
timeouts waiting for data. I've put the logs given by dvb_debug_frontend=1 a
> > Once it has gone into that bad state, how do you get it out
> > of it again? Does
> > it need a reboot, or a reload of the drivers?
>
> Restarting the process is enough. No need of re-loading the module. If you
> want, I can provide some logs with dvb-core in debug. Maybe you can look
> Thanks. I'm sorry for hassling you with that; I see from an
> earlier posting
> you have a BSRU6/TDQB-500x tuner, I should have checked back
> further in the
> list :(
No problem. That gave me the occasion to see how it's like inside the tinbox ;-)
>
> > I tried with dvb_shutdown_timeout=
On Tuesday 06 April 2004 16:08, Valsecchi Patrick wrote:
> I'm using the stv0299 driver. For the ID as printed on the device itself, I
> guess you want what's printed on the actual chip (I had to open the
> tinbox): STV0299B
> J147BEK
> J22210204
> MALTA
>
> On the tinbox, I have a sticker wi
I'm using the stv0299 driver. For the ID as printed on the device itself, I guess you
want what's printed on the actual chip (I had to open the tinbox):
STV0299B
J147BEK
J22210204
MALTA
On the tinbox, I have a sticker with "Hauppauge WinTV NEXUS version 2.1"
I tried with dvb_shutdown_tim
[...]
> 3) If I put a sleep(x) after the close, and x>dvb_shutdown_timeout then the
> next tune will fail and you see the zigzag algorithm kick in trying
> endlessly to find a signal. I've put a test software that reproduce that
> everytime in attachment.
>
> >From those 3 observations, I can gues
Hi,
I tried to use 0.9.4, but it didn't compile with my 2.4.22 kernel.
For not doing nothing while waiting my budget card, I was doing some other research
and tests. There is some interesting problems around the closing of the frontend.
Looks like things are not released correctly and some othe
AIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Gregor Lawatscheck
> Sent: Monday, April 05, 2004 5:14 PM
> To: [EMAIL PROTECTED]
> Subject: [linux-dvb] Re: stability problems + closing and
> re-opening the
> frontend
>
>
> Valsecchi Patrick wrote:
>
> > Hi
Valsecchi Patrick wrote:
Hi,
In my kind of application (monitoring) I don't really care if I loose some packets. Would it be possible to reset the firmware when that happens? That's what I wanted to try to do by closing the firmware and re-opening it.
Guido Fiala suggested over at the vdr mailing
On Friday 02 April 2004 18:11, Gregor Lawatscheck wrote:
> Yes it's possibly a firmware bug introduced after 0.9.4 because that
+
> release doesn't show the behavior or at least not within 1000 channel
> changes or signal-less operation.
> .
7:39 PM
> To: [EMAIL PROTECTED]
> Subject: [linux-dvb] Re: stability problems + closing and
> re-opening the
> frontend
>
>
> On Friday 02 April 2004 18:11, you wrote:
> > Valsecchi Patrick wrote:
> > > All,
> > >
> > > Here is the test code. It&
On Friday 02 April 2004 18:11, you wrote:
> Valsecchi Patrick wrote:
> > All,
> >
> > Here is the test code. It's butt ugly, but does the job and it's short.
> > You need a satellite tuner and need to edit the dvbBug.c file to put two
> > frequencies you have on your dish. Last run, it crashed the
Valsecchi Patrick wrote:
All,
Here is the test code. It's butt ugly, but does the job and it's short. You need a satellite tuner and need to edit the dvbBug.c file to put two frequencies you have on your dish. Last run, it crashed the ARM in 7516 iterations. So it may take some time.
Is it possi
All,
Here is the test code. It's butt ugly, but does the job and it's short. You need a
satellite tuner and need to edit the dvbBug.c file to put two frequencies you have on
your dish. Last run, it crashed the ARM in 7516 iterations. So it may take some time.
Is it possible it's a firmware bug?
27 matches
Mail list logo
