Mini Freezer wenn cache1 oder cache 2 kommt

[saerdnast]

Ich habe Mini Freezer /kurzes stottern vom Bild /Klötzchenbildung wenn die Antwort aus dem Cache kommt

Jedesmal wenn die Antwort aus dem cache1 oder cache2 kommt passiert es.
Kommt es von der Karte direkt alles ok
Was kann das sein
Hier einer kleiner Auszug meiner Configs und der Log

Spoiler: Conf

Du musst dich Anmelden oder Registrieren um diesen Inhalt sichtbar zu machen!

Spoiler: Server

Du musst dich Anmelden oder Registrieren um diesen Inhalt sichtbar zu machen!

Spoiler: log

Du musst dich Anmelden oder Registrieren um diesen Inhalt sichtbar zu machen!

Danke

Jetzt wieder 20 Minuten kein einziger Aussetzer Ruckler alles kommt von der V141 und kein einziger cache dabei
Wie kann ich das verhindern abschalten?

 

[janni1]

Hi.
die Frage ist hier, wieso es überhaupt zu cache1 oder cache2 -Hits kommt bei nur einem Client.
Meist deutet es auf Netzwerkprobleme hin. Es werden wohl Pakete abhanden Kommen.
Wie ist denn der Client mit dem Server verbunden? (Lan/Wlan/Dlan)

 

[saerdnast]

Per Wlan aber das schon seit über 2 Jahre und keine Probleme bisher
Ist ja HomeCs
Also kommt Cache 1 oder 2 nur wenn die Antwort der Karte nicht am Receiver ankam also Paketdatenverlust im Netzwerk? Richtig so?

 

[janni1]

Hi,
richtig,

cache2 kommt, wenn mit diesem ECM vorher schon mal angefragt wurde.
Die Karte wird dann nicht erneut angefragt, da die Anfrage an sie schon unterwegs ist.

cache1 kommt, wenn das CW von einer vorherigen Anfrage schon im Speicher liegt.

Es wurde also in beiden Fällen vom Client doppelt angefragt, weil es wohl einen Paketverlust gegeben hat.

Ich würde es evtl mal mit einem Fallback versuchen, so wie hier beschrieben.
HowTo - Antifreeze OScam Tweaking für fehleranfällige Anbindungen im HS (WLAN/dLAN)

 

[saerdnast]

Okay Danke könnte ich noch was verfeinern an meinen Einstellungen?
z.b. am cache den Delay oder so?

Und ich müsste den Loadbalancer abschalten wenn ich das benutze

 

[janni1]

Hi,
nein an den Einstellungen am Server brauchst du erstmal nichts ändern, auch den LB kannst du so laufen lassen.
Der Fallbackreader müßte ja auf den Client.
Ich würde es aber evtl. ,wenn möglich erstmal mit einem LanKabel versuchen .
Schau dir einfach noch mal dein Log an.
Die Anfragen sollten bei Sport HD1 genau alle 7sec am Server eingehen.
Dein Timing dagegen ist total aus dem Tritt.

 

[saerdnast]

Eigentlich hatte ich bisher noch nie Probleme damit gehabt erst seit ein paar Tagen
Hatte auch mal alles neu gestartet Router den Server und Receiver aber ich gehe davon aus das die
Fritzbox oder was mit meinem Netzwerk nicht stimmt . Mein Sohn sagte gerade das das Internet über Wlan seit ein paar Tagen spinnt
und das ist derselbe Wlan der den Receiver auch benutzt.

 

[janni1]

Hi,
um ganz sicher zu gehen, könntest du auch mal ein paar Pings vom Reci zum Server schicken und anders herum.
Dann siehst du, wie lang sie brauchen und wieviel da abhanden kommen.

 

[saerdnast]

vom Receiver zum Server? Wie mache ich das?

 

[janni1]

Hi,

• mit telnet auf die Box
• anmelden
• ping ip.des.ser.vers

abrechen/beenden kannst du das ganze dann mit strg+c

Es würde aber auch z.B. mit DCC (DreamboxControlCenter) funktionieren.

 

[Schimmelreiter]

Es gibt noch einen Grund, wieso es zu Freezern kommen kann, wenn die Antwort aus dem Cache stammt:
Sie ist zu schnell!

Die meisten haben immer nur möglichst kurze Antwortzeiten im Blick, es geht aber eben auch zu kurz.
Sinkt die Antwortzeit deutlich unter die Zeit, die bei einer Anfrage per Karte erreichbar wäre, dann gibt es genauso Freezer, als wenn gar keine oder eine zu späte Antwort käme.

Die gute Nachricht:
Das Problem ist ganz einfach lösbar.

Meine Clients haben alle in der oscam.dvbapi gleich am Anfang stehen:

Du musst dich Anmelden oder Registrieren um den Inhalt der Codes zu sehen!

D: <CAID> <Mindestzeit in ms>
verzögert das Weiterreichen der Antwort an die dvbapi auf (nicht um!) die jeweils angegebene Zeit.

Kommt also die Antwort auf eine Anfrage für CAID 098C schon nach 20ms rein, was bei mir durchaus häufiger vorkommt *g*, dann wird sie um weitere 100ms verzögert, damit die Gesamtzeit bei 120ms liegt, wie bei einer schnell angesprochenen Karte.
Bei einer Antwort nach z.B. 143ms hingegen wird nicht verzögert, da die Zeit ja bereits >120ms ist.

Insofern ist es eine der wenigen Einstellungen in oscam.dvbapi, mit denen man nicht wirklich viel falsch machen kann (Es sei denn man stellt kompletten Schwachsinn, z.B. für CAID 098C z.B. 500ms, ein).
Deshalb werden sie vermutlich auch so wenig beachtet, ich habe manchmal den Eindruck, die Leute basteln eher an der oscam.dvbapi rum, damit sie Probleme kriegen *g*

Man kann auch auf dem oscam-Server eine Verzögerung einstellen, die ist dann aber für alle User und alle CAIDs gleich und damit weniger gut geeignet.

 

[janni1]

Hi,
Wenn man das so wie von @Schimmelreiter beschrieben am Client eintragen möchte, sollte man unbedingt darauf achten, dass man mindestens eine Version ab 10946 einsetzt!

Spoiler

Du musst dich Anmelden oder Registrieren um diesen Inhalt sichtbar zu machen!

Man könnte dafür am Client auch global den Parameter "delayer" in [dvbapi] verwenden.
Dies verzögert alle CWs maximal auf den angegebenen Wert (Standard 60ms), was beim Emu/Key-Betrieb sehr sinnvoll ist.
Mit diesem Standardwert sollte aber in der Regel kein Muxer mehr Probleme haben, dass das CW zu schnell kommt.

Hier im obigen Fall sieht man aber schon am unregelmäßigen Eintreffen der ECMs und an Doppelanfragen, dass hier wahrscheinlich was an der Verbindung nicht stimmen kann.
Was hier speziell in diesem Fall kontraproduktiv ist, ist Parameter "delay = 80" unter [cache] am Server.
Wenn es schon durch Probleme zu erhöhter Latenz oder durch Paketverlusten zu Doppelanfragen und damit zu Cache1-2 Hits kommt, sollte man die Antwort nicht auch noch "verlängern"