Felix Domke wrote: > Manu Abraham wrote: >>Felix Domke wrote: >>>>>At least, there is actually a TS where all channels (with different >>>>>sid) point to the same PMT. >>>>Strictly speaking service ID is unique within a transponder.. But there >>>>could be cases of violation too.. >>>>But in this case, how do you proceed ? based upon program number ? >>>Having multiple services with different SIDs and same PMT-PIDs is not a >>>problem at all. >>>The PMT has the sid (or "program number") in their "table id extension" >>>field, so you should filter for it (in any case). Then you get the >>>correct PMT. It's even allowed in the standard, i think (though i have >>>no quote to proove it at the moment) >>No, i am doing that at present, filter by service_id and table_id_ext.. >>Needed to know whether it could go wrong in the cases when service_id is >>junk as was discussed previously.. > Sorry, was meant as a response to the "having different SIDs each point > to the same PMT". > > In the other case (which i don't believe to exists, at least not for > more than a day ;), since it would simply not work at all, thus wasting > expensive bandwidth), yes, there's no way to recover. > So i believe we don't have a problem/ or a much better way of doing things regarding that aspect .. > Sure, you could rely on the order in the PAT, but that's too ugly. In > these cases, you should drop the PAT/PMT and use plain ES pids for zapping. the ES PID's are kind of optional in the config, in the sense you require them for faster zaps, but would work without them too, ie, could be obtained from the initial PAT/PMT parsed cached data. The original idea that we discussed was to cache the parsed data and write ES info back to config for faster zaps... Manu
