On 23.09.2016 16:59, glenvt18 wrote:
The code in cDevice::Action() (device.c:1588) which checks whether a
stream can be descrambled by a particular CAM relies on the hard-coded
TS_SCRAMBLING_TIMEOUT value which is 3 seconds. That can be too low not
only for dvbapi, but for some 'real' CAMs as well. When a CAM is unable
to start descrabmling in 3 seconds, recordings and streamdev don't work,
and VNSI plugin has for years been using hacks and workarounds to cope
with it. We need a more flexible solution here. It can be a VDR option,
which can be set to 0 to disable, or a virtual function
cCamSlot::ScramblingTimeout() which can return 0.
@Klaus, what is your opinion on that?
More info on this issue:
If there is only one single CAM in the system, disabling this
timeout might make sense. However, if there is more than one CAM,
VDR can't know which CAM will be able to actually decrypt the
broadcast, so it has to try each of them in turn. With a long timeout,
switching between channels might take very long, while a short timeout
could (and apparently does) sometimes missfire. So 3 seconds is a
compromise between the two.
I don't know what that VNSI stuff does, but usually if the first try
doesn't work, VDR will retry after a few seconds and eventually the
channel will get decrypted (and a timed recording Will start).
Can you please verify if this works with your setup? I.e. start VDR
without any patches or plugins ("plain vanilla", except for any plugins
that are absolutely necessary - but in particular no VNSI!) and set
a timer for an encrypted channel. Then check whether VDR retries
using the CAM and eventually starts the recording.
In order to handle the case with only one single CAM you could try changing
if (t > TS_SCRAMBLING_TIMEOUT)
if (t > TS_SCRAMBLING_TIMEOUT && CamSlots.Count() > 1)
vdr mailing list