DVBAPI Incorrect count of descramblers during recording and playing same file

[knzsys]

Revision

11530

Issue Description

Incorrect count of descramblers

When the issue occurs

Incorrect count of descramblers during recording and playing same file

How the issue is reproducable

Start recording and 5 seconds later start watching that recording.
The counter of descramblers is raising every ECM Cycle until it reached
the maximum of 16. From now no additional channels are decrypted because
no descramblers may be available. Only the one recording channel is decrypted. The descrambler counter stays at 16 until recording is stopped.
During timeshift that error does not occur.
After stopping that recording the counter value drops down 2-3 steps with every zapping.

[knzsys]

This variable contains the wrong value:
static uint32_t ca_descramblers_used

[knzsys]

I have written a "dirty" fix for the problem, which works with VU+ 4K models
assuming that playing a recorded file will always use ca20.

Add to the function dvbapi_send_dcw of module-dvbapi.c
after these lines:

void dvbapi_send_dcw(struct s_client *client, ECM_REQUEST *er)
{
	int32_t i, j, k, handled = 0;
	for(i = 0; i < MAX_DEMUX; i++)
	{
		uint32_t nocw_write = 0; // 0 = write cw, 1 = dont write cw to hardware demuxer

		// ignore empty demuxers, skip ecm response for other
		// srvid and ecm recponse for different adapter
		if(demux[i].program_number == 0
			|| demux[i].program_number != er->srvid
			|| demux[i].adapter_index != er->adapter_index)
		{
			continue;
		}

these lines:

		if (demux[i].ca_mask & (1 << 20))
		{
			cs_log("Demuxer %d is using ca20 -> playing recorded file -> skip!", i);
			continue;
		}

We have still the issue, that the counter is getting too low, when zapping during recording.

Further investigating needed...

[knzsys]

New result of my investigations:

remove_streampid_from_list
is counting the available descramblers twice, if 2 StreamPIDs from same demuxer is removed (typically 1 video + 1 audio stream)

Log:

2019/08/11 16:59:20 62745646 c      (ecm) knzapi (098C::0BBD:9F:006E): found (125 ms) by knztv3 - Sky Atlantic HD
2019/08/11 16:59:27 62745646 c   (dvbapi) Using 1 of 16 total descramblers
2019/08/11 16:59:27 62745646 c      (ecm) knzapi (098C::0BBD:9F:006E): found (128 ms) by knztv3 - Sky Atlantic HD
2019/08/11 16:59:34 62745646 c   (dvbapi) Receiver wants to demux srvid 0093 on adapter 0000 camask 0002 index 0001 pmtpid 0066
2019/08/11 16:59:34 62745646 c   (dvbapi) Demuxer 1 ecmpid 0 CAID: 1834 ECM_PID: 1C8A PROVID: 000000 
2019/08/11 16:59:34 62745646 c   (dvbapi) Demuxer 1 ecmpid 1 CAID: 09C7 ECM_PID: 1D8A PROVID: 000000 
2019/08/11 16:59:34 62745646 c   (dvbapi) Demuxer 1 ecmpid 2 CAID: 09FD ECM_PID: 1E8A PROVID: 000000 
2019/08/11 16:59:34 62745646 c   (dvbapi) Demuxer 1 ecmpid 3 CAID: 1861 ECM_PID: 198A PROVID: 000000 
2019/08/11 16:59:34 62745646 c   (dvbapi) Demuxer 1 found 4 ECMpids and 3 STREAMpids in caPMT
2019/08/11 16:59:34 62745646 c   (dvbapi) Demuxer 1 trying to descramble PID 0 CAID 1834 PROVID 000000 ECMPID 1C8A ANY CHID PMTPID 0066 VPID 06FF
2019/08/11 16:59:34 62745646 c   (dvbapi) Demuxer 1 trying to descramble PID 1 CAID 09C7 PROVID 000000 ECMPID 1D8A ANY CHID PMTPID 0066 VPID 06FF
2019/08/11 16:59:34 62745646 c   (dvbapi) Using 2 of 16 total descramblers
2019/08/11 16:59:34 62745646 c      (ecm) knzapi (1722::0000:93:0093): found (83 ms) by knztv3(btun 1834) - Sky 1 HD
2019/08/11 16:59:34 62745646 c   (dvbapi) Using 2 of 16 total descramblers
2019/08/11 16:59:34 62745646 c      (ecm) knzapi (098C::0BBD:9F:006E): found (130 ms) by knztv3 - Sky Atlantic HD
2019/08/11 16:59:40 62745646 c   (dvbapi) Using 2 of 16 total descramblers
2019/08/11 16:59:40 62745646 c      (ecm) knzapi (1834::0000:89:0093): found (1030 ms) by knztv3
2019/08/11 16:59:41 62745646 c   (dvbapi) Using 2 of 16 total descramblers
2019/08/11 16:59:41 62745646 c      (ecm) knzapi (098C::0BBD:9F:006E): found (122 ms) by knztv3 - Sky Atlantic HD
2019/08/11 16:59:44 62745646 c   (dvbapi) Demuxer 1 stopped descrambling for program 0093 (1834@000000:0093 unknown)
2019/08/11 16:59:44 62745646 c   (dvbapi) Remove streampid 06FF using indexer 0 from ca1
2019/08/11 16:59:44 62745646 c   (dvbapi) Removed last indexer of streampid 06FF from ca1
2019/08/11 16:59:44 62745646 c   (dvbapi) Remove streampid 0703 using indexer 0 from ca1
2019/08/11 16:59:44 62745646 c   (dvbapi) Removed last indexer of streampid 0703 from ca1
2019/08/11 16:59:44 62745646 c   (dvbapi) Remove streampid 0704 using indexer 0 from ca1
2019/08/11 16:59:44 62745646 c   (dvbapi) Removed last indexer of streampid 0704 from ca1
2019/08/11 16:59:48 62745646 c   (dvbapi) Using 0 of 16 total descramblers
2019/08/11 16:59:48 62745646 c      (ecm) knzapi (098C::0BBD:9F:006E): found (122 ms) by knztv3 - Sky Atlantic HD
2019/08/11 16:59:55 62745646 c   (dvbapi) Using 0 of 16 total descramblers

[knzsys]

Tested both errors still in rev 11537

[knzsys]

Better, but fix works only on Duo 4K for rev 11537 :

Change lines 6665 to 6668 of module-dvbapi.c

			if(demux[i].program_number == 0)
			{
				continue; // only evalutate demuxers that have channels assigned
			}

to

			if(demux[i].program_number == 0)
			{
				continue; // only evalutate demuxers that have channels assigned
			}
			
			if (demux[i].ca_mask & (1 << 20))
			{
				cs_log("Demuxer %d is using ca20 for program number %04X -> playing recorded file -> SKIP!", i, demux[i].program_number);
				demux[i].program_number = 0;
				continue;
				// skip demuxers used for playing recordings since they are already decrypted
				// and causes wrong values of variable ca_descramblers_used
			}

remove_streampid_from_list still to be fixed

[knzsys]

A clean fix, which will work under any environment and on any hardware,
is on the way........

....for adding to the official trunk.

The "dirty" fix above is not a good way, because the number of ca devices is different on each model of enigma boxes. Additonally the behavior other devices (like PC or Coolstream) is unpredictable.

[nautilus7]

Hi, thanks for the report.

I am aware of some descrambling counting errors, but never got my hands around them because the whole descrambler detection and counting logic is going to be revised (currently for some receivers, mainly dreambox, the detection is wrong).

I am not sure how the new logic would work or what modifications will be done to the code yet.
Furthermore, the code that keeps track of what streampids are being descrambled and in which ca device, is really complicated. I tried once to understand it, but I lost track of it. And the problem is that I don't understand what is the need for such complicated code...

Anyway, to help me understand your problem though, I need a new log with debug 128 enabled. Please repeat the same procedure and post a new log. Also give details about your box and enigma2 image you use.

One thing I don't understand in your report is that since the channel is being descrambled when you record it, why playing back the (descrambled) recording needs additional descrambling??? It doesn't make sense.

[knzsys]

Hi nautilus,

the code is ugly in some parts. I'm glad that you are cleaning it up.

Here is my part:

Not only playing a running recording leads to wrong decramblers count,
but also other conditions.

So i fixed the descrambler counter by calculating it from scratch using
the active streampid list.

I testest it deeply and it seems to work well.
Even the rec file bug is handled better now (reduces available desramblers only to 15 and not to 0 than before).
I will commit the fix soon.

---

But there is still the problem that oscam tries to descramble descrambled
recordings.
I deeply investigated the problem and that are my results:

1. The ECM streams stays in the recorded file
2. The ECM informations of recorded file are written to camd.socket during play by enigma in VU+ boxes.
3. During playing a file the reported ca device "used" for "descrambling" is always the last one available on the receiver (f.ex. /dev/dvb/adapter0/ca20 for VU+ Duo 4K, ca8 for Vu+ Ultimo)
4. I have tried get some additional informations from the CA device using the DVB CA api ​https://www.kernel.org/doc/html/v4.12/media/uapi/dvb/ca.html

=> there is NO difference between real channels and recorded file, but the (last) used CA device
=> oscam is not capable to distinguish between channel and file.
=> This have to be fixed in enigma.

Until this fixed I will using my private patch which have to be adopted for every mode and kind of enigma box before publishing :-( :-(

Replying to nautilus7:

Hi, thanks for the report.

I am aware of some descrambling counting errors, but never got my hands around them because the whole descrambler detection and counting logic is going to be revised (currently for some receivers, mainly dreambox, the detection is wrong).

........

[knzsys]

Patch for issue described below ONLY FOR PRIVATE USE.
Attached file: skip_recordings.patch
skip demuxers used for playing recordings since they are already decrypted

ATTENTION!
Patch descramblers_used.patch from http://www.streamboard.tv/oscam/ticket/4744
have to be applied first until it will be added to trunk!

ATTENTION! This patch have to be modified for the model of enigma receiver used!
for VU+ boxes the CA device with the highest number ist used for playing recordings.
/dev/dvb/adapter0/ca20 (VU+ Duo 4K)
/dev/dvb/adapter0/ca8 (VU+ Ultimo)
I would be happy, if anybody can give me values for other enigma2 receivers :-)

used ca device can be detected at loglevel 128!
for VU+ boxes it is always the highest.

Replying to knzsys:

But there is still the problem that oscam tries to descramble descrambled
recordings.
I deeply investigated the problem and that are my results:

1. The ECM streams stays in the recorded file
2. The ECM informations of recorded file are written to camd.socket during play by enigma in VU+ boxes.
3. During playing a file the reported ca device "used" for "descrambling" is always the last one available on the receiver (f.ex. /dev/dvb/adapter0/ca20 for VU+ Duo 4K, ca8 for Vu+ Ultimo)
4. I have tried get some additional informations from the CA device using the DVB CA api ​https://www.kernel.org/doc/html/v4.12/media/uapi/dvb/ca.html

=> there is NO difference between real channels and recorded file, but the (last) used CA device
=> oscam is not capable to distinguish between channel and file.
=> This have to be fixed in enigma.

Until this fixed I will using my private patch which have to be adopted for every mode and kind of enigma box before publishing :-( :-(

[knzsys]

descramblers_used.patch