CI/CAM: CAM thread started too late causing "TL__"

[ast@…]

This is for mythtv 0.27.1.

I do have a CAM that, after power up, doesn't pass the transport stream, either encrypted or unencrypted, until communication with the CAM commences. I didn't check further, which part of the communication (e.g. connection, session, time/date) is actually required. A quick look through the spec doesn't seem to disallow this CAM behaviour.

The problem is now, that MythTV starts the CAM thread which commences communication only in SetPMT(). This, however, is called only after TuningSignalCheck?() returns "good signal" which in turn requires the transport stream, thus causing a chicken and egg problem resulting in "TL".

Thus the CAM thread needs to be started before TuningSignalCheck?() starts to wait for the transport stream.

The attached patch is more or less a demo workaround that calls SetPMT with a NULL PMT before TuningSignalCheck?() is called. What is probably really required is just to start the CAM thread at a suitable point in the processing flow.

[ast@…]

cam thread start workaround

[mythtv@…]

I have the same behaviour, after reboot I get TL_ and I must remove and reinsert the CAM to get a decrypted picture - is there a simple way to verify if I have the same problem?

[ast@…]

You can only try the attached patch. Be aware, however, that there are more problems (e.g. card validity updates don't work) which I don't have a solution for.

[Stuart Auchterlonie]

Closing all old tickets in trac.

If your issue still persists, please open an issue in Github ​https://github.com/MythTV/mythtv/issues

and reference the existing trac ticket.