verschlüsselte Kanäle mit vdr-plugin-satip und Octopus Net

1.)

Menü --> Einstellungen --> DVB --> Kanäle aktualisieren

auf "nein" setzten.

2.)

CAIDs auf Null setzten:

Den VDR stoppen, dann

sed -i channels.conf -e 's/^\(.*:.*:.*:.*:.*:.*:.*:.*:\).*\(:.*:.*:.*:.*$\)/\10\2/'

den VDR wieder starten.

Zitat von Hemonu

Hat schon jemand erfolgreich ein CI im Octopus Net in Betrieb?

Du meinst eher ein CAM, oder?

Das CI im Octopus Net ist noch nicht unterstützt, so mein letzter Kenntnisstand. Daher überrascht mich das es mit VLC bei Dir tun soll ... hmm, mal testen, hab auch ein AC Classic hier liegen ...

Regards
fnu

Versuch mal in cSatipDevice::HasInternalCam() 'true' zurückzugeben.
In der channels.conf dann bitte die original Einträge verwenden (mit CA-Ids).

Klaus

Zitat von Hemonu

Das CI der Octopus Net wird seit Firmware 1.0.17 unterstützt. In der Doku oder im Menü findet man allerdings nichts.

Ok, das habe ich nicht mitbekommen, auch entsprechende Fragen blieben an andere Stelle leider unbeantwortet.

Werde gleich mal in Keller gehen, das AC Classic raussuchen und testen. Geht dann aber nur in einer Mischbelegung, intern und O'Net, es war doch irgendwie möglich bestimmt Kanäle an einen Adapter zu pinnen der entschlüsseln kann ... ?

Regards
fnu

Zitat von fnu

Werde gleich mal in Keller gehen, das AC Classic raussuchen und testen.

Ging jetzt auch eben ohne Mischbelegung. Ja, mit VLC werden die Kanäle hell, mit dem VDR noch nicht.

Habe "cSatipDevice::HasInternalCam() 'true'" gepatched, ist ja nur eine Zeile (?) und Plugin neu gebaut. Aber im syslog steht nichts davon das der Kanal nicht geöffnet werden könnte, bleibt einfach schwarz ...

Entschlüsselung war bisher auch noch nicht im Fokus der Entwicklung, sondern das man das allgemein mal nutzen kann. Ich hatte z.B. vor einiger Zeit nur den Update auf 1.0.21 gemacht und die 1.0.17 schlicht übergangen, wie auch die Release Notes dazu.

Regards
fnu

It seems that ONet decryption requires client to specify the PMT pid via an extra parameter (x_pmt) - that's an special API extension by DD. Now, the VDR doesn't provide the PMT pid information of channels and implementing a PAT parser in the plugin is total overkill and therefore the VDR core should be modified to provide the required information.

Zitat von rofafor

It seems that ONet decryption requires client to specify the PMT pid via an extra parameter (x_pmt) - that's an special API extension by DD. Now, the VDR doesn't provide the PMT pid information of channels and implementing a PAT parser in the plugin is total overkill and therefore the VDR core should be modified to provide the required information.

If this is a "special API extension by DD", how do other SAT>IP servers handle this?
Does the SAT>IP protocol not specify how encrypted channels are to be handled?
Or is the ONet the only one that can handle encrypted channels?

Klaus

Zitat von kls

If this is a "special API extension by DD", how do other SAT>IP servers handle this?
Does the SAT>IP protocol not specify how encrypted channels are to be handled?
Or is the ONet the only one that can handle encrypted channels?

Well, at least I haven't spot any other device with CAM support and specification doesn't state anything about scrambling, so I guess the decrypting has been left for clients or the product is meant only for FTA channels as some of the product pages advertise.

So, checked quickly specs of other devices, Triax TSS 400, DSS 400GSS.box, Inverto IDL 400 and Telestar Digibit R1, none of them do obviously provide a CI.

Regards
fnu

Hi,

da gibt es SAT>IP Receiver mir CI+ Devolo

CU
9000h

Beim Devolo ist hingegen das CI+ nicht im SAT>IP Server sondern im Client integriert.
Dadurch wird das so nicht vergleichbar sein.

HI,

ja aber wuerde die CI Loesung am VDR auch so haben wollen.

CU
9000h

Hallo falls ich die Spezifikationen richtig verstehe sollte der sat-ip server den gesamten Stream dem client schicken, der ist dann für die Entschlüsselung zuständig.
Cu Peje

Zitat von Hemonu

it seems to me that one feasible way would be to define an additional parameter with the PMT pid in the channels.conf.

Well, the most feasible solution would be adding new pid types: ptCurrentPmt and ptOtherPmt.

Zitat von rofafor

Well, the most feasible solution would be adding new pid types: ptCurrentPmt and ptOtherPmt.

This will definitely not go into channels.conf!
If there is no other solution, I'll see if the PMT pid can be stored together with the CA descriptors, so that it is available when needed.

Klaus