> I'd say it's a bug. > > Which frontend driver? > > Anyway, if it only happens once directly after open(), when initializing > the frontend, I would say it's not worth fixing.
Its _probably_ a piece of extra code I added on purpose, forgetting about nonblocking mode. Without the code, the following was happening: 1) Application opens frontend device 2) Application calls FE_SETFRONTEND 3) Application creates a TS filter and starts reading it 4) The frontend tunes the device. The problem is the device might be already tuned before step 1. In which case, the application gets some random transport stream data from the previous attempt, which was very confusing. The code forces the thread doing the tuning to do: 1) Application opens frontend device 2) Application calls FE_SETFRONTEND 3) The frontend tunes the device. 4) Application creates a TS filter and starts reading it 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? -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
