Bug #4744
closed
Invalid start code XX:XX:XX error casues stream to pause for a few seconds
Added by r 2 over 7 years ago. Updated over 7 years ago.
0%
Description
I upgraded my Tvheadend server from 4.0.9 to 4.2 branch (I tested 4.2.2 and 4.2.4). In 4.2 brach I started to see in the logs frequent messages like "TS: AC3 #XXXX Invalid start code XX:XX:XX" or "TS:H264 #XXXX Invalid start code XX:XX:XX. Sometimes these errors appears frequently, each 10-20 minutes, an each time the error is reported by Tvheadend, it causes the video stream to freeze for a few seconds, usually 10 or more, and causing in some rare cases that some of the connected clients in that moment remain in bad state after it, being needed to disconnect and reconnect the client to recover it. I tested both servers 4.0.9 and 4.2 running in the same server (Raspberry PI2), using the same key providers (OSCAM) to decode the same channel (DVB-S2 using Technisat Skystar USB HD), and this behaviour appears only in 4.2 brach.
Files
| tvheadend.log (477 KB) tvheadend.log | r 2, 2017-11-26 19:22 |
Updated by Jaroslav Kysela over 7 years ago
--trace descrambler,capmt,cwc - https://tvheadend.org/projects/tvheadend/wiki/Traces
Updated by r 2 over 7 years ago
- File tvheadend.log tvheadend.log added
Jaroslav Kysela wrote:
--trace descrambler,capmt,cwc - https://tvheadend.org/projects/tvheadend/wiki/Traces
In Tvheadend 4.2.4, when I try to trace the modules you requested, adding them through Tvh UI (Configuration->Debugging, Trace Subsystem), only capmt, cwc are traced; for the descrambler module, I receive an error in Tvh log console saying: "config: uknown subsystem 'descrambler" and it's automatically cleared from the string introduced in the Trace Subsytem field.
At the end I launched Tvh from console (tvheadend -l /tmp/tvheadend.log --trace descrambler,capmt,cwc): ... but I doubt it's tracing descrambler system because I can't see traces about it in the file.
Updated by Jaroslav Kysela over 7 years ago
$ ./build.linux/tvheadend --subsystems | grep descrambler descrambler Descrambler descrambler-emm Descrambler EMM
Updated by Jaroslav Kysela over 7 years ago
- Category changed from Parsers to Descrambling
- Assignee changed from Andreas Smas to Jaroslav Kysela
Updated by Jaroslav Kysela over 7 years ago
Your key source is not reliable, here is the change for both keys (which is basically invalid - only one key /odd,even/ should change after 15 seconds in your case):
2017-11-26 19:04:24.152 [ DEBUG]:capmt: localuser: CA_SET_DESCR adapter 0 par 0 idx 0 cf79024a59279e1e 2017-11-26 19:04:24.153 [ DEBUG]:capmt: localuser: CA_SET_DESCR adapter 0 par 1 idx 0 dd0afde4ca9673d3
The 'Invalid start code' checks were added to 4.2, the previous version just ignored them.
Updated by r 2 over 7 years ago
Jaroslav Kysela wrote:
Your key source is not reliable, here is the change for both keys (which is basically invalid - only one key /odd,even/ should change after 15 seconds in your case):
[...]
The 'Invalid start code' checks were added to 4.2, the previous version just ignored them.
So, when both keys (even/odd) change at the system time, video freezes until the key for the next time interval is received, in the same way that if I didn't receive the key on time, isn't?. In previous tvheadend, what was done? Discard the key (odd/event) that shouldn't change in that time interval?
Launching 'tvheadend --subsystems ...' generates the same output appearing in your post, although that I can't trace descrambler subsystem :?¿?
When you says the key source is not reliable, is there any way to know/trace if the root cause is the key provider or Oscam dvbapi implementation itself?. I tested with Oscam latest version (net protocol), and a very old one r9XXX (tcp protocol) with the same outcome.
Updated by Jaroslav Kysela over 7 years ago
r 2 wrote:
Jaroslav Kysela wrote:
Your key source is not reliable, here is the change for both keys (which is basically invalid - only one key /odd,even/ should change after 15 seconds in your case):
[...]
The 'Invalid start code' checks were added to 4.2, the previous version just ignored them.
So, when both keys (even/odd) change at the system time, video freezes until the key for the next time interval is received, in the same way that if I didn't receive the key on time, isn't?. In previous tvheadend, what was done? Discard the key (odd/event) that shouldn't change in that time interval?
No, appearently tvh is using the received wrong key, so the stream is not descrambled properly. I doubt that the old version of tvh works, too (if you see those double-key-updates).
Launching 'tvheadend --subsystems ...' generates the same output appearing in your post, although that I can't trace descrambler subsystem :?¿?
I've never seen this issue before. It means that something is wrong. but it's rpi so the debugging possibilities are limited.
When you says the key source is not reliable, is there any way to know/trace if the root cause is the key provider or Oscam dvbapi implementation itself?. I tested with Oscam latest version (net protocol), and a very old one r9XXX (tcp protocol) with the same outcome.
You probably receive wrong keys from your parent server.
You may give a test with cwc (newcamd), but you'll probably hit the same issue.
Updated by r 2 over 7 years ago
Jaroslav Kysela wrote:
r 2 wrote:
Jaroslav Kysela wrote:
Your key source is not reliable, here is the change for both keys (which is basically invalid - only one key /odd,even/ should change after 15 seconds in your case):
[...]
The 'Invalid start code' checks were added to 4.2, the previous version just ignored them.
So, when both keys (even/odd) change at the system time, video freezes until the key for the next time interval is received, in the same way that if I didn't receive the key on time, isn't?. In previous tvheadend, what was done? Discard the key (odd/event) that shouldn't change in that time interval?
No, appearently tvh is using the received wrong key, so the stream is not descrambled properly. I doubt that the old version of tvh works, too (if you see those double-key-updates).
Launching 'tvheadend --subsystems ...' generates the same output appearing in your post, although that I can't trace descrambler subsystem :?¿?
I've never seen this issue before. It means that something is wrong. but it's rpi so the debugging possibilities are limited.
When you says the key source is not reliable, is there any way to know/trace if the root cause is the key provider or Oscam dvbapi implementation itself?. I tested with Oscam latest version (net protocol), and a very old one r9XXX (tcp protocol) with the same outcome.
You probably receive wrong keys from your parent server.
You may give a test with cwc (newcamd), but you'll probably hit the same issue.
Thank you very much for your feedback, so if I understand it correctly, this isn't a bug really and could be closed.
Updated by r 2 over 7 years ago
One last question, would it be possible for Tvh to detect such situations, like changing even/odd keys at the same time, where it's not being able no decrypt the stream and use other key provided from a second CA?.
I have setup two of these bad key providers in two different Oscam instances and setup two different CAs in Tvh pointing to the previous ones?. I see Tvh is requesting to both oscam servers the same keys at the same time, but it's seems that it's only using the key it received first to decrypt the stream. It would be great than in case Tvh isn't able to do it, like when reporting "The Invalid Start Code XX:XX:XX", to try to decrypt it with one of the others keys received from other active CAs registered in Tvh.
I tried to dig if it would be possible to implement the same from Oscam side, but it seems currently Oscam is not smart enough to detect this invalid keys.
Updated by Jaroslav Kysela over 7 years ago
TVH does not know if key is valid or invalid. It just use the provided key. The 'Invalid Start Code' is just a consequence when tvh tries to parse the broken data stream. If you have more key sources, you may configure oscam to 'verify' key http://www.streamboard.tv/wiki/OSCam/en/Config/oscam.conf#double_check . But it's expensive, indeed.
Updated by r 2 over 7 years ago
Thanks for the trick, I'm giving it a try. The issue that I see is that most of the times these providers give you with something like 3 to 6 simultaneous lines to compensate its bad service quality so it would by funny that at the end the one cccam server would be double checking the key given by the same provider but different cccam line. Trying to play at the moment with server weights in oscam load balancer to check if i'm able to avoid this.