Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linux-dvb] Re: Vdr "video data stream broken"



----- Original Message ----- 
From: "Jon Burgess" <mplayer@jburgess.uklinux.net>
To: "Andreas Share" <a.share@t-online.de>
Cc: <linux-dvb@linuxtv.org>
Sent: Saturday, July 10, 2004 10:26 PM
Subject: [linux-dvb] Re: Vdr "video data stream broken"


> Andreas Share wrote:
>
> >Hi,
> >
> >I have around 1600-1800 interrupts per second, with the ss2 as secondary
> >device during epgscan.
> >
> >
> >
> OK, That is not excessive - an idle 2.6 machine has 1000 from the timer
> interrupt alone.
>
> >One other thing: The Dbox2 related Tuxbox Project share the Api3 and the
> >most of the core driver stuff with us. And they have similar problems.
> >Sometimes the boxes deliever no more audio/video, and sometimes the boxes
> >have no picture but sound at the german "ARD" channel. They have track
them
> >down to framer crashes, and i think we have the same problem. The tuxbox
now
> >check the framer status and reset it in case of a crash....
> >
> >
> >
> When I have trouble with my DXR3 ouput device I get "Buffer overflow"
> messages from VDR.
> On the full featured cards the embedded CPU is involved in both the
> input and output datapath
> so it is possible that a firmware lockup might cause the input to be lost.
> If you still receive sound then at least some of the TS is being received.
> Perhaps the filter for the video PID gets lost.

Hmm, then some channel switches should resolve this, but if "ARD" fails the
only way bring it back is a driver reload (or using transfermode from the
second card;))


> >IIRC this problems on dvb cards *and* the dbox2 was "indroduced" in API3,
so
> >i think there is a piece of code (or some timing problems) in the core
stuff
> >causes the crashes.
> >
> >Is there any way to check the framer status on the different dvb cards?
If
> >yes, we could improve the error handling in case the framer crashes.
> >
> >
> >
> I am sure something could be done, but it is best IMHO to confirm the
> cause of the problem before changing the code.

I´m agree

> For example, start playing a recording and leave it on pause overnight
> and see if it still crashes.
> If it still crashes then it is less likely to be because the framer is
> locking up.

ok, i try this.

Andreas





Home | Main Index | Thread Index