Ragnar Sundblad wrote: > > --On den 11 maj 2004 23:53 +0100 Andrew de Quincey <[EMAIL PROTECTED]> > wrote: > > >However, looking back at it, I don't know if this is a good idea: (a) it > >has the nonblocking blocking issue, and (b) a multithreaded app might > >have different threads for tuning and for receiving data, in which case > >the getting-old-TS-data problem would still occur. > > > >Anyone have an opinion on whether I should remove it? > > It sounds that this fix is trying to work around bugs in > userland software. If so, I'd say lets fix the user land > software instead, and remove the fix (at least some time later, > and maybe file a bug).
Full ACK. The frontend API is specified to be asynchronous, if userland sets filters before the frontend reports successful tuning it's its own fault. IMHO the code must be removed, because some software relies on the non-blocking behaviour of FE_SET_FRONTEND. > If the fix also has something to do with the hw_sections=0 bug > (<http://www.linuxtv.org/mailinglists/linux-dvb/2003/06-2003/msg00626.html> > , > <http://www.linuxtv.org/mailinglists/linux-dvb/2003/06-2003/msg00639.html>) > I think that you should leave it in. That's the wrong way to fix it, then. IIRC I got stale data in manual testing with szap and test_sections, which indicated something like a missing ringbuffer flush. Johannes -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
