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

[a.share@t-online.de (Andreas Share)]

> On Thursday 08 July 2004 16:23, Andreas Share wrote:
> > > On Thursday 08 July 2004 15:51, Christian Schuld wrote:
> > > > I suppose
> > > > none of the driver developers actually use such a setup with VDR
> >
> > regulary,
> >
> > > > because then it would have gotten more attention - simply because it
is
> > > > really annoying ;-)
> > >
> > > Yep it seems so :(. I posted this some weeks ago too and its an every
day
> > > question on vdr portal too, further it makes using streamdev-server
quite
> > > annoying, were it works nice otherwise .... Well i guess we did not
> >
> > complain
> >
> > > enough ...
> > >
> > > What information is needed to debug this ?
> > >
> > > Steffen
> >
> > Hi,
> >
> > i have tried to debbuging this, but at the moment without success:(
> >
> > I have used 3 different cards as 2. or 3. card, and all of them fails in
> > the same way. After some time (epg-scanning in vdr)  get no more data
from
> > the cards. No more interrupts are handled in this case.
> >
> > Setting up the filters is ok, so i think something crashed on the cards
and
> > we get no more data in the (card) buffers, or the interrupt handler does
> > not work anymore in this case.
> >
> > I have seen sync problems between the frontend threat and the demux
thread
> > also...for example vdr stops all section filter, tune und (re)start the
> > section filter, but because the demux is much faster then the frontend
> > threat this result in stopping filters, starting new filter and then
tuning
> > the card (call to fe_set_fontend in the frontend driver). Maybe some
> > invalid data caused by the tuning during running filters "kills"
something
> > in the driver or at the card.
>
> Does klaus know about this ? Can something changed inside vdr to avoid
this ?
> This is what i understood from what you have said :D, am I right ? I have
> this problem since months no matter which vdr version and this sucks.
>
> Steffen

Hi,

this is maybe one of the things who trigger this errors. I have yesterday
tested a larger delay between tuning and starting the section filter
(device.c), but without success. And, this causes some delays in displaying
the cannel infos after channel-switch and  encrypting channels.

Maybe the driver should close all filters, tune and then restart the
filters...

I have also tested "epg-scanning" without any section filter and a shorter
scan_timeout (1s), and i could not crash the skystar2 in this case (with ~
6000 channel switches in 2 hours).

Andreas