SKY V14 - wait_time over

karli9 · 28. August 2015

Hallo

Ich habe seit kurzem auf gewissen Sky-Sender folgende Fehlermeldung und der Sender bleibt dunkel.

Code:

(098C&000000/0B5C/007A/97:85A5A829753635D6D74FAE6F638D17B5): not found (120 ms) - Sport1+ HD (wait_time over)

Ich habe aber eigentlich nichts an meiner Oscam Konfiguration geändert.

Ist vielleicht etwas an meinen Cache-Einstellungen (oscam.conf) nicht mehr gut?

Code:

[cache]
delay = 10
max_time = 10
wait_time = 0500@023800:50:170,0500@040810:50:310,0D95:50:250,1830:50:470,098C:120:200

Vielen Dank für die Hilfe

Gruss

supraracer · 29. August 2015

AW: SKY V14 - wait_time over

Nutzt du überhaupt CacheEX?

-supraracer

karli9 · 29. August 2015

Ja ich habe auf dem Server CacheEx, doch ich empfange auf dem Server kein Cache, sondern sende nur Cache.

Komischerweise gehen die Sender heute früh wieder, kann es auch sein das die Karte am Abend überlastet war, sprich die Antwortzeiten länger und dem entsprechend meine Einstellungen falsch waren?

Gruss

Hier mal noch meine Cache-Sektion

Code:

[cache]
delay = 10
max_time = 10
wait_time = 0500@023800:50:170,0500@040810:50:310,0D95:50:250,1830:50:470,098C:120:200
cacheexenablestats = 1
cwcycle_check_enable = 1
cwcycle_check_caid = 0500,0D95,1830,098C
cwcycle_maxlist = 4000
cwcycle_keeptime = 15
cwcycle_onbad = 1
cwcycle_dropold = 1
cwcycle_sensitive = 4
cwcycle_allowbadfromffb = 1

janni1 · 29. August 2015

AW: SKY V14 - wait_time over

Hi,

karli9 schrieb:
Ja ich habe auf dem Server CacheEx, doch ich empfange auf dem Server kein Cache, sondern sende nur Cache.
...

das versteh ich nicht.
Warum hast du dann überhaupt Waittimes gesetzt?
Mit diesem Parameter willst du ja auf Cache warten, bevor ein Reader angefragt wird.
Beschreibe mal kurz deinen Aufbau.

Gruß
janni1

karli9 · 29. August 2015

AW: SKY V14 - wait_time over

Ahhh dann habe ich vielleicht grundsätzlich was falsch gemacht. Ich habe eben einen CardServer wo die V14 drin ist und dann habe ich einen vServer und dieser bekommt vom CardServer die V14 und den Cache vom CardServer, macht so in dem Fall meine Ganzen Cache Einstellungen gar keinen Sinn?

Gruss

janni1 · 30. August 2015

AW: SKY V14 - wait_time over

Hi,
nein, so macht das im Prinzip keinen Sinn.

Beschreibe deinen Aufbau mal bischen näher.
Auf welchem Server sind die Clienten.
Hast du CacheEx-Partner?

Gruß
janni1

karli9 · 30. August 2015

AW: SKY V14 - wait_time over

Hallo

Also da ist der CardServer mit den lokalen Karten über Smargos und dann gibt es eben den vServer und dieser greift auf den CardServer Server für die lokalen Karten und über CacheEx (Mode 3) bezieht er noch den Cache vom CardServer. Meine beide Clients (DM8000 und DM7020) sind mit dem vServer verbunden. Dazu kommen noch ein CacheEx Partner, dieser greift mit Mode2 auf den CardServer. Ich von meiner Seite beziehe seine Karten/Cache vom vServer her über Mode2.

Ist dies einigermassen verständlich?

Viele Grüsse

janni1 · 30. August 2015

AW: SKY V14 - wait_time over

Hi,
ja, es ist verständlich
aber das macht so keinen Sinn, wenn nicht auch noch anderer Clienten auf dem Cardserver wären,

karli9 schrieb:
... vServer und dieser greift auf den CardServer Server für die lokalen Karten und über CacheEx (Mode 3) bezieht er noch den Cache vom CardServer...

denn so bekommt der Vserver, wenn überhaupt, nur seine selbst angefragten CWs nochmal gepusht.
Diesen CE-Mode3-Reader kannst du dir sparen.

Von welchem Server stammt nun eigentlich die Fehlermeldung aus Post #1 ?

Gruß
janni1

karli9 · 30. August 2015

AW: SKY V14 - wait_time over

Hallo

Danke für die Antwort, dass heisst wenn der vServer über Mode3 den Cache vom CardServer holt bringt das gar nichts, sondern der Cache auf der CardServer ist eigentlich ja das Ergebnis aus den Abfragen vom vServer.

Die Fehlermeldung kommt auf dem CardServer, doch ich glaube ich habe da was gefunden und zwar habe ich auf meinem CardServer noch einen Sky-Reader von meinem Bruder (Backup), ich habe als die SKY lokal, plus noch einen Sky-Reader (CCcam) von meinem Bruder, doch mein Bruder hat nicht das volle Paket sondern nur ein paar Teile daraus und nun habe ich gesehen das gewisse Sender nicht auf meiner lokalen Karte gesucht werden, sondern die von meinem Bruder und ich glaube darum bleibt es dann dunkel, Oscam geht dann irgend wie nicht auf den zweiten Sky-Reader (meine lokale Full Karte), sondern bleibt sehen, weshalb das so ist ist mir ein Rätsel, Oscam sollte doch automatisch die Abfrage auf dem nächsten Sky-Reader ausführen. Ich habe jetzt mal bei dem Sky-Reader von meinem Bruder die Services hinterlegt, damit auf diesen Reader wirklich nur noch Anfragen gehen, die beantwortet werden können, doch wie so Oscam nicht meinen Reader anfragt ist mir noch nicht klar.

Viele Grüsse

janni1 · 30. August 2015

AW: SKY V14 - wait_time over

Hi,
du solltest dann auf dem Vserver mit dem Loadbalancer arbeiten und am besten LB_whitelist_services bei den Readern setzen,
wo direkt lokale Karten dahinter sind und zwar mit genau den Sendern, die von diesen bedient werden können.

Zeid am Besten mal die Config vom Vserver.

Gruß
janni1

axel · 31. August 2015

AW: SKY V14 - wait_time over

Hi,

ja bitte mal alle Konfigs posten. So verstehe ich zumindest nicht das Problem.

Am besten noch ein Log dazu...

PS: Mit @janni1 hast Du hier einen "Experten am Apparat", das meine ich Ernst.

karli9 · 31. August 2015

AW: SKY V14 - wait_time over

Hallo zusammen

Also hier mal die Configs auf dem vServer.

oscam.conf

Code:

[global]
bindwait = 1
CacheDelay = 100
LogFile = /tmp/oscam.log;stdout
MaxLogSize= 1000
netprio = priority
waitforcards = 0
saveinithistory = 1
lb_mode = 1
lb_save = 250
fallbacktimeout = 2200
lb_auto_betatunnel = 0
clientmaxidle = 0
block_same_ip = 0

[cache]
delay = 10
max_time = 10
wait_time = 0500@023800:50:170,0500@040810:50:310,0D95:50:250,1830:50:470,098C:120:200
cacheexenablestats = 1
cwcycle_check_enable = 1
cwcycle_check_caid = 0500,0D95,1830,098C
cwcycle_maxlist = 4000
cwcycle_keeptime = 15
cwcycle_onbad = 1
cwcycle_dropold = 1
cwcycle_sensitive = 4
cwcycle_allowbadfromffb = 1

[cccam]
port = 14169
version = 2.1.3
forward_origin_card = 0
reshare = 2
ignorereshare = 1
updateinterval = 30
keepconnected = 1

[cs378x]
port                    = 32074

oscam.server

Code:

[reader]
label = mylocals
enable = 1
protocol = cccam
device = MYDNS,15078
user = USER
password = PWD
group = 1
inactivitytimeout    = 1
cccversion = 2.1.3
cccmaxhops = 3
ccckeepalive = 1
cccmindown = 1


[reader]
label = proxy1
enable = 1
protocol = cccam
device = DNS,23456
user = USER
password = PWD
group = 2
inactivitytimeout    = 1
cccversion = 2.1.3
cccmaxhops = 3 
ccckeepalive = 1
cccmindown = 1

[reader]
label = proxy2
enable = 1
protocol = cccam
device = DNS,12345
user = USER
password = PWD
cacheex = 2
cacheex_maxhop = 1
group = 21
ccckeepalive = 1
dropbadcws = 1
inactivitytimeout = 30

oscam.user

Code:

[account]
user = USER
pwd = PWD
uniq = 1
group = 1,2,21
cccmaxhops = 3
cccreshare = 0

Das wäre wie gesagt der vServer. Falls es was nützt kann ich natürlich auch noch der Server (CardReader) Configs posten.

Wäre dann bei meinem Reader für meine lokalen Karten sowas korrekt?

Code:

[reader]
label = mylocals
enable = 1
protocol = cccam
device = MYDNS,15078
user = USER
password = PWD
group = 1
inactivitytimeout    = 1
cccversion = 2.1.3
cccmaxhops = 3
ccckeepalive = 1
cccmindown = 1
lb_whitelist_services = SRG,ORF,HDplus,SKY

Kommt dann mit dem "lb_whitelist_services" Parameter mein SKY-Proxy (proxy2) gar nicht mehr zu Zug? Die Idee wäre ja wenn meine SKY-Karte nicht antwortet (überlastet ist), die Abfrage an den anderen Proxy geht wo ja auch eine SKY-Karte steckt.

Vielen Dank

Gruss

karli9 · 2. September 2015

Hallo

Also ich bin bis jetzt noch nicht weiter gekommen, zu mal ich auch noch kein Feedback auf meine Configs bekommen habe.

Mich würde jedoch auch mal noch interessieren wo macht bei meinem Umfeld CacheEx Sinn, wo macht ein LoadBalancer Sinn, wo soll was aktiviert, resp. deaktiviert sein?

Vielen Dank

Hallo

Ich habe bei mir mal die komplette Cache-Sektion aus der oscam.conf genommen und da hat es wieder funktioniert. Eigentlich hatte ich CacheEx schon über ein Jahr auf dem Server aktiv (Mode 3), doch vor 3 Woche habe ich auf dem Server einen Peer mit (Mode 2) aufgenommen, kann das vielleicht das Problem sein, das mein Server ein Problem hat wenn Mode 2 und 3 zusammen laufen?

Weil langsam weiss ich echt nicht mehr wo ich noch nach dem Fehler suchen soll, SKY-Sender die eigentlich hell werden sollen, werden mal hell und dann werden sie wieder nicht hell und laufen in ein (wait_time over). Ich habe auch irgendwie das Gefühl das wenn ein Sender dunkel wird, er dann wie gesperrt ist für eine Zeit, kann das sein?

Vielen Dank

Gruss

janni1 · 3. September 2015

AW: SKY V14 - wait_time over

Hi,
ja genau so ist es. Dafür ist der Loadbalancer zuständig.
Dieser sperrt z.B. bei Fehlanfragen den entsprechenden Sender für genau "lb_reopen_seconds"
Damit so etwas nicht passiert, sollte man bei Reader bei denen man genau weiß, was diese können müssen,
(z.b. lokalen Karten) mit lb_whitelist_services arbeiten.
Diese Sender werden dann nie vom LB geblockt.

Gruß
janni1

karli9 · 3. September 2015

AW: SKY V14 - wait_time over

@janni1

Also ich habe auf meinem CardServer beim V14 Reader nun diese Einträge drin, ist das so korrekt?

[reader]
label = SKY
description = V14 (NDS)
enable = 1
protocol = smartreader
device = Serial:Reader B9B87E5
caid = 098C
services = !SKY_HDplus,!SKY_ORF
boxid = 12345678
ins7e11 = 13
detect = cd
mhz = 450
cardmhz = 2700
group = 6
emmcache = 1,2,2,0
lb_weight = 300
blockemm-unknown = 1
blockemm-u = 1
blockemm-s = 1
blockemm-g = 1
saveemm-u = 1
ndsversion = 2
lb_whitelist_services = SKY

Auf dem vServer wo jedoch reine Proxies drin sind, da wird man den Parameter "lb_whitelist_services" wohl nicht setzen müssen oder?

Gruss

SKY V14 - wait_time over

karli9

Hacker

supraracer

DEB Inventar

karli9

Hacker

janni1

karli9

Hacker

janni1

karli9

Hacker

janni1

karli9

Hacker

janni1

axel

karli9

Hacker

karli9

Hacker

janni1

karli9

Hacker

Ähnliche Themen

SKY V14 - wait_time over

Hacker

DEB Inventar

Hacker

Hacker

Hacker

Hacker

Hacker

Hacker

Hacker

Ähnliche Themen

Datenschutz & Transparenz

Datenschutz & Transparenz