Josef Wolf wrote: > ... >>>After all, they're not likely to change right in the middle of a movie, >>>are they? > > > Oh, I would not be very surprised. Lots of movies use multiple languages. Yes, but I don't think it would make any sense to toggle the APID's language code every time a sentence in a different language is spoken ;-) >>I wouldn't expect them to change in the middle of a movie, but some >>documentaries may have interviews and actual film footage in different >>languages. > > > About two weeks ago there was a report about Einstein where repeatedly the > reporter started a sentence in german and interviewed persons fullfilled > the sentence in english. I have no clue whether the PIDs changed for that > specific report. As I said, I don't think this would make any sense. >>>But then again, most broadcasters don't even get the running >>>status in sync with the actual broadcasts, so how can we expect >>>the PIDs to be set at the right time. Seems to me like there are >>>a few monkeys sitting at a switchboard, plugging in cables randomly >>>and every once in a while hitting the right spot ;-) I always thought >>>that in today's digital playout centers things would be completely >>>computerized... > > > Klaus, are you that much convinced that the broadcasters are the problem that > you start blaming on them? Well, based on past experience I tend to ;-) > See, there might be zillions of other reasons that could lead to the > described effect. Just to name one (possible) reason: the code that > constructs tables from sections might loose sections now-and-then. Such > a bug would lead to the effect described here: > > >>When PMT_SCAN_TIMEOUT is set to the default 10 seconds there is a delay >>between event change and a PID change, as Lauri Tischler noticed. >> >>I changed the PMT_SCAN_TIMEOUT to 1. Now the delay is gone, and event >>change and possible PID change happen at the same second (based on >>syslog). > > > BTW: Why is PMT_SCAN_TIMEOUT needed at all? I have not looked at the > actual code, but the existence of such a timeout looks to me as if > someone once noticed a problem with table reconstruction code and > decided to cure the symptomps (construct table even when sections > are still missing, based on a timeout) instead of curing the real > cause (find the reason why sections get lost). Such a "cure" would > be very consistent with the effect described above. The problem is that cPatFilter::Process() processes a table of PMT PIDs and in order to do so needs to set a filter for each of the PIDs in the table. After the filter has been set, it needs to wait until the data is received. Ok, this works fine as long as it is _guaranteed_ that for every entry in the table there will be actual data broadcast. As a matter of fact, my first implementation of this stuff didn't have this timeout, and promptly got stuck on a channel that had PMT PID entries, but didn't send data for at least one of them. So I've added the PMT_SCAN_TIMEOUT, assuming that there won't be too many such broken channels, and that 10 seconds should be long enough for any data to arrive, but not too long so that things keep on running. I assume that in Teemu's case there actually is such a broken table entry, which triggers the timeout (proven by him setting PMT_SCAN_TIMEOUT to 1 and observing that the problem was gone). So I'd still guess that it's the broadcaster's fault. Maybe 10 seconds is a little long, but then again we would need to know the official repeat intervalls of this kind of data. I'm sure it's somewhere in the DVB standards, but I don't have it at hand right now. If somebody can come up with this number, I'd gladly set PMT_SCAN_TIMEOUT to a smaller value. Nevertheless, somebody should either find out why (if at all) VDR hits PMT_SCAN_TIMEOUT unjustified - or tell that broadcaster not to send broken data. Klaus
