Rantanen Teemu wrote: > Klaus Schmidinger wrote: > >>I've said it before, and I'll repeat it: it's the broadcasters' fault! >>The PIDs must be set correctly _before_ a broadcast starts! > > > I asked once already, but you gave no answer. Sorry, I had only very little time lately to go through the VDR ML messages. There are still plenty of them in my inbox... > Could you please tell me > where in the DVB standard this is said, so I could reference it when I > report this to the broadcaster. Well, I can't quote a standard here, but I would say that plain common sense dictates that the PIDs should be set correctly (including language codes) _before_ a broadcast starts. After all, they're not likely to change right in the middle of a movie, are they? And with _before_ I'd say something in the area of a few seconds (like 5 or 10 or so), not just a few milliseconds. 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... > PS. Can PMT_SCAN_TIMEOUT have something to do with the fact that the PID > change always happens few seconds after the program has started? This timeout is only to make sure we don't wait too long on a PMT that isn't actually broadcast. You could add some logging to that 'if' branch to see whether it gets triggered by lastPmtScan being set to 0 or by an actual timeout (i.e. 'time(NULL) - lastPmtScan' being only a little more than PMT_SCAN_TIMEOUT). cPatFilter::Process() does handle only one entry at a time, but I would assume that it works fast enough. You could, though, add some debug logging to see how long it actually takes until a change in PIDs is realized. Klaus
