Camd.socket issues, a new CaPMT interface
In the old camd.socket implementation (called clientPMT) softcams play a server role to which enigma (the client) needs to connect. This has the disadvantage that enigma endlessly needs to poll for the existance of camd.socket. Also, when enigma has sent the pmt data and the softcam is somehow stopped and restarted (or a different softcam is started), the PMT data is not resent. A zap is needed to send new pmt data.
Connection loss
A connection loss-detect mechanism has been implemented to remove this need for a channel change on swap/restart of the softcam. Enigma dectects when the connection to the camd.socket is lost and starts retrying. As soon as a softcam sets up camd.socket again, enigma will immediately connect and resend the pmt data. This method also provides transparent softcam changes!
However, some softcams do not adapt to this principle flawlessly yet, as they close connections as soon as the PMT data has been sent. Enigma sees this as connection loss and retries to connect to the softcam. The softcam will accept the connection, believing it will receive new PMT data (e.g. thinks a zap has been done).
In itself this is not a big problem, but when the user has selected OSD output on channel changes he will get repeated OSD messages which will become quite annoying after a while.
Note: when no softcam is running, enigma still tries to connect to /tmp/camd.socket. It will retry this every 5 seconds perpetually.
The new CaPMT interface
A new PMT interface has been developed, called serverPMT. In this interface the server/client role is reversed. Enigma now acts as a server, to which softcams (now clients) can connect to receive PMT information. This allows for faster ZTI times (zap to image). Measurements show that passing PMT information from enigma to the softcam takes 16 to 32 millisends in the old clientPMT interface. With the new serverPMT interface it just takes 2 milliseconds (obviously, there is still the wait for the softcam to initiate descrambling before you get proper view.)
Additionally, this results in immediate view when a softcam is started while enigma is already running (eliminating the need of the 'autozap' feature). This is implemented using the CA/CI interface, which is adapted to work for softcams. Switching softcams becomes practically transparent in this sense, as long as the current ECM interval is not ended during startuptime of the new softcam.
The serverPMT interface is a nice and clean interface. Enigma will become passive and will not actively try to make a camd.cocket connection. Since it now plays a server role, many external programs are able to receive PMT data at the same time, making it possible to build a very simple daemon to manage sticky softcams per channel/provider or other tools that can make use of PMT data.
The new interface sets up the /tmp/.listen.camd.socket and waits for connections to it. A softcam should connect to this socket and leave it open. As soon as enigma detects the connection to the socket it will send CAPMT data in the same format as in the camd.socket way. When somehow the connection is lost (on enigma crashes for example) the softcam should periodically (every second for example) try to reconnect to the socket.
The interface will use the list_management flag to indicate CAPMT data for more services is sent. Clients should check the ca_pmt_list_management field in the CAPMT objects, to determine whether an object is the first or last object in the list, an object in the middle, or perhaps an update for an existing service. By doing this softcams can implement support for recording services while viewing another. Furthermore softcams can check the cmd_id, to determine the function of the receiver CAPMT.
ca_pmt_list_management values:
#define LIST_MORE 0x00
CA application should append a 'MORE' CAPMT object the list and start receiving the next object#define LIST_FIRST 0x01
CA application should clear the list when a 'FIRST' CAPMT object is received, and start receiving the next object#define LIST_LAST 0x02
CA application should append a 'LAST' CAPMT object to the list and start working with the list#define LIST_ONLY 0x03
CA application should clear the list when an 'ONLY' CAPMT object is received, and start working with the object#define LIST_ADD 0x04
CA application should append an 'ADD' CAPMT object to the current list and start working with the updated list#define LIST_UPDATE 0x05
CA application should replace an entry in the list with an 'UPDATE' CAPMT object, and start working with the updated listca_pmt_cmd_id values:
#define CMD_OK_DESCRAMBLING 0x01
CA application should start descrambling the service in this CAPMT object as soon as the list of CAPMT objects is complete#define CMD_OK_MMI 0x02
#define CMD_QUERY 0x03
#define CMD_NOT_SELECTED 0x04
CA application should stop descrambling this service (used when the last service in a list has left, note that there is no CI definition to send an empty list)A client implementation can mainain two lists. One is a list of received CaPMT objects, and a second lists services the softcam is currently descrambling. When a LIST_FIRST or LIST_ONLY is received, the first last can be discarded and rebuild with the new CaPMT data. But when a LIST_UPDATE is received the first list should be updated with the received CaPMT data. When a LIST_ADD, LIST_LAST or LIST_UPDATE is received, the two lists should be compared so the second list can be updated and the descrambler(s) can be reset. By doing this, black holes in recordings can be avoided. For further details see DVB document A025, "Guideline for Implementation and Use of the Common Interface for DVB Decoder Applications"
To allow for structured PMT distribution it is advised that any tool allows command line instructions to select the location of the socket it needs to connect to. Default would be the /tmp/.listen.camd.socket. It is suggested to use the '-p' parameter for this. E.g.:
camd -p /tmp/pmt.socket
PLi® Wiki HomePage
