With a very recent DVB driver and hw_sections=0, it seems that
section data gets queued up and survives a channel (transponder/frequency) change.
After a channel change, a read of sections on PID 0 sometimes
return 1 and maybe even more sections from the previous channel.
With hw_sections=1 or pre-hw_sections=N versions of the driver
this doesn't happen.
When this happens, my VDR plugin for teletext subtitling (which discovers pid to listen to and teletext page number on that pid by itself) gets confused, and it also seems that VDR's eit scanner stops working (which isn't that obvious for the user though).
I made a workaround for my plugin by always reading out one section and continue reading until subsequent sections doesn't seem to have been queued up (checked with poll(x, x, 0)) before actually starting to parse any sections. This seems to work most of time. Just trying to read out the old queued data with poll(x, x, 0)+read directly after the channel change until there is no more data doesn't seem to work - it won't read any data, it rather seems that the queued up data isn't given to me until there is real new data, or something like that.
I haven't investigated the cause of this, just tried to get a grip of the behaviour and tried to make a work around to get my plugin running.
If my guesses are correct, I think we lack a buffer flush somewhere at channel changes.
/ragge
-- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
