Plötzliche Fehler im Oscam Log

[torty85]

habe keinen einzigen pay

 

[bubbl]

Aha

 

[torty85]

Warum so verwundert? Ist das so außergewöhnlich? Wie dem auch sei, gibt es eine Möglichkeit den beiden Boxen nur die CWs der proxies weiterzuleiten, deren gruppen ich denen vergeben habe, so dass nichts über cache von anderen proxies rein kommt. das würde mir zur Eingrenzung schon ernorm helfen.

 

[glaubichnicht]

Erstmal kann es sein das du nichts bezahlt hast. Aber irgendjemand wird dafür zahlen.
Keiner zahlt ein Abo bei Sky und erwartet nicht das man sich an den Kosten beteiligen soll.
Da es jetzt nur eine Vermutung ist, gehe ich davon aus, dass du den Karteninhaber nicht kennst.

Viele denken bei solche Konstellation das sie an der Situation was ändern können.
Das könnt ihr nicht. Den Takt gibt die Quelle an. Und wenn da nur Müll kommt, musst du den Müll annehmen. Auch wenn du es blocken würdest, fehlt genau zu der Zeit eine sauberes CW. In deinem Fall liefert einer der Quellen bei deinem kostenlosen Partner keine mehr.

 

[torty85]

Im Wort Cardsharing steckt die Antwort der "Bezahlung" ja schon. So waren die Ursprünge und bei mir war es nie anders, ist vielleicht nicht mehr selbstverständlich.

Kann es sein dass es keine Möglichkeit gibt die Anfragen auf ein oder zwei zugeordneten proxies zu begrenzen, ohne "unerwünschten" cache von anderen Proxies zu erhalten, da auf diese Möglich noch niemand eingegangen ist?

Edit:
Beim Blick in meine Config kann ich mir die 50ms / 51ms nun auch erklären (delay). Habe hier vor längerem mal diese Einstellung gesetzt:

Spoiler

[cache]
delay = 50
max_time = 11

Hier stellt sich mir nun die Frage, ob ich den Cache (zumindest für Testzwecke) so beeinflussen kann, wie ich das gerne hätte. Zum einen könnte ich den delay-Wert so hoch setzen, dass der cache langsamer ist als "normale" Anfragen. Zum anderen könnte ich max_time auf 0 setzen, was aber wohl nicht funktioniert, da der Wert laut Hilfe 3,5s über clienttimeout sein muss. Somit bleibt nur der Weg über "delay", z.B. delay = 5000, wenn ich den cache praktisch komplett deaktivieren möchte, richtig?

Hier mal meine gesamte Config, könnte vielleicht auch hilfreich sein:

# oscam.conf generated automatically by Streamboard OSCAM 1.20_svn SVN r11715
# Read more: https://svn.streamboard.tv/oscam/trunk/Distribution/doc/txt/oscam.conf.txt

[global]
logfile                       = /usr/local/bin/log/oscam.log
usrfileflag                   = 1
clienttimeout                 = 6000
fallbacktimeout               = 2000
clientmaxidle                 = 200
unlockparental                = 1
nice                          = -1
maxlogsize                    = 4096
waitforcards_extra_delay      = 5000
readerrestartseconds          = 7200
dropdups                      = 1
usrfile                       = /usr/local/bin/log/userfile
mailfile                      = /usr/local/bin/log/mail
emmlogdir                     = /usr/local/bin/log/emm
lb_mode                       = 1
lb_save                       = 5000
lb_max_ecmcount               = 3000
lb_retrylimit                 = 2400
lb_stat_cleanup               = 168
lb_auto_betatunnel            = 0
lb_auto_betatunnel_prefer_beta= 70
lb_savepath                   = /usr/local/bin/log/oscam.stats
lb_auto_timeout_p             = 70
ecmfmt                        = c@p s/i/d/l CW:w HOP:j
resolvegethostbyname          = 1
failbantime                   = 1440
disablecrccws_only_for        = 0500:030B00,060A00,060C00;1819:00006D;09C4:000000;098C:000000;1884:000000;1841:000000;1811:003311,003315;1883:003311;092B:000000;1813:000068;0B01:000000;098D:000000;098E:000000;091F:000000;1813:000000;0963:000000;0961:000000;0960:000000;1834:000000;1838:000000

[cache]
delay                         = 50
max_time                      = 11

[cccam]
port                          = xxxxx
nodeid                        = xxxxx
version                       = 2.3.0
reshare                       = 1
recv_timeout                  = 4000

[monitor]
port                          = xxxxx
nocrypt                       = 127.0.0.1
monlevel                      = 4

[webif]
httpport                      = xxxxx
httpuser                      = xxxxx
httppwd                       = xxxxx
httphelplang                  = de
httprefresh                   = 86400
httppiconsize                 = 25
httpallowed                   = 10.8.0.0-10.8.255.255,192.168.0.0-192.168.178.255,127.0.0.1,255.255.255.255,255.255.255.255

Danke nochmals.

 

[DaHooD]

Du kannst über die oscam.dvbapi gewisse CAIDs forcieren, bzw komplett ignorieren.
Damit lassen sich dann leicht die Anfragen auf das nötigste begrenzen.

Die 50 ms sollten nicht stören, ganz im Gegenteil, bei manchen Sendern darf die Antwort nicht zu schnell kommen

 

[torty85]

Durch einen Tipp habe ich das mit dvbapi bereits gelöst, danke.

Allerdings habe ich noch 2 Probleme, für die ich noch eine Lösung suche. Wenn klar ist, dass es keine Lösung gibt, wäre ich auch um eine Rückmeldung dankbar, dann brauche ich da erstmal nicht weiter suchen. Folgende Probleme habe ich noch:

1. Ich möchte keine Cache-CWs an Clients weiterleiten, deren Gruppen ich nicht zugeordnet habe. Habe ich einem Receiver nur Gruppe 1 und 2 zugeordnet, so soll er keine Cache-CWs von Gruppe 3, 4 usw. erhalten.

2. Wenn ich in das Log schaue, so habe ich den Verdacht, dass auch Cache-Antworten mit genau der im Log definierten Mindestzeit Probleme verursachen. Müsste ich die Mindestzeit evtl. noch weiter anheben oder dürfte es ab 50ms ohnehin keine Probleme geben? Warum verursachen die Antwortzeiten mit genau 50 ms (handelt sich somit wohl um alle Cache-Zeit unter 50ms) solche Probleme und andere mit längeren Antwortzeiten nicht? Sind diese womöglich auch noch zu schnell, oder stimmt mit denen ohnehin etwas nicht? Allerdings konnte man im Log erkennen dass der CW den identischen Wert hat:

2024/04/13 19:07:11 02E0F6C6 c (ecm) Box2 (1838@000000 0069/0000/0000/92 CW:6FF83D0A43FD8C126B2D136FDFCB426C HOP:00): found (587 ms) by proxie2 (P/1/2/4) - Sky Sport Bundesliga HD
2024/04/13 19:07:15 3DFA2557 c (ecm) Box1 (1838@000000 0069/0000/0000/92 CW:6FF83D0A43FD8C126B2D136FDFCB426C HOP:00): cache1 (50 ms) by proxie2 - Sky Sport Bundesliga HD (cw count 3) (lg)

Danke für eure Hilfe.

 

[DarkStarXxX]

Was du willst oder nicht spielt im dem Fall keine Rolle.
Das ist der Interne OSCam Cache den kann man nicht deaktivieren.

 

[torty85]

OK, das hatte ich schon fast vermutet, dann war ja meine nächste Frage ob man das zumindest beeinflussen kann. Auch wenn es nicht die Dauerlösung sein soll, kann ich cache delay z.B. von 50 auf 5000 erhöhen und würde den Cache praktisch deaktivieren oder funktioniert das so nicht?

Um nochmal auf mein Beispiel zurpck zu kommen, warum wird das Bild bei Box2 mit found 587ms hell und bei Box1 mit cache 50ms nicht, obwohl gleicher ECM?

2024/04/13 19:07:11 02E0F6C6 c (ecm) Box2 (1838@000000 0069/0000/0000/92 CW:6FF83D0A43FD8C126B2D136FDFCB426C HOP:00): found (587 ms) by proxie2 (P/1/2/4) - Sky Sport Bundesliga HD
2024/04/13 19:07:15 3DFA2557 c (ecm) Box1 (1838@000000 0069/0000/0000/92 CW:6FF83D0A43FD8C126B2D136FDFCB426C HOP:00): cache1 (50 ms) by proxie2 - Sky Sport Bundesliga HD (cw count 3) (lg)

Mir ist gerade die Zeit noch aufgefallen 19:07:11 vs. 19:07:15. Könnte das die Erklärung sein? Kam die Anfrage von Box1 einfach zu spät beim Server an? Ist das auch der Grund warum Box 1 ofmals den Cache erhält aber dieser zu spät angefragt wird?

 

[DaHooD]

Der cache dient ja auch dazu, unnötige Anfragen zu reduzieren.

Um das etwas sicherer zu gestalten ein ordentliches CW erhalten zu haben kannst du den CW Count erhöhen, dann wird das CW erst weitergeleitet wenn es mehre Treffer mit gleicher Antwort gab.

Halt Stop Komando zurück, der CW Check geht nur bei CacheEx.

 

[torty85]

ok schade, das wäre an anderer Stelle nicht verkehrt gewesen, auch wenn es für mein Beispiel oben keine Auswirkung gehabt hätte, da der CW ja wohl OK ist, da das Bild auf einer Box hell wurde. Ist in meinem Fall aber wohl nicht der Cache sondern der Zeitversatz 19:07:11 vs. 19:07:15 das Problem, oder?

 

[DaHooD]

In der Regel ist das CW bei dem Service für ca 7s gültig. Wenn die Anfrage incl Antwortzeit zu spät eintrifft, gilt natürlich das CW nicht mehr.

In den Falle würde ich mal versuchen, das Cache Delay auf 0 zu setzen, und die maximale Gültigkeitsdauer des CW's zuverkürzen. (7s ?)
Das sind die ersten beiden oben in den Cache - Einstellungen vom WebIF

 

[torty85]

In wieweit meinst du, dass dies das Problem löst? Ich kann zwar von 50ms auf 0ms runter gehen aber da gewinne ich nur sehr wenig Zeit also definitiv unter 50ms. Ich gehe davon aus dass es an dem sehr geringen Zeitgewinn nicht liegt. Es wäre ja schon ausreichend wenn die Antwort nach 4000ms eintrifft.

Die gültigkeitsdauer kann ich nicht wirklich verkürzen. Laut Hilfe soll der Wert 3,5s über dem Client Timeout (bei mir 6s) liegen und dann bin ich ja schon fast bei meinen eingestellten 11 ms.

Damit es nicht unter geht hier nochmals meine Theorie, die bisher noch nicht bestätigt oder dementiert wurde. Dürfte das Problem nicht daran liegen, dass die Anfrage auf dem Server von Box1 mit 4 Sekunden Verspätung einfach zu spät eintraf:

2024/04/13 19:07:11 02E0F6C6 c (ecm) Box2 (1838@000000 0069/0000/0000/92 CW:6FF83D0A43FD8C126B2D136FDFCB426C HOP:00): found (587 ms)
2024/04/13 19:07:15 3DFA2557 c (ecm) Box1 (1838@000000 0069/0000/0000/92 CW:6FF83D0A43FD8C126B2D136FDFCB426C HOP:00): cache1 (50 ms)

Würde dann auch das Log des Clients erklären der Timeouts meldet.

Meine Erklärung: Box 1 und Box 2 fragen gleichzeitig an Box 2 erhält nach 578ms (+ wenige ms Transportzeit) das CW. Die Anfrage von Box 1 benötigt ca. 4s bis diese beim Server angelangt. Dieser antwortet schnell aus dem Cache, aber die Antwort kommt trotzdem nicht mehr rechtzeitig bei Box 1 an und erzeugt deshalb einen Timeout im log.

Habe ich einen Denkfehler oder könnte dies das Problem korrekt beschreiben?

Hier nochmals ein Auszug des Serverlogs das ich bereits gepostet habe, was meine Theorie wohl untermauert:

2024/04/13 19:06:56 3DFA2557 c  (ecm) box1 (1838@000000 0069/0000/0000/92 CW:89D9356EED61746BBA412B78232F6C74 HOP:01): cache1 (51 ms)
2024/04/13 19:06:56 3DFA2557 c  (ecm) box1 (1838@000000 0069/0000/0000/92 CW:89D9356EED61746BF49B5B1874BFF31B HOP:01): found (77 ms)
2024/04/13 19:06:56 3DFA2557 c  (ecm) box1 (1838@000000 0069/0000/0000/92 CW:1E11B2350E07B17C148D4205CADE791B HOP:01): found (433 ms)
2024/04/13 19:06:56 3DFA2557 c  (ecm) box1 (1838@000000 0069/0000/0000/92 CW:1E11B2350E07B17C148D4205CADE791B HOP:01): cache2 (304 ms)
2024/04/13 19:06:56 3DFA2557 c  (ecm) box1 (1838@000000 0069/0000/0000/92 CW:3FD9085F60FAC92C148D4205CADE791B HOP:01): found (843 ms)
2024/04/13 19:06:57 3DFA2557 c  (ecm) box1 (1838@000000 0069/0000/0000/92 CW:3FD9085F60FAC92C44A76456F383934F HOP:01): found (1538 ms)
2024/04/13 19:06:57 3DFA2557 c  (ecm) box1 (1838@000000 0069/0000/0000/92 CW:3FD9085F60FAC92C44A76456F383934F HOP:01): cache2 (1527 ms)
2024/04/13 19:06:58 3DFA2557 c  (ecm) box1 (1838@000000 0069/0000/0000/92 CW:B094E60E9CBB182844A76456F383934F HOP:01): found (1948 ms)
2024/04/13 19:06:58 3DFA2557 c  (ecm) box1 (1838@000000 0069/0000/0000/92 CW:B094E60E9CBB1828F49B5B1874BFF31B HOP:01): found (2348 ms)
2024/04/13 19:06:58 3DFA2557 c  (ecm) box1 (1838@000000 0069/0000/0000/92 CW:B094E60E9CBB1828F49B5B1874BFF31B HOP:01): cache2 (2345 ms)

Normal kommen zeitlich 2 Anfragen (von Box 1 und 2) beim Server an, dann ist 10 Sekunde Pause und es kommen wieder 2 Anfragen. Beim Auszug oben kann man erkennen, dass box 1 innerhalb von ca. 2 Sekunden 10 Anfragen macht, also der Zeitraum von ca. 1,5 Minuten TV schauen. Somit gab es hier wohl für 1,5 Minuten einen Verbindungsabbruch im Heimnetzwerk so dass die Anfragen nach erneutem Verbindungsaufbau geballt beim Server ankamen.

Grund ist mir zwischenzeitlich eigentlich auch klar. Bei Box 1 hängt ein Repeater dazwischen. Hatte ich nicht mehr auf dem Schirm da es die Receiver meiner Eltern im Elternhaus betrifft.

Mit diesen Erkenntnissen sind die ersten beiden Rückmeldungen (Quelle liefert nichts / Karte überlastet) wohl nicht korrekt.

Falls jemand noch eine andere Erklärung hat, kann derjenige sich gerne melden, aber für mich ist die Sache nun eigentlich klar.

Zielt etwas am Thema nun vorbei, aber ist das Repeaterverhalten normal, dass es hin und wieder zu solchen Problemen kommt? Verbindung von Box zum Repeater ist durchschnittlich und von Repeater zum Router auch. Beim Repeater handelt es sich um eine ausgediente Fritzbox 7330 SL. Könnte das noch ein Problem darstellen, dass eine Fritzbox umfunktioniert Repeater eine schlechtere Performance liefert als z.B. ein "richtiger" Fritz!Repeater?

Kann aber hierzu auch ein neues Thema im richtigen Bereich eröffnen.

 

[DaHooD]

Welches Protokoll benutzt du denn ? Die UDP Protokolle sind bei WiFi nicht zu empfehlen.

 

[torty85]

Wo meinst du bzw. wo muss ich schauen? Meinst du hier nun in Oscam eine Einstellung oder in der Fritzbox?