Johannes Stezenbach wrote: > Helmut Auer wrote: > >>Andreas Share wrote: >> >> >>>after tons of debug-logs i have found (maybe) the reason for the "Video >>>datastream broken" errors (and maybe UPT errors too). >>> >>>The problems, at least with my skystar2 cards, are caused by an >>>inconsistend >>>timing (different runtime) between frontend and demux ioctl´s. >> >>Are the DVB-driver developers aware of this problem ? >>I am surprised to see no comments here. For some VDR-users the UPT- or >>datastream broken error is a great pain. > > > Andreas' experimental code does arbitrary changes to certain > timings until it works for *him*. That's not a solution, but > it certainly indicates where the problem might come from. > > There were posting here suggesting bugs with vdr's handling > of FE_GET_EVENT, maybe that's the way to go? >
I've changed the FE_GET_EVENT handling in VDR to use poll() and in this case I see short 0x1f-events (FE_HAS_LOCK bit set) of abt 100ms on channels I can't tune to (I had a bogus entry in my channels.conf). The original VDR lock detection handles this as a valid lock, which is a bit sloppy in my opinion, but I would like to know if an application has to expect such "spikes" and do some filtering on frontend events? Other question: There _seems_ to be some evidence that it is dangerous if you set (change?) filters when the frontend is not locked. Could that be possible? System: 1 Nexus-s rev. 2.1, one Skystar2 rev2.6c, dvb-kernel 2.4 CVS branch. Wolfgang > Johannes > >
