Hier fehlen mindestens zwei Anfragen bevor die Caid gewechselt wurde.
Ich vermute hier Verbindungsprobleme beim Clienten selber (evtl. Wlan oder Dlan).
Leider wurden im Log die ECM-Hashes geixxxt, sonst könnte man evtl. mehr dazu sagen.
hm.. Zeiten sind grenzwertig (bei v14), aber wohl noch im Rahmen. ich bleib bei der Vermutung, dass die Ursprungsserver teilweise einfach überlastet sind. deine Configs sehen soweit gut aus, aber reshare = 2 würde ich schleunigst (global!) ändern.
boah, die Zeiten sind ja teilweise Horror! ich würd den Clients auf jeden Fall einzelnen CAIDs zuweisen. bei jedem Senderwechsel wird teilweise ein anderer Server abgefragt (weil Cache schneller) und das führt zu kurzzeitigen Verbindungsverlusten. Beispiel: wenn z.B. Sat 1 geschaut wird und auf Pro 7 geschaltet wird (beides Fantasiewerte) verliert der Client den Server, weil eine andere Person bereits Pro 7 schaut und der Cache eine schnellere Antwort gibt.
versuch es mit dem Loadbalancer und lb_mode = 2.
ansonsten hab ich auch keine Idee mehr und mache Platz für andere
Hi,
das Log wurde sicherlich "ausgedünnt",
denn cache 2 kommt nur, wenn ein anderer Client den Sender parallel schaut.
Die Zeiten find ich jetzt nicht so dramatisch, denn wenn evtl zwei Sender auf dem selben Transponder abgerufen werden, verdoppeln sie sich auch schon mal.
Und so schlimm verbastelt find ich die Configs jetzt auch nicht, bis auf das Böse "ignorereshare = 1". Das geht gar nicht
Zu den Freezern bleibt es bei mir dabei: Es lag an "verlorenen" Anfragen, mit darauf folgendem Caidwechsel beim Clienten.
Evtl würde ich die 1843 noch mit in den Cyclecheck nehmen, nicht das da FakeCws über die Proxys kommen.
"ignorereshare = 1" sofort entfernt worden, warum das da drin war, keine Ahnung, jedenfalls nicht mit irgendeiner bösen absicht. Ich bescheisse hier niemanden und Share keine Karten bis ins All. Ich gebe meine Lokale Karte und nehme eine Lokale Karte. Nichtmal ein anderer Client (außer Freunde und Familie - und die Resharen nicht!!!) bekommt die Karte von jemand anderen. Bodenlose Frechheit mir sowas zu unterstellen @axfa77.
Den 1843 habe ich mal deaktiviert.
Ich habe nur die Zeit aus dem Log gepostet, bei dem der Client mir geschrieben hat, wo er Aussetzer hatte. Das war in der Zeit von ca. 20:30 bis 21:00Uhr.
@janni1 und/oder @Emperor288, können wir uns bitte dann noch meine LB Config anschauen, dass wir die auf den richtigen Weg bekommen. Denn dort habe ich seit ewigkeiten nichts mehr dran gemacht, wie man an der 1702 sieht
Wenn ANFRAGEN VERLOREN gehen, kann auch am Router NAT vom Server liegen. OSCam hält die Leitung ja teoretisch aufrecht. Ohne keep allive beim Client in der Servereinstellung könnte was verbessern. Zumindest trennt es 50% der User, die dann ZDF oder praktisch im Standby schlummern.
Nee dann = 0 ausschalten, also die Leitung bei Inaktivität schließen.
Ist übrigens auch bei Massenauswürfen der Grund, das die Verbindungen kurz reißen, wenn zuviel Verbindungen gehalten werden. Bei Einzelfälle liegt es am Client Netzwerk, oder ein einem Verbindungsknoten. Zu messen mit Pingplotter.
2018/03/16 20:36:27 524DCD14 c (ecm) cl1 (1830@000000/0000/EF75/92:5681254B5CED3CBAC69E3020C5E979BE): found (305 ms) by Ma (P/1/2/3) - ProSieben HD
2018/03/16 20:36:41 524DCD14 c (ecm) cl1 (1830@000000/0000/EF75/92:33E17BB429F0FD7D0E250EA5AD68AFEE): found (23 ms) by Ma (P/1/2/3) - ProSieben HD
2018/03/16 20:36:41 524DCD14 c (ecm) cl1 (1830@000000/0000/EF75/92:33E17BB429F0FD7D0E250EA5AD68AFEE): cache2 (22 ms) by Ma (P/1/2/3) - ProSieben HD
2018/03/16 20:36:41 524DCD14 c (ecm) cl1 (1830@000000/0000/EF75/92:7EE93C34F96F583C6308AF5EE6910C57): found (265 ms) by Ma (P/1/2/3) - ProSieben HD
2018/03/16 21:08:53 524DCD14 c (ecm) cl1 (1830@000000/0000/EF75/92:C96EE3C7E1757EE44629B64EEF0F5C31): found (23 ms) by Ma (P/1/2/3) - ProSieben HD
2018/03/16 21:08:54 524DCD14 c (ecm) cl1 (1830@000000/0000/EF75/92:15A5C6C283428E0093E4E669CE20B101): found (578 ms) by Ma (P/1/2/3) - ProSieben HD
2018/03/16 21:08:54 524DCD14 c (ecm) cl1 (1830@000000/0000/EF75/92:15A5C6C283428E0093E4E669CE20B101): cache2 (579 ms) by Ma (P/1/2/3) - ProSieben HD
2018/03/16 21:08:54 524DCD14 c (ecm) cl1 (1830@000000/0000/EF75/92:C96EE3C7E1757EE44629B64EEF0F5C31): cache1 (1 ms) by Ma - ProSieben HD
Die Anfragen kommen außerhalb des Zykluses (bei Pro7 sind das 7sec.) und werden doppelt gestellt. Bleiben also irgendwo auf der Strecke.
Wenn er der einzige ist der Probleme hat, wird es wohl bei ihm liegen.
Ungesehen würd ich auf Billigreceiver bei den andern Clienten Tippen, und du der einzigste mit einem gescheiten Receiver hast keine Probs.
War auch mal meine Konstellation da ich den "andern" keine Linuxkiste zugetraut hatte, was einem aber unterm Strich dann mehr Nerven kostet.