Project

General

Profile

Bug #5449

CAPMT descrambler does not work with frontend1

Added by Peter Bašista almost 6 years ago. Updated almost 6 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Descrambling
Target version:
-
Start date:
2018-12-20
Due date:
% Done:

0%

Estimated time:
Found in version:
4.3-1683~gdd37467c8
Affected Versions:

Description

I am running Tvheadend on a device with a single Si21662 DVB adapter which has three frontends. I have a CAPMT descrambler configured, which connects to a locally running instance of OSCam via unix socket.

When I stream from frontend0, descrambling works fine. Tvheadend is able to descramble multiple channels from the same transponder simultaneously.

However, when I try to stream the same scrambled channel that works with frontend0 from frontend1, it fails with "No descrambler" (trace logs are attached). It is reproducible even when no other frontend is in use. It seems like, at least in my case, Tvheadend is not able to properly use CAPMT descrambler on frontend1.

There is a similar issue #5330 (now resolved) about Tvheadend not being able to use multiple frontends of the same adapter simultaneously. Maybe the way it was resolved did not take descramblers into account. But I am not sure. The root cause of this issue may as well be different.

Files

scrambled_channel.frontend0.log (33.4 KB) scrambled_channel.frontend0.log Streaming a scrambled channel from frontend0 Peter Bašista, 2018-12-20 21:37
scrambled_channel.frontend1.log (85.4 KB) scrambled_channel.frontend1.log Trying to stream a scrambled channel from frontend1 Peter Bašista, 2018-12-20 21:37
scrambled_channel.frontend1.log (38.6 KB) scrambled_channel.frontend1.log Tvheadend log while trying to stream a scrambled channel from frontend1 Peter Bašista, 2018-12-20 23:08
oscam.128.log (17.2 KB) oscam.128.log OSCam log while trying to stream a scrambled channel from frontend1 Peter Bašista, 2018-12-20 23:09

History

#1

Updated by Joe User almost 6 years ago

Can you provide a log with just --trace descrambler,capmt (frontend1 is enough) and a corresponding oscam log with -d 128 (dbvapi)?

Have you tried with a newcamd connection to oscam?

#2

Updated by Peter Bašista almost 6 years ago

Joe User wrote:

Can you provide a log with just --trace descrambler,capmt (frontend1 is enough) and a corresponding oscam log with -d 128 (dbvapi)?

Yes. The files are attached.

Have you tried with a newcamd connection to oscam?

No, I did not experiment with that. Do you suppose that it make make a difference?

#3

Updated by Joe User almost 6 years ago

I see you are using the old socket mode connection to oscam. Not sure if it will solve it, but it is better to use a network connection (even if on same machine.)

Preferred mode is mode 5 - OSCam net protocol (rev >= 10389)
[[https://docs.tvheadend.org/webui/config_caclient/]]

#4

Updated by Peter Bašista almost 6 years ago

Joe User wrote:

I see you are using the old socket mode connection to oscam.

Yes. I did not know that it is considered an "old" method.

Not sure if it will solve it, but it is better to use a network connection (even if on same machine.)

I see. Thanks for the suggestion, I have tried it (as you have suggested - "OSCam net protocol (rev >= 10389)") and it indeed seems to help. Tvheadend can then descramble streams from frontend1 as well.

Although not all OSCam "Boxtype" and "PMT Mode" combinations seem to work reliably. Some of them behave (in my case) in a way that when starting descrambling on frontend1, the already running descrambling on frontend0 is stoped. But that may be an OSCam issue as well.

A combination that "works for me" so far is boxtype=pc-nodmx and pmt_mode=0. There may be other combinations that work well.

With regards to connecting to OSCam via unix socket: I think that it would still be beneficial to make it work properly, but I am not sure where the issue is.

#5

Updated by Joe User almost 6 years ago

Did you try boxtype=pc and PMT mode=4 like the wiki suggests?

PMT mode=0 is for using the camd.socket

Did you enter an IP address for "Camd.socket filename / IP Address (TCP mode):" ie, 127.0.0.1

What did you have set originally?

You can look at the logic here:
[[https://github.com/oscam-emu/oscam-patched/blob/master/module-dvbapi.c]]

Look for cfg.dvbapi_listenport and cfg.dvbapi_boxtype

#6

Updated by Peter Bašista almost 6 years ago

Joe User wrote:

Did you try boxtype=pc and PMT mode=4 like the wiki suggests?

Yes, I did. I am not sure which mode exactly was causing the issue that I have described previously. For some reason, I cannot reproduce it anymore. All combinations of boxtypes pc and pc-nodmx as well as PMT modes 0 and 4 work well now. Maybe it was caused by a temporary OSCam reader glitch.

Did you enter an IP address for "Camd.socket filename / IP Address (TCP mode):" ie, 127.0.0.1

Not exactly. I have used a hostname, i.e. localhost and port 9000, which, I believe, is the default.

What did you have set originally?

I have originally used a unix socket file at /tmp/camd.socket, with no port (but Tvheadend sets it to 0 in that case, at least in GUI).

You can look at the logic here:
[[https://github.com/oscam-emu/oscam-patched/blob/master/module-dvbapi.c]]

Thank you. I have briefly looked at the code, but I am not familiar with it and I was not able to determine whether the issue with communication over the unix socket is somehow caused by OSCam or not. Maybe a longer analysis would reveal something, but I probably would not have time for it in the near future.

#7

Updated by Rafal Kupiec almost 6 years ago

Im not sure if this is related or not, but I also got problems with frontend1. It is unable to play one channel. In logs I see some continuity errors and after a while Kodi says no input. This happens only to one channel. Other channels from same transparent are working fine. Also, if I disable frontend1, the channel is working properly on all the other frontends.

Also available in: Atom PDF