marc abramson wrote: > Hello Manu and all other > > a quick explanation why switching from a channel to an other chanel or having a > signal loss and a signal back on the same chanel is NOT the same > thing (even if some STB are sending again the CA_PMT when the signal > come back). > > in a module, when a CA_PMT is received, if the module is smart and > wellwritten, the module will start by checking if the PMT is the same > than the previous one or not. If it is the same, it will NOT do > anything. > The reason why a good module will do that, instead of handling each > new CA PMT as if it the first one, is that, in this case, each time a > CA_PMT will be received, all demux filter (corresponding to the old > ca_pmt) will be closed, and all descrambler for the "old" elementary > stream will also be closed. Then, when analysing the "new" ca pmt, > everything will be reopened.. but , between the two, during a few > hundred of ms, there will be a black screen, while the descrambler > will be closed. > > Let's now imagine that the module itself is not checking the PMT > change, but sending the CA_PMT to the CA_lib (to sum up, a module is > divided in drivers, in charge of communication with the host, of the > demux , the descrambler and the smart card part, and in a CA_lib, witch is receiving > the CA_pmt - through the driver - and which is using the demux, the > descrambler and the sc driver to do the descrambling). > Then, at the ca_lib stage, the CA lib will also check if everything > has changed, or if the ES pid and the ECM PID are the same, and, once > again, if nothing has changed, not reprogram anything. > > It means that, if the driver are blocked by a signal loss (and this is > often the case with some modules), resending the same CA_PMT when the > signal come back will NOT correct anything. > Probably that explains why sometimes i had to do a retune before sending in the CA_PMT again, recovering after a signal loss. I will try out a NULL CA_PMT first before trying again.. in that case.. > during a channel switch, the module will send the new CA_PMT to the > ca_lib, and the ca_lib will see that the ES are no more the same (then > , it will close the descrambler for the old ES pid), and that the ECM > PID have also changed (then, the CA_lib will close the "old" ecm pid > filters). Then it will analyse the new ca_pmt, and reopen some demux > filter for the new ecm pid, and some descrambler channel for the new > ES. > > the only way for a host to restart correctly a module after a signal > lost will be to send 2 CA_PMT, a first one empty (that will close all > the "old" things) and then the CA_PMT. Doing that, the CA_PMT will be > handled as if it would have been the first one. > > this explain why, from time to time, after a signal loss, the > descrambling is NOT restarting, when there is never a problem when > switching from a channel to another ? > Yes, clear enough to get things moving i believe.. :-) That was a lot informative.. > please don't hesitate to ask me any question when my explanations are > not clear enough > Sure .. Thanks a lot for your input, for clearing that up. I will work out next Thursday or so and will post back, how it went.. Thanks again, Manu
