Oscam/CCcam plötzlich Probleme im UM/FV-Netz & wechsel auf cs378x

[H5400]

Abend zusammen! Ich würde gerne das Thema wieder aufgreifen. Weil mich das Thema heute etwas gepackt hat...

Ich habe seit Jahren eine Oscam Testumgebung mit CCcam als Protokoll. Seit Jahren läuft es wie ein Uhrwerk. Aber seit einer unbestimmten Zeit, muss ich feststellen, dass auf dem einen oder anderen Gerät vereinzelte Kanäle nicht immer auf den Server Anfragen. Wenn ich auf dem Client von native cccam auf oscam switche geht es dann. Manchmal auch nicht.
Also habe ich Testweise auf cs375x gewechselt, bzw. einen Port eingerichtet und Zack alles läuft wunderbar. Jeder "zickige" Kanal springt an.

Kurzum - habe ich mit dem cs Protokoll irgendwelche Nachteile? Reshare Regeln werden nicht benötigt.
Oder habe ich wegen UDP Protokoll einen Geschwindigkeit "zuwachs"

Ich habe mich etwas reingelesen, jedoch sind die Beiträge in den Boards alle über 6/7Jahre alt. Eventuell ist das cs Protokoll überholt.

Ich würde mich sehr über eins, zwei Meinungen freuen. Vielen Dank vorab....

 

[Alex]

Ich hatte zumindest früher das Problem, das über cccam keine Unique EMMs an die V13 kamen. Hab für AU deshalb schin lange camd UDP und da funzt das alles

 

[H5400]

Also wenn keine Nachteile bekannt sind, dann kann ich doch mit gutem Gewissen umstellen oder?

 

[dewildschwein500]

Hi @H5400,
ich nutze cs378x und cs357x, wobei cs357x nur als Fallback dient (Infos zum Fallback: Antifreeze OScam Tweaking für fehleranfällige Anbindungen im HS (WLAN/dLAN))
Im lokalen Netzwerk sollte cs357x (UDP) ausreichend zuverlässig sein ... Beim CS übers Internet ist cs357x (UDP) nicht zu empfehlen.

 

[H5400]

Danke für den link. kurze Frage - siehst du UDP kritisch wegen der Gefahr Pakete zu verlieren?
Falls das der Grund ist, wie steht es um cs378x?
Falls das Protokoll die zickigen Kanäle erfolgreich verarbeiten kann, dann wäre es auch eine Option.

 

[dewildschwein500]

Hi @H5400,
ja, bei UDP gehen Pakete unbemerkt verloren und führt denn oft zu Freezern. cs378x nutzt TCP und da fallen Verluste direkt auf und es wird versucht das Paket erneut zuzustellen.

 

[el_malto]

Aber seit einer unbestimmten Zeit, muss ich feststellen, dass auf dem einen oder anderen Gerät vereinzelte Kanäle nicht immer auf den Server Anfragen. Wenn ich auf dem Client von native cccam auf oscam switche geht es dann. Manchmal auch nicht.
Also habe ich Testweise auf cs375x gewechselt, bzw. einen Port eingerichtet und Zack alles läuft wunderbar. Jeder "zickige" Kanal springt an.

Kurzum - habe ich mit dem cs Protokoll irgendwelche Nachteile? Reshare Regeln werden nicht benötigt.

Logs und Configs wären da mal interessant. Sonst kann man da nichts zu sagen.

cs375x

cs375x gibt es nicht, meinst du nun cs378x oder cs357x. Weil cccam benutzt auch TCP wie cs378x. Wenn es also mit cs378x auf einmal läuft, würde ich eher auf ein reshare oder wie beim TE anticascading Problem tippen.

Hier was zu TCP und UDP.
cs378x = TCP
cs357x = UDP

Spoiler: TCP vs. UDP

Sowohl TCP als auch UDP sind Protokolle, die verwendet werden, um Datenbits, auch Pakete genannt, zu senden. Beide bauen auf dem Internetprotokoll auf. Man kann es auch so ausdrücken: Wenn man ein Paket per TCP oder UDP verschickt, wird es an eine IP-Adresse gesendet. Beide Pakete werden ähnlich behandelt und von Ihrem Computer zum zwischengeschalteten Router bis zum Ziel geleitet.


TCP steht für "Transmission Control Protocol" und ist das am häufigsten genutzte Protokoll im Internet.


TCP garantiert, dass der Empfänger die Daten korrekt empfängt, indem sie durchnummeriert werden. Der Empfänger quittiert den korrekten Empfang der Daten and den Sender zurück. Falls keine Bestätigung kommt, werden die Daten erneut gesendet, außerdem werden sie auf Richtigkeit überprüft. TCP ist also extrem zuverlässig und setzt sein Augenmerk auf das unbedingt korrekte Senden und Empfangen von Daten und stellt sicher, dass keine Daten verloren gehen oder während des Sendevorgangs korrumpiert werden. Aus diesem Grund gehen bei einem Download auch keine Daten verloren, wenn die Verbindungsstrecke unstabil ist oder temporär unterbrochen wird. Das geht natürlich nur zu einem gewissen Punkt. Wenn die Verbindung ganz abbricht, wird Ihr Computer 'aufgeben' und eine Fehlermeldung herausgeben, dass er nicht mehr mit dem Host kommunizieren kann.


UDP steht für User Datagram Protocol. Ein Datagram ist das gleiche wie ein Paket von Informationen. Das Protokoll arbeitet ganz ähnlich wie TCP, verzichtet aber auf die permanenten Fehleruntersuchungen. Das ganze Hin- und Her-Senden und Überprüfen geht spürbar auf die Bandbreite und kann die Geschwindigkeit stark dezimieren.


Wenn UDP eingesetzt wird, werden die Daten versendet - das war's. Es findet keine Überprüfung statt, ob das Paket korrekt empfangen wurde. UDP macht nach dem Versenden des ersten Pakets sofort weiter und verschickt umgehend das nächste. Sollte der Empfänger einige UDP-Pakete nicht bekommen - Pech gehabt. Er kann die Daten nicht erneut anfordern. UDP garantiert nicht für den Versand und auch nicht für die Vollständigkeit der Daten. Aber durch den Verzicht auf das prüf-Prozedere wird schnellstmögliche Kommunikation sichergestellt.

Quelle: Google

Damit sollte der Unterschied klar sein. TCP ist zuverlässiger. Ich benutze aber ebenfalls wie @dewildschwein500 schon verlinkt hat eine Fallback Line mit UDP. Da das ganze hin und her senden und bestätigen bei TCP unter Umständen auch mal länger dauern kann wenn Pakete verloren gehen oder ein "Stau" auftritt, kann es bei einer anfälligen Karte wie z.b. der V13 ab ca. 550-600 ms zu Freezern kommen. Daher schicken wir wie im verlinkten Thread schon beschrieben eine UDP Anfrage hinterher in der Hoffnung, dass diese direkt durch geht und die Antwort schneller kommt. Man könnte die Fallback Line auch über TCP machen, aber das würde bei einem "Stau" ja wenig Sinn machen. Bei HD+ Karten ist das "fast" nicht nötig, da diese ja sehr "größzügig" sind und erst ab 1500-2000 (oder noch höher?) freezen.

 

[master-x]

Dann versuch ich mal.
Cs 357 /378 das sind Protokolle noch aus D Box zeiten, damals liefen die Spitze , zu der zeit war auch die Datenmenge geringer als heute , wenn man sich HD Sender ansieht . Im Home Cs mit Lan zu Lan kein Problem das sollte ohne weiteres gehen, mit den alten Protokollen cs 357.Zum heutigen sharen im Home cs.Der Server sollte zumindest am Lan Router verbunden sein wenn möglich,die clienten können via Wlan sich conecten.
Ich benutze nur noch die ', gbox oder cccam protokolle und habe nie irgendwelche freezer hänger oder dauerpings weder auf Server oder clienten.

nimm nur cccam als protokoll.

Und pass die group an .

 

[H5400]

Das Thema ist das cccam mit einigen Programmen Probleme hat. Ich würde auch gerne alles so lassen. Woran könnte es dann liegen? Ich möchte die perfomanteste Lösung haben....

Gibt es bekannte Probleme mit dvb-api?

 

[master-x]

wie meinst du das ? cccam mit einigen Programmen Probleme hat.

Nutze die selbe Oscam auf allen deinen Geräten Server sowie Clienten,und nutz reines cccam protokoll,ne bessere performance ,wüsste ich nicht zurzeit.

Schaut dir mal configs an,configs sollten so minimal wie möglich gehalten werden,weniger ist mehr.

Wo ist dein abschnitt DVBapi ?.

Spoiler: config

[global]
logfile = /var/log/oscam.log
maxlogsize = 100

[dvbapi]
enabled = 1
user = ich
boxtype = dreambox
au = 1

[cccam]
port = 12345
version = 2.3.2

[webif]
httpport = 1234
httpuser = ich
httppwd = 123456
httphelplang = de
httpallowed = 192.XXX.XXX.XXX-192.XXX.XXX.XXX

sorry doppelpost

 

[H5400]

Ich verfolge das Hobby schon 10j. Und nutze bestimmt meine config (ohne cs35xx) seit bestimmt 6j oder mehr, und alles ohne Probleme.
Aber ich weiß nicht was UM/VF geändert hat, aber seit einigen Monaten werden nicht alle Kanäle auf anhieb, oder sogar gar nicht geöffnet.
Daraufhin habe ich gestern die muse gefunden, das cs zu testen und alle Kanäle die gezickt haben, sind ohne Probleme gelaufen.
Also gibt es gerade zwei Optionen
Erstens an meiner config ist was faul oder oscam/ccc werden nicht getriggert auf dem server anzufragen.

Alle Geräte sind ältere gigablue's quad+ und alte se.
Aber die quad's haben aktuell hdfreaks images drauf.
Die alte se Box hat gestern eine frische oscam bekommen.

 

[Derek Buegel]

zu der zeit war auch die Datenmenge geringer als heute

Falsch!
Beim CS sind die Datenmengen heute noch genau so gering wie damals.
cs378x läuft astrein.

MfG

 

[master-x]

wie meinst du das ? cccam mit einigen Programmen Probleme hat.

Nutze die selbe Oscam auf allen deinen Geräten Server sowie Clienten,und nutz reines cccam protokoll,ne bessere performance ,wüsste ich nicht zurzeit.

Schaut dir mal configs an,configs sollten so minimal wie möglich gehalten werden,weniger ist mehr.

Wo ist dein abschnitt DVBapi ?.

Falsch!
Beim CS sind die Datenmengen heute noch genau so gering wie damals.
cs378x läuft astrein.

MfG

ok !

 

[el_malto]

@H5400 poste deine Configs mal vollständig und in Spoilern getrennt. Und ebenso einen Log vom Server und Clienten wenn die Probleme auftreten.

 

[H5400]

Guten Morgen. Ich geh den einfachen Weg und teste es an den problem clients. Wenn es die nächsten Tage gut läuft. Wird CC an den Nagel gehängt. Falls es nicht den erhofft Erfolg bringt, werde ich nochmal mit log und co. Melden.

Bis dahin... vielen Dank für eure Unterstützung.

Eine Frage in die Runde zum Thema CS378x. Ich habe drei Karten [2xV23 (HD&SKY) und einmal UM02]
Wenn ein Client auf die UM02 zugreift, wird eine invalid Anfrage auf die V23 erzeugt und ich möchte keine invalid Anfragen von Clients in meinem Log sehen. :-D
Was kann ich dagegen tun?
Ich arbeite mit Services. Ich habe auch Server-Seitig eine Blockier-Service (alle srvid + 1838) erstellt, aber das funktioniert nicht.

Client-seitig habe ich die 098E priorisiert, damit ich wenigstens nur selten eine invalid Anfrage bekomme.

Habt ihr ein Tipp?