Standbild immer wenn Server auch guckt

[Schimmelreiter]

Da ich grad an meine oscam.dvbapi komme, hier mal meine Einstellungen für Delay (In der oscam.dvbapi aller Clients):

D: 0500 90
D: 1830 320
D: 1838 320
D: 1843 320
D: 098C 120
D: 098E 120
D: 09C4 120

Die Einträge bedeuten, an einem Beispiel:
D: 1843 320
-> Antworten für CAID 1843 (HD02) verzögern auf 320ms

D.h. Antworten für HD02 die schneller kommen als innerhalb von 320ms werden trotzdem erst 320ms nach der Anfrage verarbeitet, alles was nach mehr als 320ms kommt wird natürlich direkt verarbeitet.

Antwort kommt nach 90ms -> Verarbeitet nach 320ms
Antwort kommt nach 290ms -> Verarbeitet nach 320ms
Antwort kommt nach 320ms -> Verarbeitet nach 320ms
Antwort kommt nach 350ms -> Verarbeitet nach 350ms
Antwort kommt nach 400ms -> Verarbeitet nach 400ms

 

[Mopyfisch]

das mit dem delay hab ich nicht gefunden.

auf dem sever ist oscam auf dem clienten cccam

testen kann ich leider so nichts da das problem nur bei liveevents auftaucht und nur wenn auf dem server etwas anderes läuft als auf den clienten wenn überall das gleiche läuft passiert es nicht und wenn der server dunkel bleibt läuft es auch auf den clienten problemlos auch wenn auf den zwei clienten unterschiedliche sender laufen


so?

Spoiler: oscam.dvapi

D: 0500 90
D: 1830 320
D: 1838 320
D: 1843 320
D: 098C 120
D: 098E 120
D: 09C4 120
[reader]
label = v13
protocol = internal
device = /dev/sci0
services = sky
showcls = 0
caid = 09C4
ident = 09C4:000000
boxid = 12345678
ins7e11 = 15
detect = cd
mhz = 368
cardmhz = 368
ident = 09c4:000000
group = 1
ndsversion = 2

 

[Pilot]

das mit dem delay hab ich nicht gefunden.

Kannst du auch nicht finden.
Das mußt du in oscam.dvbapi beim Clienten erst reinkopieren und dann oscam neu starten.

 

[axel]

Hi,

installiere auch auf dem Client Oscam.

Dann siehst Du, woran es liegt.

Gruß

Gesendet von meinem SM-G920F mit Tapatalk

 

[Schimmelreiter]

auf dem clienten cccam

Igitt, das stinkt doch, so tot ist CCcam.

Und wenn dann die erste UHD-Kiste ins Haus kommt, ist das Geweine wieder riesengroß, weil die Umstellung dann sofort klappen muß, weil es gar keinen CCcam dafür gibt ...

 

[Mopyfisch]

Das ist ein kompliziertes thema um es mal ebenso zu installieren ich hab das was ich hier habe mit 30 beiträgen und viel lesen bis zu diesem punkt geschafft ....mehr brauch ich nicht ich hab auch nicht die zeit das immer wieder umzustricken das alles muss nix können da muss nur auf jedem tv ein bild ankommen ....die qualität die da momentan vorhanden ist reicht völlig aus ...

das läuft so seit acht jahren und ich versuche einfach nur die standbilder (gefühlt mehr geworden sind) weg zu bekommen ....

also reines oscam system sollte es sein so wie ich das verstehe richtig

 

[xyndra]

Spoiler: Oscam.user

[account]
user = dvbapi
pwd =
group = 1
au = 1
caid = 09C4
suppresscmd08 = 1

[account]
user = mopy
pwd = mopyfisch
group = 1
services = skyall
caid = 09C4
au = 1
disabled = 0

[account]
user = solocool
pwd = mopyfisch
group = 1
services = skyall
caid = 09C4
au = 0
disabled = 0

Spoiler: Oscam.dvbapi

P: 09C4
D: 09C4 120
I: 0

Spoiler: oscam.conf

[global]
serverip = 192.168.0.101
logfile = /var/log/oscam.log
maxlogsize = 0
preferlocalcards = 1
saveinithistory = 1

[cccam]
port = 12000
version = 2.2.0
reshare = 1
reshare_mode = 0
ignorereshare = 0
stealth = 1
minimizecards = 0
keepconnected = 1
forward_origin_card = 0


[dvbapi]
enabled = 1
au = 1
boxtype = dreambox
user = dvbapi
pmt_mode = 0

[webif]
httpport = 12088
httpuser =
httppwd =
httprefresh = 0
httpallowed = 127.0.0.1,192.168.0.2-192.168.0.254
httphideidleclients = 0
httpreadonly = 0
httpsavefullcfg = 0

Spoiler: oscam.server

label = v13
protocol = internal
device = /dev/sci0
services = sky
showcls = 0
caid = 09C4
ident = 09C4:000000
boxid = 12345678
ins7e11 = 15
detect = cd
mhz = 368
cardmhz = 368
group = 1
ndsversion = 2

 

[Schimmelreiter]

das läuft so seit acht jahren und ich versuche einfach nur die standbilder (gefühlt mehr geworden sind) weg zu bekommen ....

Das wird ohne oscam bei den Clients nicht gehen, da kein anderer Client bremsen kann.

Und da die Standbilder genau dann auftreten, wenn der Server mitguckt, gehe ich nach wie vor davon aus, daß zu schnelle Antworten die Ursache sind.

Der Sachverhalt ist total einfach nachzuvollziehen:
Der Server kriegt den CW-Wechsel mit und sein oscam berechnet ein neues CW.
Die Clients kriegen zwar exakt zur selben Zeit wie der Server mit, daß sich das CW geändert hat, aber deren Anfragen kommen um die Netzwerklatenz verzögert beim Server an, der Server hat mit der Ermittlung des neuen CW schon begonnen und mit einer um genau diesen Vorsprung verringerten Zeit kriegen die Clients die Antworten aus dem Cache des Servers.

Das ist auch der Grund, wieso manche Leute aus Rücksicht auf diesen CCcam-Schrott CacheEx(change) wieder aufgeben: Die ganzen nicht mehr gepflegten Cams (CCcam, mgcamd, ...) basteln bei zu schneller Antwort Freezer.

Und das wiederum ist der Grund (bzw. einer der Gründe), wieso ich auf meinem Server keine CCcam-Clients dulde.

also reines oscam system sollte es sein so wie ich das verstehe richtig

In einem reinen oscam-System ist auf jeden Fall schon einmal die Fehlersuche einfacher, da sowohl Server als auch Client anständige Logs erzeugen.

Und oscam braucht man sowieso, bei
- Serverbetrieb an DS-lite/Dual-Stack (Nur oscam kann einigermaßen IPv6)
- Clients mit sh4 oder arm-Architektur (Also einerseits die ganz alten Kisten wie Spark, Kathrein, Topfield; andererseits aber auch alle aktuellen Boxen mit UHD)
- Sharing von diversen XXX-Sendern auf Astra (Kann auch kein anderer Client)

Und hat man einmal einen Client mit oscam eingerichtet, fragt man sich eh, wieso man vorher auf die Idioten gehört hat, die einem CCcam als Client eingeredet haben.
Man sollte aber auch nicht auf die Deppen hören, die einem einreden wollen man müßte alles an oscam konfigurieren was man konfigurieren kann.
Ein Client braucht nur eine Minimal-Config und muß nicht mit services, Gruppen, whitelist, ... verkompliziert werden.

 

[axel]

Hi,

ja Oscam only, läuft hier 1A überall.

Das ist kein Hexenwerk als Client.

Hier gibt es prima Anleitungen dazu, ich find's gerade nicht mit dem Handy.

Das läuft stabiler, vor Allem siehst Du im Log jeweils, was da Sache ist.

Gruß

Edit: Jetzt war @Schimmelreiter schneller & ausführlicher. Also, Oscam auf den Client bügeln und Grundkonfigs dazu.

Gesendet von meinem SM-G920F mit Tapatalk

 

[xyndra]

Von supraracer oscam.client
HowTo - OScam Client Configs für CCcam Protokoll (VERY tiny & cute)

 

[Schimmelreiter]

Start-Config für einen oscam-Client so einfach wie möglich:

oscam.conf:

[global]
logfile                       = stdout;/var/log/oscam.log
maxlogsize                    = 100
preferlocalcards              = 2

[dvbapi]
pmt_mode                      = 0
user                          = dvbapi

[webif]
httpport                      = 81
httphelplang                  = de
httpallowed                   = 127.0.0.1,0.0.0.0-255.255.255.255,::1,fe80::-fe80::ffff:ffff:ffff:ffff,fd00::-fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff,2000::-3fff:ffff:ffff:ffff:ffff:ffff:ffff:ffff

oscam.server:

[reader]
label                         = Irgendein Name für den HS-/CS-Server
protocol                      = cccam
device                        = IP_oder_Host_des_Servers,Port_des_Servers
user                          = Benutzername
password                      = Kennwort
group                         = 1
cccversion                    = 2.3.0
cccwantemu                    = 1
ccckeepalive                  = 1
disablecrccws_only_for = 0500:050F00

oscam.user:

[account]
user                          = dvbapi
keepalive                     = 1
au                            = 1
group                         = 1

oscam.dvbapi:

D: 0500 90
D: 1830 320
D: 1838 320
D: 1843 320
D: 098C 120
D: 098E 120
D: 09C4 120

Mit allem darüber hinaus würde ich mich erst beschäftigen, wenn es aus irgendeinem Grund unabdingbar wird.
Das schließt diese unsägliche Ignoriererei (I: 0) und Priorisiererei (P: CAID) in oscam.dvbapi mit ein.
Ja, man kann damit dafür sorgen, daß man um Millisekunden schneller nach dem Zappen ein Bild kriegt.

Man kann sich damit aber auch einen Arsch voll Arbeit einhandeln, wenn man die bei einem Kartenwechsel auf x Clients an die neuen Gegebenheiten anpassen muß.
Insbesondere bei HS und auch CS im kleinsten Kreis bringt es übrigens rein gar nichts, weil oscam - anders als die Totkonfigurierer meinen - doch nicht zu blöd ist, selber zu sehen, welche Karten es gibt.

P: und I: sind nur dann relevant, wenn es im CS-Netz mehrere verschiedene Karten gibt, die die selben Sender hell machen können.

Wenn es eh nur eine V13 (09C4) gibt, dann kommt oscam auch von ganz alleine darauf, daß es die für Sky-Sender zu nehmen hat.
Versuche der Clients, HD+ über die Sky-Karte hell zu machen, blockiert man auch lieber einmalig auf dem Server durch einen Negativ-Service, statt auf allen Clients die oscam.dvbapi zu pflegen.

Glaubt mir, ich spreche da aus Erfahrung:

Seitdem ich bei x Clients die Prio
P: 1843
P: 1830
nach Kartenwechsel HD02 -> HD01 umdrehen

und die Prio
P: 1722
P: 1833
P: 098C
P: 09C4
nach Kartenwechsel S02 -> V14 umstricken

mußte, haben Clients bei mir nur noch die o.g. Delays in oscam.dvbapi, denn die ändern sich nicht und den Rest findet oscam auch selber raus, dann dauert es halt 500ms statt 200ms, bis nach dem Zappen ein Bild da ist.

 

[axel]

Hi,

also ich hab schon viel "rumgefrickelt" damit, das es diese "Delay-Geschichte" in der .dvbapi gibt wusste ich gar nicht.

Mein Rat: Erstmal das mit keinerlei Filter etc. ans Laufen bekommen, so einfach wie möglich.

Die Profis hier helfen sicher gerne.

Gruß

Gesendet von meinem SM-G920F mit Tapatalk

 

[Schimmelreiter]

also ich hab schon viel "rumgefrickelt" damit, das es diese "Delay-Geschichte" in der .dvbapi gibt wusste ich gar nicht.

Weiß ich auch erst, seit ich CacheEx mache

Bei Antwortzeiten von 30ms für Sky kriegt man halt genauso Freezer, als wenn man eine ranzige Pay-Line aus Eritrea nutzt und 800ms Antwortzeit hat
Und daß HD+-Antworten nach nur 70ms nicht gut sind, wenn eine echte Karte im stickstoffgekühlt übertakteten Reader vielleicht 280ms schaffen könnte, fällt dann auch nicht mehr schwer zu glauben.

 

[janni1]

Hi,
Welche Oscam-Version läuft bei dir?

# oscam.conf generated automatically by Streamboard OSCAM 1.00-unstable_svn build #4443

Wenn das stimmen sollte, würde ich erstmal updaten. Danach gilt dann unbedingt #8, also blocken.

Der Server kriegt den CW-Wechsel mit und sein oscam berechnet ein neues CW.
Die Clients kriegen zwar exakt zur selben Zeit wie der Server mit, daß sich das CW geändert hat, aber deren Anfragen kommen um die Netzwerklatenz verzögert beim Server an, der Server hat mit der Ermittlung des neuen CW schon begonnen und mit einer um genau diesen Vorsprung verringerten Zeit kriegen die Clients die Antworten aus dem Cache des Servers.

... plus der Netzwerklatenz zurück und müsste dabei eigentlich wieder etwa solang dauern, wie auf dem Server, mit dem Unterschied, dass es dort als "cache2"-Hit auftaucht.

Um das Caching abzustellen und auch diese Anfrage direkt zur Karte durchzulassen, könnte man in der [cccam]-Sektion "forward_origin_card = 1" setzen.
Ich glaube allerdinds nicht, dass das der richtige Weg wäre.

Mich würde aber als erstes ein Log vom Server interessieren, denn normalerweise sollte es hier keine Probleme geben.

 

[Mopyfisch]

Vielen vielen dank euch