gelöst Frage zur Bedeutung im Log

MKLST2 · 15. Mai 2019

Hi,

ich betreibe eine DM900 an einem Raspberry Pi3 mit Oscam. Ich habe hier eine HD+Karte die ich weitershare. Zusätzlich bin ich mit einem Cacheex-Server verbunden.
Das alles läuft auch soweit ruckelfrei. Mir ist aber die Meldung

2019/05/15 18:41:47 64DE2BB4 c (ecm) DM900 (1830@000000/0000/EF76/92:84F84D39D6CED9A3348D349F59BFE8A4): cache3 (492 ms) by cacheex - kabel eins HD (wait_time over)

nicht verständlich. Was soll "(wait time over)" bedeuten?

PS: Wieso kann ich nur mit dem Präfix "gelöst" hier posten?

pehedima · 15. Mai 2019

MKLST2 schrieb:
PS: Wieso kann ich nur mit dem Präfix "gelöst" hier posten?

Das haben wir extra so eingebaut, damit wird weniger Arbeit haben. :smile:
Spaß, seit dem es den Präfix 'gelöst' wieder gibt, ist das beim Erstellen einiger Threads so. Danach kann man den wieder löschen. Wird noch geklärt. Habe das schon entsprechend geändert.

Zu deinem Problem:
Schau mal in deine oscam.conf, was unter wait_time dort definiert ist.

MKLST2 · 15. Mai 2019

oscam.conf

[cache]
wait_time = 1830:400,098C:110

janni1 · 15. Mai 2019

Hi,
der Eintrag ist ganz normal.
Währen der Waittime taucht das geforderte CW (oder der geforderte Count dieses) nicht im Cache auf und die Anfrage geht an einen Reader.
Während der Beantwortungszeit des Readers, taucht das Geforderte nun doch noch auf und der Hit wird aus dem Cache genommen,
auch nach Ablauf der Waittime, deshalb "(wait_time over)".
Die Karte/Proxy wurde zusätzlich und umsonst angefragt und die Antwort verworfen.

Problem mit wait time Cacheex3

Moin Leute, habe ein Problem mit dern "wait time" Einstellungen für meine Debian server, welche ich im Oscam Webif eintrage. cccam protokoll 2x HD02, 2x 098C loadbalancer aktiv Cacheex3 aktiv Ich bin mir nicht sicher ob meine config in Ordnung ist, bzw. was man noch verbessern könnte...

www.digital-eliteboard.com

Bei dir ist in diesem einen speziellen Fall die Waittime zu niedrig.
Das Cw ist erst nach 492ms im Cache aufgetacht und du hast laut waittime nur 400ms gewartet, bevor du deine Karte (umsonst) angefragt hast.

MKLST2 · 15. Mai 2019

Soll ich alles so belassen oder soll ich die Waittime erhöhen, um die Meldung los zu werden?

janni1 · 15. Mai 2019

Hi,
kommt drauf an, wie oft sie bei dir auftaucht
400ms könnten bei 1830 schon etwas knapp sein, bei schlechterem bzw. über mehrer Hops kommendem Cache.
Ich würde es evtl mit 500ms versuchen.

MKLST2 · 15. Mai 2019

OK, ich werde das mal testen.

Tec-Hi · 15. Mai 2019

Hi

ich schraub die etwas höher, schau mal im Zitat nach "Verwendungspraxis:"

wait_time

Sie müssen registriert sein, um Links zu sehen.
Parameter ist optional
NEU svn 8358:02/16/2013

Wartezeit und Dynamische Wartezeit in Millisekunden für cache exchange und CSP, bevor ECMs an den Reader/Proxy gesendet werden.

wait_time = [caid][&mask][@provid][$servid][:awtime][:]dwtime,n
wait_time = [blank] none (default)

Info:
awtime --> Zeit die bei jeder Anfrage gewartet wird (always wait time)
dwtime --> Zeit die bei positivem Fund eines CWs im Cache gewartet wird (dynamic wait time)

Beispiel:
wait_time = 0:50:250,0200@00009X:50:150,15:950,0500@000001:150,1602&ffdf:1200

Verwendungspraxis:
wait_time = 098C:5:130,09C4:5:130,1702:5:1900,1830:5:490,1843:5:490

HF

MKLST2 · 15. Mai 2019

OK, ich hab es jetzt mal nach Empfehlung eingestellt.

wait_time = 1830:490,098C:130

2019/05/15 19:46:13 1844EAAE c (ecm) xxxxx (1830@000000/0000/EF75/92:531798FFF7BE0C2AFFBB21CE5FAB7D1F): cache3 (357 ms) by cacheex - ProSieben HD
2019/05/15 19:46:14 0EC7E349 c (ecm) DM900 (1830@000000/0000/EF11/92:0FF035AF2275861EAA7B5BE627685291): cache3 (343 ms) by cacheex - VOX HD
2019/05/15 19:46:24 0EC7E349 c (ecm) DM900 (1830@000000/0000/EF11/92:smiley:EBBDBAD5CB3F85D2C7039461902BC62): cache3 (346 ms) by cacheex - VOX HD
2019/05/15 19:46:28 1844EAAE c (ecm) xxxxx (1830@000000/0000/EF75/92:8DE5BF1E09D796904DDC8904A62F6575): cache3 (353 ms) by cacheex - ProSieben HD
2019/05/15 19:46:34 0EC7E349 c (ecm) DM900 (1830@000000/0000/EF11/92:FE8A756DCFB05F54695159AD82EE46B8): cache3 (429 ms) by cacheex - VOX HD
2019/05/15 19:46:43 1844EAAE c (ecm) xxxxx (1830@000000/0000/EF75/92:5B0DE85825892E18E09ED38557A3D499): cache3 (353 ms) by cacheex - ProSieben HD
2019/05/15 19:46:44 0EC7E349 c (ecm) DM900 (1830@000000/0000/EF11/92:B473E9E885A62BB59928EC06A54D17C7): cache3 (352 ms) by cacheex - VOX HD

DarkStarXxX · 15. Mai 2019

Als Fausregel hat sich bei mir bei den meisten Caids erwiesen: Kartenantwortzeit + 50% = Waittime

janni1 · 15. Mai 2019

Hi,
schau dir am besten deine Zeiten an!
Mit 490ms hättest du im oberen Fall auch ein "(wait_time over)" gehabt.
Waittimes sind immer individuell und in der Regel nicht übertragbar.

In der Regel nimmt man Kartenzeit +1/3 + 50ms pro Hop
Mit Nagracaids auch eher unkritsch, da würde sogar, wenn die Karte im Notfall schnell antwortet 800 - 1000ms noch gehen

MKLST2 · 16. Mai 2019

Ich habe jetzt mal auf wait_time = 1830:400,098C:170 gestellt.
So ruckelt hier nichts mehr. Wenn ich die 1830 auf 500 stellt, bleibt sie ab und zu hängen.

edit: noch eine Frage zur Bedeutung. Was sagt das hier?

2019/05/16 15:36:10 6F432FF9 c (ecm) Helmut (1830@000000/0000/EF75/92:A946EE81D5C34D37A46FB1C7FCE60275): cache1 (346 ms) by HD+ - ProSieben HD (cw count 2)

cw count 2?

janni1 · 16. Mai 2019

Hi,
du hast das cw von zwei verschieden Quellen bekommen.
Bei dir im Fall (cache 1) hatte deine Karte bereits ein CW berechnet, weil bereits jemand den Kanal geschaut hat.
Ein weiteres kam warscheinlich über CE.
Die Zeit dabei ist aber seltsam. Hast du evtl. etwas bei "cacheex_cw_check =" gesetzt?

MKLST2 schrieb:
Wenn ich die 1830 auf 500 stellt, bleibt sie ab und zu hängen.

Das ist sehr ungewöhnlich, ein Log und die Configs wären hier interessant.

MKLST2 · 16. Mai 2019

Hi janni1,
hier die Configs und Logs:

2019/05/16 16:09:36 00000000 s (main) System name = Linux
2019/05/16 16:09:36 00000000 s (main) Host name = raspberrypi
2019/05/16 16:09:36 00000000 s (main) Release = 4.9.35-v7+
2019/05/16 16:09:36 00000000 s (main) Version = #1014 SMP Fri Jun 30 14:47:43 BST 2017
2019/05/16 16:09:36 00000000 s (main) Machine = armv7l
2019/05/16 16:09:36 00000000 s (main) creating pidfile /tmp/.oscam/oscam.pid with pid 20694
2019/05/16 16:09:36 00000000 s (config) services reloaded: 0 services freed, 13 services loaded, rejected 0
2019/05/16 16:09:36 00000000 s (config) userdb reloaded: 6 accounts loaded, 0 expired, 0 disabled
2019/05/16 16:09:36 00000000 s (main) signal handling initialized
2019/05/16 16:09:36 00000000 s (config) 187 service-id's loaded in 1 ms
2019/05/16 16:09:36 00000000 s (config) 12 tier-id's loaded
2019/05/16 16:09:36 00000000 s (net) cs378x: initialized (fd=5, port=xxxxx, ip=192.168.8.10)
2019/05/16 16:09:36 00000000 s (reader) HD+ [mouse] creating thread for device /dev/HD+
2019/05/16 16:09:36 00000000 s (reader) xxxx [cs378x] creating thread for device xxxxx
2019/05/16 16:09:36 00000000 s (reader) ORF1 [cs378x] creating thread for device xxxxx
2019/05/16 16:09:36 00000000 s (reader) cacheex [cs378x] creating thread for device xxxxx
2019/05/16 16:09:36 00000000 s (main) waiting for local card init
2019/05/16 16:09:36 27675C3D p (reader) ORF1 [cs378x] proxy xxxxx
2019/05/16 16:09:36 27675C3D p (reader) ORF1 [cs378x] proxy initialized, xxxx
2019/05/16 16:09:36 29DE871C p (reader) Rob [cs378x] proxy xxxxx
2019/05/16 16:09:36 29DE871C p (reader) Rob [cs378x] proxy initialized, xxxxx
2019/05/16 16:09:36 588DBD23 p (reader) cacheex [cs378x] proxy xxxxx
2019/05/16 16:09:36 39B69C74 h (webif) webif: decompressed 179776 bytes back into 443592 bytes
2019/05/16 16:09:36 39B69C74 h (webif) HTTP Server running. ip=192.168.8.10 port=16002
2019/05/16 16:09:36 588DBD23 p (reader) xxxxx: resolved ip=xxxxx
2019/05/16 16:09:36 588DBD23 p (reader) cacheex [cs378x] connecting to xxxxx
2019/05/16 16:09:36 588DBD23 p (reader) cacheex [cs378x] proxy initialized, xxxxx
2019/05/16 16:09:36 6FC93465 r (reader) HD+ [mouse] Reader initialized (device=/dev/HD+, detect=cd, mhz=357, cardmhz=357)
2019/05/16 16:09:37 6FC93465 r (reader) HD+ [mouse] card detected
2019/05/16 16:09:38 6FC93465 r (reader) HD+ [mouse] ATR: 3F FF 95 00 FF 91 81 71 FE 47 00 44 4E 41 53 50 31 34 32 20 52 65 76 47 43 36 61
2019/05/16 16:09:38 6FC93465 r (reader) HD+ [mouse] Setting baudrate to 111600 bps
2019/05/16 16:09:39 6FC93465 r (reader) HD+ [mouse] detect native nagra card
2019/05/16 16:09:40 6FC93465 r (reader) HD+ [mouse] ready for requests
2019/05/16 16:09:40 6FC93465 r (reader) HD+ [mouse] found card system nagra
2019/05/16 16:09:40 6FC93465 r (reader) HD+ [nagra] THIS WAS A SUCCESSFUL START ATTEMPT No 1 out of max allotted of 1
2019/05/16 16:09:40 6FC93465 r (reader) HD+ [nagra] ROM: D N A S P 1 4 2
2019/05/16 16:09:40 6FC93465 r (reader) HD+ [nagra] REV: R e v G C 6
2019/05/16 16:09:40 6FC93465 r (reader) HD+ [nagra] SER: ############
2019/05/16 16:09:40 6FC93465 r (reader) HD+ [nagra] CAID: 1830
2019/05/16 16:09:40 6FC93465 r (reader) HD+ [nagra] Prv.ID: 00 00 34 11 (sysid)
2019/05/16 16:09:40 6FC93465 r (reader) HD+ [nagra] Prv.ID: 00 00 00 00
2019/05/16 16:09:40 6FC93465 r (reader) HD+ [nagra] IRD ID: ############
2019/05/16 16:09:40 6FC93465 r (reader) HD+ [nagra] active to: 2019/07/07 12:59
2019/05/16 16:09:41 6FC93465 r (reader) HD+ [nagra] -----------------------------------------
2019/05/16 16:09:41 6FC93465 r (reader) HD+ [nagra] |id |tier |valid from |valid to |
2019/05/16 16:09:41 6FC93465 r (reader) HD+ [nagra] +----+--------+------------+------------+
2019/05/16 16:09:41 6FC93465 r (reader) HD+ [nagra] |8011|0064 |2015/06/06 |2016/06/06 |
2019/05/16 16:09:41 6FC93465 r (reader) HD+ [nagra] |8011|0BEA |2018/06/07 |2019/06/08 |
2019/05/16 16:09:41 6FC93465 r (reader) HD+ [nagra] |8011|0065 |1992/01/01 |1993/01/01 |
2019/05/16 16:09:41 6FC93465 r (reader) HD+ [nagra] -----------------------------------------
2019/05/16 16:09:41 00000000 s (main) init for all local cards done
2019/05/16 16:09:41 00000000 s (emmcache) loaded 0 emmcache records from /tmp/.oscam/oscam.emmcache in 0 ms
2019/05/16 16:09:41 00000000 s (emmcache) loaded 0 emmstat records from /tmp/.oscam/oscam.emmstat in 0 ms
2019/05/16 16:09:41 00000000 s (anticasc) anti cascading disabled
2019/05/16 16:09:41 36A43B1A c (client) encrypted cs378x-client xxxxx granted (Helmut, au=off)
2019/05/16 16:09:41 3A13A190 c (client) encrypted cs378x-client xxxxx granted (WolfSohn, au=off)
2019/05/16 16:09:41 36A43B1A c (ecm) Helmut (1830@000000/0000/EF75/92:C5DD307F3B79EDC6161A4C02BBA21145): cache3 (98 ms) by cacheex - ProSieben HD
2019/05/16 16:09:42 3A13A190 c (ecm) xxxxx (1830@000000/0000/EF75/92:C5DD307F3B79EDC6161A4C02BBA21145): cache3 (339 ms) by cacheex - ProSieben HD (cw count 2)
2019/05/16 16:09:44 26EA8BB8 c (client) encrypted cs378x-client 192.168.8.9 granted (DM900, au=off)
2019/05/16 16:09:44 26EA8BB8 c (ecm) DM900 (1830@000000/0000/EF10/92:8CD585AD8FAEC8991AC46BDF1492FA61): found (323 ms) by HD+ - RTL HD
2019/05/16 16:09:48 77771531 c (client) encrypted cs378x-client xxxxx granted (xxxxx, au=off)
2019/05/16 16:09:54 26EA8BB8 c (ecm) DM900 (1830@000000/0000/EF10/92:90AEEE57BB71BCC4504B8D021F7E334C): found (323 ms) by HD+ - RTL HD
2019/05/16 16:09:56 3A13A190 c (ecm) xxxxxx (1830@000000/0000/EF75/92:89DBCC4401756CF324F352CE8E387D2C): found (323 ms) by HD+ - ProSieben HD
2019/05/16 16:09:56 36A43B1A c (ecm) Helmut (1830@000000/0000/EF75/92:89DBCC4401756CF324F352CE8E387D2C): cache3 (347 ms) by cacheex - ProSieben HD (cw count 2)

[global]
serverip = 192.168.8.10
logfile = /var/log/ipc/OScam.log
maxlogsize = 2480
preferlocalcards = 1
readerrestartseconds = 2
dropdups = 1
block_same_ip = 0

[cache]
delay = 10
max_time = 20
wait_time = 1830:400,098C:170
[cs378x]
port = xxxxx
serverip = 192.168.8.10

[webif]
httpport = 16002
httpuser = oscam
httppwd = xxxxx
httprefresh = 15
httpshowmeminfo = 1
httpshowuserinfo = 1
httpshowreaderinfo = 1
httpshowcacheexinfo = 1
httpshowecminfo = 1
httpshowloadinfo = 1
httpallowed = 192.168.8.5
httposcamlabel = OSCam Raspberry
http_status_log = 1

[account]
user = DM900
pwd = xxxxx
description = Home
group = 1,2,3,4

[account]
user = xxxxx
pwd = xxxxx
keepalive = 1
allowedprotocols = cs378x
group = 2
cccreshare = 0

[account]
user = xxxxx
pwd = xxxxx
keepalive = 1
allowedprotocols = cs378x
group = 2
cccmaxhops = 2
cccreshare = 0

[account]
user = Helmut
pwd = xxxxx
description = DM900
allowedprotocols = cs378x
group = 2,10
cccmaxhops = 2
cccreshare = 0

[account]
user = xxxxx
pwd = xxxxx
allowedprotocols = cs378x
group = 2
cccmaxhops = 2
cccreshare = 0

[account]
user = xxxxx
pwd = xxxxxx
keepalive = 1
allowedprotocols = cs378x
group = 2
cccreshare = 1

[reader]
label = HD+
description = HD+ reader
protocol = mouse
device = /dev/HD+
services = hd+
fallback = 1
caid = 1830
boxkey = A7642F57BC96D37C
rsakey = BF358B5461863130686FC933FB541FFCED682F3680F09DBC1A23829FB3B2F766B9DD1BF3B3ECC9AD6661B753DCC3A9624156F9EB64E8168EF09E4D9C5CCA4DD5
detect = cd
group = 2
emmcache = 1,3,2,0
blockemm-g = 1

[reader]
label = xxxx
description = Yks
protocol = cs378x
device = xxxxxx
user = xxxxx
password = xxxxxx
services = !hd+,sat-sky-starter,sat-sky-entertainment,sat-sky-cinema,sat-sky-cinemahd,sat-sky-sportsd,sat-sky-sporthd,sat-sky-bundesligasd,sat-sky-bundesligahd,sat-sky-bluemovie,sat-sky-select,sat-sky-sonstige,!orfice
fallback = 1
group = 4
disablecrccws_only_for = 098C:000000
audisabled = 1

[reader]
label = ORF1
protocol = cs378x
device = xxxxx
user = xxxxx
password = xxxxx
services = orfice
caid = 0648
group = 1
cccreshare = 1
ccchop = 2
audisabled = 1

[reader]
label = cacheex
protocol = cs378x
device = xxxxx
user = xxxxx
password = xxxxx
inactivitytimeout = 60
reconnecttimeout = 60
keepalive = 1
disablecrccws_only_for = 098C:000000
cacheex = 2
cacheex_ecm_filter = 1830,098C
cacheex_drop_csp = 1
cacheex_block_fakecws = 1
group = 10
dropbadcws = 1
ccchop = 3
audisabled = 1

janni1 · 16. Mai 2019

Hi,
configs und log sehen soweit gut aus.
Es darf aber nur "Helmut" den Cache nutzen, da nur dieser Gruppe 10 hat.
Wenn das so gewollt ist -warum auch immer-, würde ich bei allen anderen Usern "no_wait_time = 1"setzen, da sonst hier auch die Waittime ausgelöst wird.
Eine andere Variante wäre, bei Ihnen Gruppe 10 zu erlauben aber die Caids zu beschränken.

gelöst Frage zur Bedeutung im Log

MKLST2

Elite Lord

pehedima

MKLST2

Elite Lord

janni1

Problem mit wait time Cacheex3

MKLST2

Elite Lord

janni1

MKLST2

Elite Lord

Tec-Hi

MKLST2

Elite Lord

DarkStarXxX

janni1

MKLST2

Elite Lord

janni1

MKLST2

Elite Lord

janni1

Ähnliche Themen

gelöst Frage zur Bedeutung im Log

Elite Lord

Elite Lord

Elite Lord

Elite Lord

Elite Lord

Elite Lord

Elite Lord

Ähnliche Themen

Datenschutz & Transparenz

Datenschutz & Transparenz