On 23.09.2016 16:59, glenvt18 wrote:
Hi folks,
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: https://github.com/FernetMenta/vdr-plugin-vnsiserver/pull/74#issuecomment-24...
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 the line
if (t > TS_SCRAMBLING_TIMEOUT)
to
if (t > TS_SCRAMBLING_TIMEOUT && CamSlots.Count() > 1)
Klaus