SAT>IP support. Revive vdr-sc partially

[CReimer]

Hi manio. I know this is completely against your concept for vdr-dvbapi.

The README of vdr-satip says.

Stream decryption requires a separate CAM plugin that works without direct access to any DVB card devices.

Your plugin is the only still actively developed one. But since your plugin depends on oscam and oscam depends on direct access to the DVB cards it's incompatible with any SAT>IP hardware.

Well you are the only developer I know who knows enough about CAM and VDR to revive and fix vdr-sc (Drop the clumsy logging stuff, remove keyfile support, Remove outdated cardreader support, make it compatbile to the new APIs of VDR 2.1.x). Something like a vdr-sc with only cardclient features. A vdr-cardclient plugin.

It's also preferable for cardserver connections over network.

Instead of oscam (Server) --> oscam (Client) --> vdr-dvbapi --> vdr oscam (Server) --> vdr-sc(cardclient) --> vdr

[manio]

Hello Chris, I exactly know what you mean :) I have a plan to add support to some kind of "dvbapi over network". It's on my mind since the new CAM interface. I know that it will also help people which has to add another local OSCam to the chain, because currently OSCam dvbapi module is opening the demux thus needs access to physical hardware.

In the alternative way the filtering will be done not on the OScam, but my plugin will do it using VDR (it will only receive ECM/EMM/CAT filtering requests) and the resulting data will be sent to OSCam (not via local socket, but via TCP connection, so no matter where will be the destination OSCam). This is my plan.

In fact I even have an early working code for this (currently it's working as ECM are passed correctly), but I don't want to say the estimated finish time as the code needs to be fixed, well tested, besides this will need a changes in OSCam (introducing some simple protocol), my plugin and also probably in VDR so it's too early to talk about the details.

Just keep calm, if nothing wrong happens it should be out some day... :)

[CReimer]

Sounds great.

and the resulting data will be sent to OSCam (not via local socket, but via TCP connection, so no matter where will be the destination OSCam).

You want to introduce another network protocol? Why not rely on already existing protocols like cccam2, camd35, newcamd?

In fact I even have an early working code for this (currently it's working as ECM are passed correctly), but I don't want to say the estimated finish time as the code needs to be fixed, well tested

If you need testers? Here I am? :tongue:

[manio]

Maybe 'introducing' a protocol was a too big word for this. In fact the existing protocol has to be expanded to make possibility of filtering ECM/EMM pids.

If I choose one of the protocol you mentioned I had to implement additional logic in my plugin (I don't know about camd35 but from the ones you mentioned CCcam would be the closest candidate as It can support several CAIDs using one connection, newcamd cannot handle more then one CAID per socket, and I would like to have it simple in configuration).

So finally I think the best approach is just to use the OSCam dvbapi for all this stuff. In this context dvbapi module is a little different then the protocols you mentioned. I want to leave the logic on OSCam side, it's handling it very well, it is now deciding about which ECM pid use, in which priority, when attach EMM filters, which filters apply and so on. I just don't want to duplicate this logic in my plugin. I just want to make it "simple and stupid". OSCam is doing the great and hard work here, I will just use it and only feed it with needed data.

Thank you for willing to be a tester. I'll contact you when needed :P

[manio]

Klaus will hopefully add EMM pids to the VDR receiver, so the EMM updates should work soon. Requested feature is now in master, closing.

[locka-hd]

Hi , i can add sc-system to oscam ?