> 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