fixed: keep a state per section in cwc. don't mark as forbidden when only one section fails #477
Conversation
…only one section fails
| @@ -22,6 +22,7 @@ | |||
| #include <stdint.h> | |||
| #include <stdlib.h> | |||
| #include "queue.h" | |||
| #include "descrambler/descrambler_types.h" | |||
There was a problem hiding this comment.
Please, keep the definition in descrambler.h . This header file is included from service.h, so cwc.c also includes it.
There was a problem hiding this comment.
no, you'll need to include the whole descrambler.h where it's used, which is needless.
There was a problem hiding this comment.
This file must be included in all clients anyway.. I don't see any usage for the standalone declaration.
There was a problem hiding this comment.
src/descrambler/cwc.c:42:#include "service.h"
src/service.h:24:#include "descrambler.h"
src/descrambler/cwc.c:129:th_descrambler_t;
All clients MUST know the whole th_descrambler_t structure..
|
Noticed another problem. Not sure if it's new or regressed somewhere, but when we don't get a valid response from cwc at the start (e.g. timed out), then we we'll stop trying right away and don't retry at all. This leads to a huge delay when switching channels when this happens. I'll see if I find time to fix that too this week end. |
|
I tried to fix this issue in commit: bafbf38 |
When there are multiple sections and one of them fails to decrypt, then the whole service got marked as 'DS_FORBIDDEN'. This gets corrected a bit later when a valid ecm reply comes in after the invalid ones, but in case the invalid one comes in after the valid reply, then decryption will stop completely.
This fixes the issue by keeping a state per section.