On 20.01.2009 22:18, Oliver Endriss wrote: > Klaus Schmidinger wrote: >> On 20.01.2009 16:01, Frank Schmirler wrote: >>> On Tue, 20 Jan 2009 14:43:22 +0100, Alexw wrote >>>> I have attached a raw TS capture (~10M) containing the PMT pid 132 >>>> which is revealing the problem. >>> Hum - PID 132 is a french dolby track, not a PMT PID... >> VDR uses the (fixed) "pseudo" PMT pid 0x0084, which is 132. >> This was taken from some patch that implemented PAT/PMT handling >> (don't remember which one it was, maybe it was even the code from >> reel multimedia - not sure if I've missed mentioning that in the >> CONTRIBUTORS file). >> >> Anyway, I was already wondering if simply using some fixed PMT >> pid was such a good idea. What if some other stream uses exactly >> that pid? Apparently this is the case in this example. >> >> So I guess it will be necessary to first collect all pids and then >> check whether the default pseudo PMT pid is still free, and if >> not, incresase it until a free one is found... > > Hm - why don't you use the PID of the original PMT?
Because I don't have it ;-) It would be yet another parameter that needs to be stored in the channels.conf. I'll do it the way I mentioned, just need to give the cPatPmtGenerator the channel in the constructor so that it can choose a PMT pid that is different than any of the channel's other pids. Klaus _______________________________________________ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
