Localtime is sent to CAM module instead of timestamp from MPEG stream

[david@…]

In cCiDateTime::SendDateTime? (mythtv/libs/libmythtv/dvbdev/dvbci.cpp), the localtime is sent to the CAM module (see first four lines of the method)

However, EN50221 (section 8.5.2) says that the time to be sent is that derived from the Time and Date section (TDT, pid 0x0014) of the SI information in the MPEG stream. If the time is used in the decryption, this could cause the decryption to fail immediately, or after some time due to drift between the host and MPEG clocks.

[danielk]

This will not be fixed unless you attach a patch...

[Janne <janne-mythtv@…>]

Is this a real problem or just a theoretical one?

vdr uses in the recent version 1.4.4 still localtime and it has more DVB CI user than MythTV.

If it's not a real problem the ticket should be closed. I tried it and even a offset of days didn't let the decryption fail (Not to mention that a time offset of more than a couple of seconds will disturb scheduled recordings).

[david@…]

I couldn't tell whether it's a real or theoretical problem.

I do know that:

A) MythTV and vdr seems to lock up my CAM (AlphaCrypt?) within a matter of minutes while gnutv from the dvb-apps repo works for hours or days without problems. I'm trying to work out which differences there are between the MythTV and gnutv CAM handling code and the time sent to the CAM module was one of the differences I found so far (the polling code is the next thing that I'm planning to take a closer look at).

B) The EN50221 spec says that the time from DVB stream must be used. Following the spec can never be a bad thing and the module, or at least some modules, clearly uses the time for *something* or they wouldn't ask to be provided with the time at all. This might of course differ for different modules and different crypto systems.

I'm working on the time handling right now in my spare time...and I'll post a patch as soon as I have something which works...

[danielk]

Closing this until we have a patch.

David, reopen this and set the type to "enhancement" when your patch is ready for review.

[david@…]

Patch version 1

[david@…]

Ok, I've finally managed to sort this out, I've uploaded a patch for review (against 0.20-fixes branch, should hopefully be simple to readjust for the trunk).

Please note that I'll have limited Internet connectivity for the next two weeks (vacation) so further work (if necessary) on this might have to wait for a while.

[Stuart Auchterlonie]

This adds support for the processing of the TDT table which theoretically could also be used to add a timesync source (preferably optional) to a network free myth box.

[danielk]

Updated patch

[danielk]

David, can you check the patch I just uploaded?

It adds time offset support for both DVB and ATSC streams. It averages the offsets over the last 16 time tables seen so that we can determine the DVB/ATSC time with sub-second accuracy at any time.

[david@…]

Replying to danielk:

David, can you check the patch I just uploaded?

Will do when I return (so after the 4:th of January)

[david@…]

I've read through the patch and tested it now and it seems fine.

[david@…]

One note though:

Is the offset averaging that helpful?

The time sent with the DVB stream has a one second resolution, if the host time drifts relative to the DVB stream, it would take at least 8 updates for it to take effect (say we have 16 samples with a 6 second diff...it would then take 8 samples of 7 seconds diff before the 7 second diff takes effect). Considering that the TDT can be sent in 30 seconds intervals, that would mean a 4 minute delay.

[danielk]

The offset averaging is not so much for the CAM. There has always been an expressed desire to have the ability to sync your clock to the DVB/ATSC time of a channel. The averaging makes the time value accurate enough that you could do this. Although around here my channels differ by as much as 20 seconds in their concept of UTC time so it wouldn't be very accurate. But according to the law they should be using a GPS time source, so in theory it the time should be fairly accurate.

[danielk]

(In [12439]) Fixes #2703. Adds PSIP UTC time handling.

• Adds DVB TDT parsing
• Adds accurate time estimation based on DVB TDT and ATSC STT time.
• Passes the accurate time delta to the Conditional Access Module class
• Adds code to the CAM class to so that it can pass the correct time to the CAM wrt to what time the station thinks it is (which can be several seconds off from our time even when using NTP.)
• Moves time handling function to util so it can be shared by the new code and the existing time methods in EITHelper.

The DVB spec says that the CAM must be given accurate time WRT to the transmission time of the stream, if either our clock was off or the transmitters time was off then the old code did not do this because we just sent our UTC time to the CAM. With this code we calculate the offset between our time and DVB time and use that to adjust the code we send to the CAM. This change should prevent us from losing more than a second of data when the CAM encryption changes during the transmission of a program we are recording.

The ATSC time offset is just a bonus since the computation is performed in mpegstreamdata, but this and the DVB time offset could be used to set the local clock.

[Janne Grunau]

(In [12476]) Fixes #2874, Refs #2703, send only the PMT off the tuned program to the CAM

[danielk]

(In [13751]) Fixes #3153. Refs #2703. Only listen for DVB TDT when the table standard is 'dvb' in DVBRecorder.

In [12439] I added code to unconditionally listen for the TDT table to the DVBRecorder, but this is incorrect. While it is recommended that ATSC streams avoid PID's that have special meaning in the DVB world this is not required and some broadcasters use it. In the case of #3153, ABC was using the DVB TDT pid for the audio stream.

I had already made this change in the multirec branch, but there it was to avoid this as theoretical problem. Since it's an actual problem for a MythTV user I've ported this over to head and James tested the fix.