Dreambox 520, Oscam, v13: Bild pixelig

Ich habe hier einen Raspi mit OScam und einer Easymouse2 um den sich im LAN 3 Dreamboxen gruppieren. Eine 920, die keinerlei Probleme macht und zwei 520 die mir Probleme bereiten. Dort gibt es immer wieder Bildstörungen in Form von pixeligen Bändern und wenn es dann grössere pixelige Flächen werden setzt auch mal der Ton kurz aus. Das Ganze tritt erst seit Umstellung der Verschlüsselung Ende 2019 auf. Vorher hatte ich solche Probleme nicht. Das Problem betrifft alle verschlüsselten Sender.

Raspi:


DM520:


Wenn ich Logs poste welche Live-Log-Einstellungen soll ich zur Analyse wählen?

Gibt es schon Ideen wie sich das fixen lässt? Netzwerkprobleme möchte ich ausschliessen. Gäbe es welche hätte mir das mein Monitoring gemeldet. Ausserdem hat ja vor der Verschlüsselungsumstellung alles funktioniert.

TIA

Schau mal nach wie hoch/niedrig der BER der Boxen ist ( Menü/einstellungen/Kanäle und Aufnahme / Kanalsuche / Satfinder )
Pixel haben nichts mit Oscam zu tun,da hast du Bild oder halt nicht


Und was soll der Newcamd kram,wird schon ewig nicht mehr genutzt,entweder cccam oder cs357x ( was ich bevorzuge)

Zumal du ALLE configs Posten solltest,mit Uasschnitten und ohne Log kann keiner was anfangen
Warum Blockst du?
Brauch kein mensch mehr

cojo schrieb:

Schau mal nach wie hoch/niedrig der BER der Boxen ist ( Menü/einstellungen/Kanäle und Aufnahme / Kanalsuche / Satfinder )
Pixel haben nichts mit Oscam zu tun,da hast du Bild oder halt nicht

Zum Vergrößern anklicken....

15,41 dB
SNR: 96
BER: 0

cojo schrieb:

Und was soll der Newcamd kram,wird schon ewig nicht mehr genutzt,entweder cccam oder cs357x ( was ich bevorzuge)

Zum Vergrößern anklicken....

Jahrzehnte lange Gewohnheit, kann ich ja mal umstellen.

cojo schrieb:

Zumal du ALLE configs Posten solltest,mit Uasschnitten und ohne Log kann keiner was anfangen

Zum Vergrößern anklicken....

Da scheiden sich hier im Forum die geister. Ich versuche es immer nach bestem Wissen so gut wie möglich zu machen bekomme aber IMMER Mecker

cojo schrieb:

Warum Blockst du?
Brauch kein mensch mehr

Zum Vergrößern anklicken....

Ganz meine Meinung, aber auch da scheiden sich hier im Forum die Geister. Ich hatte das hier: V13 - Sky plötzlich dunkel gefragt und mir wurde dort empfohlen weiter zu blocken ...

Würde mal umstellen

Da scheiden sich die Geister überhaupt nicht


Und du hast eine Oscam Frage

cojo schrieb:

Würde mal umstellen

Zum Vergrößern anklicken....

Du meinst sicher auf z.B. cs357x oder cccam, oder?

Poste erstmal die oscam.log zum Zeitpunkt der Freezer.

Hab jetzt erst mal auf cs357x umgestellt ... sieht für mich auf den ersten blick gut aus. Mehr weiss ich morgen wenn ich einen Erfahrungsbericht meiner Anwender habe Danke so weit. Ich berichte wieder.

Neugierhalber: wo liegen die Vor- und Nachteile der unterschiedlichen Protokolle? Und in welchere Situation (LAN/WAN) möchte man welches benutzen und warum?

Markante Eigenschaften der Protokolle:
cccam:
Dies ist, ungeachtet des Namens, praktisch das native Protokoll von oscam. Zwischen oscams wird normalerweise eine erweiterte Fassung genutzt, die auch mehrere Anfragen gleichzeitig zuläßt.
Bei diesem Protokoll besteht der geringste Konfigurationsbedarf, da sich die beteiligten oscams selber darüber informieren, welche Karten auf welcher Distanz verfügbar sind. Auch Karten, die auf zwei oder mehr Wegen erreichbar sind, werden so erkannt (Tauschpartner X und Tauschpartner Y tauschen auch beide untereinander und haben beide auch noch einen Tauschpartner Z, den man selber aber nicht hat ...).
Eigentlich ist damit alles gesagt und cccam[-ext] ist das Protokoll der Wahl für oscam.

cs378x und cs357x:
Diese Protokolle werden für CacheEx empfohlen oder sind dabei sogar Pflicht, da bin ich mir jetzt nicht mehr sicher. cs357x hat dabei den Vor- und Nachteil zugleich, daß es verbindungslos (= UDP) ist. Verbindungslos bedeutet, daß der Overhead einer TCP/IP-Verbindung entfällt, man kriegt also etwas mehr Cache mit derselben Menge an Traffic rein bzw. raus.
Bedeutsam ist das aber nur, wenn der Upstream oder noch seltener der Downstream auch wirklich ein Nadelöhr darstellen. Wer also z.B. noch mit DSL16000 oder niedriger und dem damit verbundenen geringen Upstream von max. 2,5 MBit/s große Mengen Cache rausschaufeln will und mit cs378x Probleme kriegt sobald er auch seinen Downstream ausreizt, kann mal cs357x ausprobieren.
Ansonsten ist cs357x so ziemlich das schlechteste Protokoll, das man nutzen kann, denn "Verbindungslosigkeit" führt auch zu dem Nachteil, daß der Client nicht erkennt, wenn nichts mehr vom Server kommt.
Verbindungsbehaftete Protokolle stellen nämlich fest, wenn die Kommunikation zum Server gestört ist und stellen daraufhin die Verbindung erneut her, verbindungslose Protokolle gucken dann einfach nur wie ein Fisch.

Alle anderen Protokolle sind eigentlich nur zur Kompatibilität mit entsprechenden alten binary-only-CAMs drin und ich würde sie auch immer nur dann einsetzen, wenn ich sie zur Kommunikation meiner einer solchen bräuchte.

@Schimmelreiter Vielen Dank für die Mühe und ausführliche Antwort! Ich werde dann alles auf cccam umstellen.

cccam habe ich erst noch mal zurückgestellt, da es nicht auf Anhieb geklappt hat Versuche ich demnächst noch mal.

Für cs357x gilt aber: es pixelt weiterhin - auch bei der 920 dort aber nicht bei allen Kanälen.

Das wird auch an so ungefähr allem liegen, außer dem verwendeten Protokoll.

Du schreibst oben zwar "LAN", aber meinst Du auch ein LAN, also verkabelt?
Oder befinden sich die "gestörten" DM520 vielleicht doch hinter WLAN oder gar dLAN[-Brücken]?

Der einzige brauchbare Ersatz für eine Cat.6e/Cat.7-Verkabelung ist .... Glasfaser.
Und nichts löst WLAN/dLAN-Probleme so einfach und nachhaltig wie Hilti-/Duss-/Makita-/Bosch-Bohrhämmer!

Wenn ich LAN schreibe meine ich LAN Genauer: CAT7, Gigabit, Ubiquity Edge Switche im Access mit Portchannels zum Core, einen Cisco Stack ... also kein Spielzeug. Glasfaser habe ich nur zwischen dem Core und dem Access. Ein einfaches Heim-Setup halt

Ja.
Das hat wohl fast jeder so oder so ähnlich.
Bei mir ist es auch Cat.7 durch's ganze Haus; ein OpenWrt-Router mit je einem DOCSIS- und einem VDSL-Modem davor, für die redundante Internet-Anbindung;, ein 48-Port-Cisco-Switch mit PoE; das Übliche halt.

Ja schon. 48 Posts reichen mir halt nicht. PoE haben bei mir alle Switche ausser dem Cisco-Stack, wie soll man sonst ordentlich WLAN (bei mir durchgängig Ubiquity Unify) und VOIP machen ... Ich nutze aber einen OpnSens Firewall Cluster zum einen um die drei VDSL100 zu betreiben und zum anderen um intern die VLANs zu trennen. Alles natürlich im IPv4/v6 Dualstack. Die Dreamboxen laufen im Moment noch immer im VLAN 1 sollen aber demnächst mit dem OSccam Raspi in das IOT VLAN wandern.

Bleibt die Frage, warum die Dinger jetzt pixeln. Mit "der alten Verschlüsselung" war das nicht so. Das kam erst mit der Umstellung.

Ich erlaube mir das nochmal nach vorne zu holen. Was kann ich noch versuchen um die Pixelei in den Griff zu bekommen? Ich bin ratlos ...

lan nutzen

Ich könnte noch auf 10 oder 40 GE umstellen aber die Boxen können das ja nicht. Im Moment ist alles nur 1 GE und die Boxen sind am LAN.

Letzter Versuch Die Boxen hängen alle am LAN und es pixelt trotzdem ...