On Sat, Sep 24, 2016 at 11:57:51PM +0200, Klaus Schmidinger wrote:

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.

So why not to have a setup option for it?

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).

VNSI does the same.

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.

I've run some tests with "vanilla" setup and 5 sec CAM delay. Most of the time VDR failed to zap retrying with ~20 sec intervals. I was observing each recording for ~30 minutes before canceling. After the scrambling timeout had expired, the CAM was 'blacklisted' with ChannelCamRelations.SetChecked() call (there was no alternative cam slot). That probably added 15 seconds. And it was just too long for the CAM. If a recording had been restarted immediately, it could have zapped successfully on the second try. VNSI with a ClrChecked() call can zap to such channels without any problem. The only recording that succeeded was the one that encountered a channel modification and was restarted at the "right" time. So, if a CAM is (always, or most of the time) unable to start descrambling in TS_SCRAMBLING_TIMEOUT seconds and there is no other candidate available, SetChecked() is to blame. It just shouldn't be called in such cases. When I removed SetChecked() call or increased TS_SCRAMBLING_TIMEOUT to 10 sec, recordings worked.

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)

Yes, it makes sense, and it works if there is only one CAM. But there are CAMs (like dvbapi) that can only be assigned to a particular device. In this case there can be more than one CAM in CamSlots but only one can be used with the device. Another problem is that if scrambling timeout is disabled and a CAM can't start descrambling in 30 seconds (MAXBROKENTIMEOUT), an emergency exit is fired (and is repeated every 30 seconds until the CAM starts descrambling). This will damage other recordings/streaming.