[mythtv] Check start byte of next table in packet commit impact on tuning reliability?

Piotr Oniszczuk piotr.oniszczuk at gmail.com
Sat Nov 14 09:18:45 UTC 2020



> Wiadomość napisana przez Klaas de Waal <klaas.de.waal at gmail.com> w dniu 22.10.2020, o godz. 18:04:
> 
> Hi Piotr,
> 
> On Thu, 22 Oct 2020 at 12:03, Piotr Oniszczuk <piotr.oniszczuk at gmail.com> wrote:
> Klaas,
> 
> Is it possible that https://github.com/MythTV/mythtv/commit/58dfe835843a39065bce73af9dc1f586b48d9de3 may cause decreased sat tuning reliability on encrypted sat channels?
> 
> With this commit i see correlation of issue of approx few % of tunings failing at waiting on TLAMc.
> Reverting this patch removes TLAMc failure case from running issues.
>  
> The result of the commit should only be that a few more tables are actually processed instead of being discarded because of checksum failures. I do not have a clear view on how this can influence decryption, also given that basic tuning has already been done otherwise there are no transport stream packets at all.
> Can you be specific on which satellite and which channels do give problems? Is it for specific channels or is it random?
> I can receive Astra-1/2/3 plus Hotbird 13.0E; if your problem is not random but specific for channels on one of these satellites then I could do some testing on it.
> 
> Thanks,
> Klaas.

Klass,

After some usage I definitely see relation of 58dfe835843a39065bce73af9dc1f586b48d9de3 to reliability of LiveTV.

Issue is seen on some channels, is manifesting as  tune stays on TL___

On 2 channels issue is well repeatable: 

Hot Bird 13B, 12264.00,	V, tpx78, sid 3106
Hot Bird 13C, 11487.77, H, tpx15, sid 5106 

Revetting 58dfe835843a39065bce73af9dc1f586b48d9de3 makes tuning on above channels reliable.

br



More information about the mythtv-dev mailing list