Quantcast
Aktuelles
Digital Eliteboard - Das Digitale Technik Forum

Registriere dich noch heute kostenlos, um Mitglied zu werden! Sobald du angemeldet bist, kannst du auf unserer Seite aktiv teilnehmen, indem du deine eigenen Themen und Beiträge erstellst und dich über deinen eigenen Posteingang mit anderen Mitgliedern unterhalten kannst! Zudem bekommst du Zutritt zu Bereichen, welche für Gäste verwehrt bleiben

Registriere dich noch heute kostenlos, um Mitglied zu werden! Sobald du angemeldet bist, kannst du auf unserer Seite aktiv teilnehmen, indem du deine eigenen Themen und Beiträge erstellst und dich über deinen eigenen Posteingang mit anderen Mitgliedern unterhalten kannst! Zudem bekommst du Zutritt zu Bereichen, welche für Gäste verwehrt bleiben

welches protokoll für oscam ist "am besten"?

taker-`

Ist gelegentlich hier
Registriert
11. Juli 2012
Beiträge
87
Reaktionspunkte
3
Punkte
28
hi leute,

wollte mal rein informativ fragen, ob es denn ein "bestes" protokoll gibt?
damit meine ich dvbapi, newcamd und was es sonst noch so alles gibt?

oder kommt es drauf an, was man denn so machen möchte?


mfg
 
ok und was meinst du mit "im auge des betrachters"? ist das ganze vllt. auch abhänger, was für ein gerät als server dient und welche geräte als clienten?
 
Jedes Protokoll hat Vor und Nachteile.

Es kommt auch immer daruf an, was man vor hat. Was der Client verarbeiten kann usw
 
Klar gibt es das DVBAPI-Protokoll. In der oscam_conf wird mit dem Parameter listen_port = xxx eingestellt, auf welchem Port Oscam auf dvbapi-Anfragen warten soll.
 
ach ja

listen_port
Parameter ist optional
NEU svn9574:03/20/2014

listen_port = 0|1

TCP IP port für SAT IP clients. Die Filterung muss auf der Client-Seite erfolgen!

0 = disabled (default)

deswegen ist nur 0 oder 1 möglich

DVBapi
Parameter ist optional
Abschnitt nur dann erforderlich, wenn OScam auch als Client zum entschlüsseln eingesetzt werden soll.

was hat das mit einem Übertragungsprotokol zu tun
 
@dodo83
Laut Wiki haste da unzweifelhaft Recht. Aber da irrt wohl leider dieses. Es wird dort aber tatsächlich ein tcp-Port definiert, an den in der Regel SAT>IP Client (minisatip, satpi, ...) andocken können, um mittels dvbapi-Protokoll cw´s abzufragen. Bin da derzeit ein wenig am rumexperimentieren.

Gruß Tom
 
Also ganz langsam...ein dvbapi-Protokoll zwischen server und client gibt es ME in dem sinne nicht.

Damit die oscam lokal auch als client entschlüsselt brauchts halt den dvbapi.
Damit server und client sich mit einander verständigen und auf dem client die sender entschl. werden , werden die übertragungsprotokolle benötigt (camd).
Sat-IP clients können mit dem listen_port mehr oder weniger ihre oscam so nutzen als wären sie (lokal) und benötigen als reader kein camd-protokoll.
Also serverseite erlaubt den direkten zugang, clientseite gibt ip an und filtert
So habe ich das ganze verstanden. Lasse mich aber gerne belehren:)
 
Zuletzt bearbeitet:
ja, so in der Art funktioniert das auch. Aber zur Kommunikation des Client mit dem Oscam-Servers über wie auch immer geartete Netzwerkprotokolle, muss a) eine Protokollfamilie, hier tcp sowie b) ein Zielport, hier listen_port = ... festgelegt werden. Das Ganze wird tatsächlich als dvbapi-Protokoll bezeichnet.

Code:
2016/07/21 16:11:58 2170147F r (reader) avg1_hd_plus [nagra] Prv.ID: 00 00 34 11 (sysid)
2016/07/21 16:11:58 2170147F r (reader) avg1_hd_plus [nagra] Prv.ID: 00 00 00 00
2016/07/21 16:11:58 2170147F r (reader) avg1_hd_plus [nagra] IRD ID: ############
2016/07/21 16:11:58 2170147F r (reader) avg1_hd_plus [nagra] active to: 2016/08/24 12:59
2016/07/21 16:11:58 2170147F r (reader) avg1_hd_plus [nagra] -----------------------------------------
2016/07/21 16:11:58 2170147F r (reader) avg1_hd_plus [nagra] |id |tier |valid from |valid to |
2016/07/21 16:11:58 2170147F r (reader) avg1_hd_plus [nagra] +----+--------+------------+------------+
2016/07/21 16:11:59 2170147F r (reader) avg1_hd_plus [nagra] |8011|0066 |2013/11/23 |2014/11/24 |
2016/07/21 16:11:59 2170147F r (reader) avg1_hd_plus [nagra] |8011|0067 |2010/01/19 |2010/01/20 |
2016/07/21 16:11:59 2170147F r (reader) avg1_hd_plus [nagra] |8011|0BEA |2015/12/27 |2017/01/10 |
2016/07/21 16:11:59 2170147F r (reader) avg1_hd_plus [nagra] -----------------------------------------
2016/07/21 16:11:59 00000000 s (main) init for all local cards done
2016/07/21 16:11:59 00000000 s (anticasc) anti cascading disabled
2016/07/21 16:11:59 282E3865 c (client) plain dvbapi-client granted (dvbapi, au=on (1 reader))
2016/07/21 16:11:59 282E3865 c (dvbapi) dvbapi channelcache loaded from /etc/vdr/plugins/oscam/conf/oscam.ccache
2016/07/21 16:11:59 282E3865 c (dvbapi) Using TCP listen socket, API forced to DVBAPIv3 (0), userconfig boxtype: 11
2016/07/21 18:29:45 282E3865 c (dvbapi) Client connected: 'minisatip/0.5.54' (protocol version = 2)

hier ein kleines Beispiel aus dem minisatip-Forum. Erst verbindet sich der lokale dvbapi (plain dvbapi-client). Die beiden letzten Zeilen protokollieren dann einen SAT>IP-Client, in dem Fall minisatip, über dvbapi-Protokoll.

Die entsprechende oscam.conf beim Server sieht dann z.B. so aus:
Code:
[dvbapi]
enabled                       = 1
pmt_mode                      = 4
listen_port                   = 9001
user                          = dvbapi

Davon unbenommen sind natürlich die ganzen anderen Protokolle, camd3 tcp/udp, newcamd, gbox, radegast, cccam, cccam ext, ....
 
Zuletzt bearbeitet:
sehr informativ, danke :) aber welches protokoll (vllt. hab ich es auch vorher falsch formuliert, ka) ist am besten, wenn ich mit einem pi, der als server und client dient, damit 5-6 andere clients versorgen möchte. das wären 5 raspis und 1 pc.
 
Da schliesse ich mich der o.a. Meinung an, dass das wohl ziemlich egal ist. Ich persönlich bevorzuge newcamd und ext. cccam, ist aber Geschmackssache und mehr oder weniger "historisch so gewachsen". Für reines Card-Sharing mit einigen wenigen Teilnehmern ist fast jedes Protokoll geeignet. Ich würde der Einfachheit halber cccam (bzw. ext cccam sprich ohne Stealth-Modus) nehmen.
 
DVBapi ist natürlich kein Verbindungsprotokol im Sinne der Eingangsfrage.

DVBapi kann auch nur einen Hardware-Client bedienen. Bei einer Oscam z. B. auf einem Pi kann dieser Client auch extern sein, weil der Pi in der Regel keinen internen Client nutzt.
 
aber welches protokoll ist am besten,
...und nochmal die gleiche Antwort: Das "beste" gibt es nicht. Einfach für dich selber austesten womit du die besten Ergebnisse hast.
Wenn deine Frage allerdings gelautet hätte:"Welches ist das gebräuchlichste?", da gäbe es auch eine eindeutige Antwort: das CCcam Protokoll. Das ist aber nur ursächlich darin begründet das fast alle Umsteiger mal vom "CCcam emu" kamen und an den Clients keinerlei Änderungen gemacht werden mussten.
 
sehr informativ, danke :) aber welches protokoll (vllt. hab ich es auch vorher falsch formuliert, ka) ist am besten, wenn ich mit einem pi, der als server und client dient, damit 5-6 andere clients versorgen möchte. das wären 5 raspis und 1 pc.

Die Clients werden doch gar nicht über ein Shareprotokoll angesprochen.
Es wird der komplette TS Stream übertragen.
 
ach ich glaube jetzt hab ichs verstanden. bitte berichtigt mich, falls ich falsch liege.

wenn ich jetzt davon ausgehe, dass ich 3 raspis habe. (nur als beispiel) dann ist 1 raspi mein server. dort ist oscam und tvheadend server drauf.
dieser server-raspi empfängt die kanäle und speist sie in tvheadend ein. diese werden nun im "*.ts" format weiter geschickt, an die 2 client raspis.

die oscam entschlüsselt mir nun meine karte und gibt die entschlüsselungen über z.b. newcamd nur an tvheadendserver weiter. somit entschlüsselt jetzt, bzw. ist es in der lage auch die schon entschlüsselten sender nun an die clients auch weiter zu leiten.

somit hat z.b. newcamd gar nix mit den clients zu tun, da das alles nur auf dem server pi von statten geht?

d.h. im endeffekt macht der server pi alles und gibt das "fertige" signal an die clients weiter und die gebn nur wieder, was sie empfangen.


stimmt das soweit? :)
 
Zurück
Oben