Cwc/Capmt changes

[perexg]

Some changes are cleanups for the descramler.

A support for the TCP mode was added to the capmt client (mode 3). Also, another mode 4 was introduced (for the camd.socket) - required patches oscam with http://www.streamboard.tv/oscam/ticket/3753 . I think that I fixed also some errors for mode 2. The capmt code requires more updates:

• better filter code for mode 3 and 4 (oscam asks for PID 1 which is not transferred to oscam at the moment)
• use non-blocking I/O and queued writes to not block the other mpegts processing

Other parts of descrambler should be also improved:

• move the descrambler instance selection one level up (descrambler.c)
• probably a better pid handling

[manio]

Great work!
Just for your info and awareness: currently the oscam is not doing host to network order conversion of CA_SET_PID, CA_SET_DESCR, DMX_SET_FILTER and DMX_STOP and its structure values, so it doesn't matter as long as it is working on same machine or machines with same endianness.
But lastly I discovered this problem, but to not break the dvbapi in oscam I created a workaround in my plugin:manio/vdr-plugin-dvbapi@4f2ed99
This way I am just detecing the endianess (+ some addition for strange clients).

So ... to have a smooth transition plan I believe that any oscam dvbapi client which is using a TCP mode should create a similar check for some time. After this to have things clean we need to add htonl() htons() in the OSCam, and finally remove this workaround-checks in the clients. Otherwise we would have a tons of reports that it suddenly stopped working.

[perexg]

The second capmt code update was pushed. Everything should be improved (and maybe broken).

Note that I fould another issue in oscam which is reported in http://www.streamboard.tv/oscam/ticket/3758 . The code from ticked 3753 was already applied to oscam svn (revision 9754).

EDIT: The patch from ticket 3758 was applied as oscam revision 9760.

[perexg]

@manio : Thanks. I do also this endian conversion in cf9163b . But in your code - I would swap the bytes - perhaps using __bswap32() or own macro. htonl() will work only for the little endian system. If the vdr is running on the big endian system (versus a little endian server) - there is no byte swap in htonl().

[manio]

@perexg
Oh yes, good point, thanks :)

[perexg]

I added another two commit to open/close the required PIDs on demand for both ECM and EMM sections.

[ckarrie]

@perexg Could you please post an example setup/configuration for oscam and tvheadend?

Edit: Oops, I just saw thats its not yet merged to master. Nevertheless documentation is always good :-)

Edit2: Okay okay, I think I got it :-)

Edit3: Works great so far 👍

[perexg]

Rebased and merged to the master git tree.

[ghost]

After try compilation after mereged:

CC src/descrambler/ffdecsa/ffdecsa_mmx.o
In file included from src/descrambler/ffdecsa/parallel_064_mmx.h:21:0,
from src/descrambler/ffdecsa/FFdecsa.c:73,
from src/descrambler/ffdecsa/ffdecsa_mmx.c:2:
/usr/lib/gcc/i486-linux-gnu/4.7/include/mmintrin.h:32:3: error: #error "MMX instruction set not enabled"

[perexg]

@PiterEL : Try latest master branch. I hope that the commit 6fc3a46 will fix this issue for you.

[ckarrie]

@perexg I get a strange issue using CAMPT with mode 3 / IP:

Recording scrambled SD channel works, recordings HD channels doesn't, streaming the same HD channel works fine.

Full log (descrambling,cwc,campt) here https://drive.google.com/file/d/0B0-Pum1Hxr6eSkVJRHFPUnJ5VDQ/edit?usp=sharing (50 MB)

[perexg]

@crarrie: It seems that oscam does not send keys for some situations. You may also check the oscam log with the 128 debug level.

EDIT: It seems that the "fails" are also when there are 2 simultaneous sessions (dvr + streaming?). Not sure if it's related, but may be.. You may verify this by stream 2 different HD channels together.

[ckarrie]

@perexg Confirmed: I opened 2 vlc instances A and B. One A i streamed a scrambled HD channel without problems. On B I started a second scrambled HD channel... but no luck! I tried another HD channel on VLC instance B but without luck. I stopped A and retried streaming with B, but no luck. I stopped B. I restarted A and it works.

Log is at https://drive.google.com/file/d/0B0-Pum1Hxr6eVkNXNmJNNjVmRDQ/edit?usp=sharing

EDIT1: after some minutes, A and B stopped, A starts working.

EDIT2: does Tvheadend request for keys? It seems not in some cases (Only one request for Key in Oscam and then no more requests...)

EDIT3: I get a campt message on unscrambled HD channels capmt: Removing CAPMT Server from service "ZDF HD" on adapter 0

EDIT4: I switched now back to cwc, now I get following in oscam log: tvheadend (098C&000000/0C22/0073/98:00000000000000000000000000000000): invalid (0 ms) (invalid SID), there are multiple CAID for this channel but TVH doesn't want to try out the other CAID's (i.e. 1833 works for this channel). And after this message, no more logs from my tvheadend cwc user in oscam. After a restart of oscam and tvheadend, I get this in oscam: user tvheadend authenticated successfully (Tvheadend) nothing else, no request for keys...

It seems sometimes to work on channels with one CAID (0500).

If you need further infos/access just ask here (with correct username ;-))

[perexg]

@ckarrie: I'm a bit lost, please, provide logs for a simple case to verify. Run A for 60 seconds, then add B for next 60 seconds (assuming that B is not decoded) and shut down tvheadend. Also grab the oscam log for dvbapi simultaneously.

For cwc - I need the tvheadend log. EDIT: But, please, try to cut only log for time you tried to decode the problematic channel.

[ckarrie]

@perexg No more 50 MB Logs? Okay okay ;-) Stay tuned.

[ckarrie]

@perexg Here we go:

Note to Oscam: all real cards, no proxies!

Case 1: campt, A= 1 scrambled HD channel, B= 1 unscrambled HD Channel

• Tvheadend log (--trace campt,descrambling): http://goo.gl/YnUAN7
• Oscam log (debug=128): http://goo.gl/PWHFqU

Case 2: campt, A= 1 scrambled HD channel (recording), B= 1 scrambled HD Channel, C= 1 scrambled HD Channel

• A started with tvheadend -> all ok
• I started B and C in VLC -> all ok
• I stopped B and C and restarted B and C --> not working!
• I tried this 3 times and always the same issue
• A keeps working/recording until I stopped Tvheadend
• Tvheadend log (--trace campt,descrambling): http://goo.gl/lHrhPf
• Oscam log (debug=128): http://goo.gl/LffYZr

Case 3: cwc, A= 1 scrambled HD channel, B= 1 unscrambled HD Channel

• Tvheadend log (--trace cwc,descrambling): TBD
• Oscam log (debug=8): TBD

Case 4: cwc, A= 1 scrambled HD channel, B= 1 scrambled HD Channel

• Tvheadend log (--trace cwc,descrambling): TBD
• Oscam log (debug=8): TBD

[perexg]

@ckarrie : I think that I found the problems in campt with multiple streams. The fix in master git tree - commit b0cdac1 .

[ckarrie]

@perexg Wow cool, this fixed Case 2!

I think all issues fixed :-) Thank you a lot.

[perexg]

Just a note: I found another issue which affects the capmt 'mode 3' and 'mode 4' in oscam . The patch is in ticket # 3768 : http://www.streamboard.tv/oscam/ticket/3768 .

EDIT: The patch is in oscam - r9765 .

[ckarrie]

@perexg Hi perexg, Tvheadend just crashed with following "message":

tvheadend: src/descrambler/capmt.c:371: capmt_pid_add: Zusicherung »mmi && mmi->mmi_mux« nicht erfüllt. I don't know how I properly translate the error ;-)

Followed by

[  ALERT] CRASH: tvheadend_tvheadend/src/descrambler/capmt.c:371 0x495ff2
[  ALERT] CRASH: tvheadend_tvheadend/src/descrambler/capmt.c:1258 0x4961f8
[  ALERT] CRASH: tvheadend_tvheadend/src/descrambler/capmt.c:1379 0x496924
[  ALERT] CRASH: tvheadend_tvheadend/src/wrappers.c:125 0x40eb11

Using version 3.9.920~ga78c1c7

[perexg]

@ckarrie : A fix is in the current git master tree.

[ckarrie]

@perexg Thank you! I give it a try!