Tvheadend

Have you tried reverting to 4.3-777~gc625df2f7~raspbianstretch? See if that has the same outcome?

sudo apt install tvheadend*=4.3-777~gc625df2f7~raspbianstretch

Most STBs rely on hardware descrambling and are not very powerful as far as CPU goes. But I would think most should be able to handle at least one channel being descrambled via software (what Tvheadend is doing) even if it is an HD channel with 3 or 4 audio tracks.

Does someone know if debug builds set the debug2 in decrambler.c??

At startup there should be a line showing the CSA descrambling mode, something like:

 [   INFO] csa: Using SSE2 128bit parallel descrambling

Mark Hunting Clarkstone: Any particular reason why I should try this specific version?

I have just tried both 4.3-777~gc625df2f7 and 4.3-819~g7c3919b88 (which seems to be the latest as of now). There is no difference in descrambling-related behavior that I could observe when comparing with 4.3-767~gd0a79495e that I have used originally. If you are interested, the logs are attached.

Joe Miller User: I am trying to descramble this channel:

http://www.onastra.com/16665077/channels#!/channel/16807

Content varies, but as of now it contains the following:

(+) Video --vid=1 (h264 1920x1080 25.000fps)
(+) Audio --aid=1 --alang=cze (mp2 2ch 48000Hz)
    Audio --aid=2 --alang=cze (ac3 6ch 48000Hz)
    Subs  --sid=1 --slang=cze (dvb_subtitle)

The CSA line for me looks like this:

[   INFO]:csa: Using 32bit parallel descrambling

The CPU on the receiver has the following capabilities:

# cat /proc/cpuinfo 
processor    : 0
model name    : ARMv7 Processor rev 3 (v7l)
BogoMIPS    : 54.00
Features    : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm 
CPU implementer    : 0x42
CPU architecture: 7
CPU variant    : 0x0
CPU part    : 0x00f
CPU revision    : 3

processor    : 1
model name    : ARMv7 Processor rev 3 (v7l)
BogoMIPS    : 54.00
Features    : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm 
CPU implementer    : 0x42
CPU architecture: 7
CPU variant    : 0x0
CPU part    : 0x00f
CPU revision    : 3

Hardware    : Broadcom STB (Flattened Device Tree)
Revision    : 0000
Serial        : 0000000000000000

Maybe it would help not to use the Raspberry Pi build, but rather compile tvheadend from scratch and use some CPU-specific compile-time optimizations. The software descrambling might then be faster. Your example CSA line mentions SSE2 128bit, which, I assume, should be faster than plain 32bit. But I am not sure which descrambling-related features this CPU supports.

Also, thanks for the information about the hardware-accelerated descrambling. I did not know about that. If you say that satellite receivers are typically equipped with hardware descramblers, is it possible to utilize them by tvheadend?

Do you have problems with encrypted SD channels?

My line is from a PC, but there are some neon optimizations for libdvbcsa (the software decryptor) which should help. However, I am not sure if they will automatically be included if you build it yourself. But a build from scratch for your machine would be a good start.

As far as using the hardware to decrypt, it depends on the drivers. I looked at this briefly when I tested tvheadend on my Amiko Alien2 (spark7162) box, but never had the time to do much. In theory, if you set oscam boxtype just like you do for enigma2 and use a capmt socket connection to tvheadend, then oscam can use IOCTLs to directly use the hardware decoders on the box.

BTW - OpenATV uses oe-alliance and openembedded has recipes to build tvheadend (and oscam.)

Joe User wrote:

Do you have problems with encrypted SD channels?

Yes, with my previous setup, the receiver was not able to descramble even a single SD channel in real time. The tvheadend's CPU usage was still 100% on a single core and the resulting stream froze regularly.

I did not try to build tvheadend myself, because I wanted to make the hardware descrambling work in the first place. I assumed it must be possible, because when Enigma2 is running on that same receiver, it uses oscam for descrambling as well and it can somehow descramble multiple channels simultaneously without any significant CPU usage.

Thank you for the suggestions about oscam configuration. Originally, I have had the boxtype parameter set to 'pc'. I have changed it to 'dreambox', because that value was also used by oscam instance, which was working fine with Enigma2. After that, tvheadend was able to descramble multiple channels simultaneously without any significant CPU usage, just like Enigma2.

I have also made one more change to oscam's configuration. As you suggested, I have set pmt_mode to '0', so that oscam clients can use a socket file instead of a TCP connection. Is it a necessary step in order to enable clients to use hardware descrambling?

I have also tried to change the boxtype back to 'pc' while using the socket file for client connections. It caused tvheadend to fallback to software descrambling again (judging from the high CPU usage). So, I assume that the most important part was to set the boxtype to 'dreambox', at least in my case.

Thank you once again for all the suggestions. My issue with high CPU usage while descrambling is now resolved.