Immer wieder Freezer bei Clients trotz "normaler" ECM Zeiten beim Raspberry Pi

[kalamari]

Hallo,

ich habe seit einigen Tagen im Homesharingbetrieb (2 Client-Boxen: VU+Solo2 und Xtrenbd ET5000) einen Raspberry Pi (Modell B, REV 2.0, 512MB mit akt. Debian Wheezy, Kernel 3.6.11) mit einer V13 inkl. HD+ als Oscam Server laufen. Die eingesetzte Oscam ist die 8452.

Nun habe ich folgendes Problem:

Es kommt bei den Clientboxen - diese sind über CCcam 2.3.0 angebunden - immer wieder in regelmäßigen Abständen (alle 2-3- Minuten) zu Freezern aufgrund erhöhter ECM-Zeiten. Komisch dabei ist, dass im OscamWebIF des Raspberry Pi die ECM-Zeiten für die Clients dabei aber immer völlig gleichmäßig (zwischen 124ms und 130 ms) weiterlaufen, während zur selben Zeit die bei den Clients angezeigten ECM-Zeiten in regelmäßigen Abständen dann deutlich/sprunghaft ansteigen.


Hier meine Config Dateien auf dem Raspberry Pi:


oscam.conf:

Spoiler

[global]
logfile = /var/cache/oscam.log
disableuserfile = 1
clienttimeout = 15000
fallbacktimeout = 4900
clientmaxidle = 60
cachedelay = 120
nice = -10
maxlogsize = 100
preferlocalcards = 1
saveinithistory = 1
[dvbapi]
enabled = 1
au = 1
boxtype = dreambox
user = local
pmt_mode = 0
[webif]
httpport = XX
httphelplang = de
httpuser = XXX
httppwd = XXX
httprefresh = 10
httpallowed = 127.0.0.1,10.0.0.1-192.168.255.255
#[camd35]
#port = XXXXX
[cccam]
port = XXXXX
reshare = 1
version = 2.3.0
stealth = 1

oscam.server:

Spoiler

[reader]
label = skyde_V13_inkl_HD+
protocol = mouse
device = /dev/ttyUSB0
caid = 09C4
boxid = 12345678
detect = cd
mhz = 358
cardmhz = 357
ins7e11 = 15
ndsversion = 2
group = 1
emmcache = 1,1,2
blockemm-unknown = 1
blockemm-g = 1

oscam.user:

Spoiler

[account]
user = Wohnzimmer
pwd = XXX
group = 1
caid = 09C4
au = 1
[account]
user = Schlafzimmer
pwd = XXX
group = 1
caid = 09C4

Wie gesagt sieht der Log im Oscam WebIF komischer Weise ganz unauffällig auf, immer und völlig gleichmäßig ECM Zeiten zwischen 124ms und 130ms. Dies auch zu den Zeitpunkten, wo bei den Clientboxen plötzlich sprunghaft erhöhte ECM-Zeiten auftreten!

Auf den Clientboxen befindet sich zur Zeit nur die Standard CCcam.cfg (also keine CCcam.prio oder dergleichen) mit C-Linie auf den Raspberry Pi.

Hat jemand eine Idee, was die Ursache für die erhöhten ECM-Zeiten bei den Clientboxen bei gleichzeitig niedrigen ECM-Zeiten beim Osacm-Server (=Raspberry Pi) sein könnte?

Grüße

Edit -ergänzende Info:
Cardreader ist eine Easymouse 2 premium

 

[stecoq_]

AW: Immer wieder Freezer bei Clients trotz "normaler" ECM Zeiten beim Raspberry Pi

Wie sind die Clienten angebunden? WLAN, LAN oder Powerlan?

Gesendet von meinem GT-I9300 mit Tapatalk 2

 

[Painbastard]

AW: Immer wieder Freezer bei Clients trotz "normaler" ECM Zeiten beim Raspberry Pi

Das würde ich auct tippen
Wlan Probleme????

 

[kalamari]

AW: Immer wieder Freezer bei Clients trotz "normaler" ECM Zeiten beim Raspberry Pi

Anbindung erfolgt über Powerlan.

Am Powerlan kann es m.E. nicht liegen, da wenn ich die V13 z.B. intern in der VU+Solo2 betreibe, die Probleme bei der Clientbox nicht auftreten. Möchte aber halt trotzdem gerne die V13 über den Raspi verteilen, damit nicht immer die Serverbox im Betrieb sein muss ...

 

[stecoq_]

AW: Immer wieder Freezer bei Clients trotz "normaler" ECM Zeiten beim Raspberry Pi

Also wenn du die VU+ über Powerlan als Server laufen lässt hast du keine Probleme? Die Configs sind die selben?

Tausch doch mal den Powerlan Adapter der VU+ mit dem des Raspberry. Vielleicht hat der Adapter am Server eine Macke.

Gesendet von meinem GT-I9300 mit Tapatalk 2

 

[kalamari]

AW: Immer wieder Freezer bei Clients trotz "normaler" ECM Zeiten beim Raspberry Pi

Der Raspberry hängt nicht an einem Adapter, sondern ist direkt am Router angeschlossen. Configs sind die selben.

Was sagen denn eigentlich überhaupt die ECM Zeiten im Oscam WebIF beim Raspberry (die ja gleichmäßig niedrig sind) im Unterschied zu den zur selben Zeit teilweise (zu) hohen ECM-Zeiten bei den Clients aus bzw. wie und warum können denn diese Werte eigentlich zur selben Zeit unterschiedlich hoch sein?

Sorry, vielleicht blöde Frage, aber ich habe immer gedacht, dass diese Werte auf Server und Clientseite zur selben Zeit dann grundsätzlich immer gleich sind ...

 

[lullu08]

AW: Immer wieder Freezer bei Clients trotz "normaler" ECM Zeiten beim Raspberry Pi

ZB bei Lines mit Rechare,
der Server logt die Zeiten die er benötigt,
der Client loggt die Zeiten, arbeitet alles nach-ein-ander ab.

Bei Lines mit Rechare, müsste man dann für NDS Karte eine Extra Zugang schalten, damit die Anfragen Paralel laufen können.

 

[kalamari]

AW: Immer wieder Freezer bei Clients trotz "normaler" ECM Zeiten beim Raspberry Pi

Bei mir ist aber ja nur "reines" und "kleines" Homesharing ohne irgend was anderes ... Müssten da nicht die ECM Zeiten dann beim Server und beim Client immer nahezu gleich sein bzw. was könnte da dann zu einer so hohen Differenz führen, noch dazu in praktisch regelmäßigen Abständen?

 

[lullu08]

AW: Immer wieder Freezer bei Clients trotz "normaler" ECM Zeiten beim Raspberry Pi

Hinzu kommt nur der Ping mal 2.
Einige Geräte haben auch noch etwas Verzögerung. Sollte aber recht gleichbleibend laufen.

Was sich auf den Ping noch auswirkt, sind wenn jemand gleichzeitig surft, verschlechtert der sich schon deutlich.
In einigen Routern kann man Netzwerkprioritäten vergeben (Fritzbox)

Die Powerline, da kannst mal schauen, ob die Verbindung möglichst kurz gesteckt ist.
3er-Stecker oder alles mit weichem Kabel dämpfen sehr stark das Signal.

 

[4gx35]

AW: Immer wieder Freezer bei Clients trotz "normaler" ECM Zeiten beim Raspberry Pi

wenn es mit Powerline und VU als server geht,
ist evtl. die Rasp Verbindung zum Router schlecht, mal anderes kabel testen,
oder rasp statt einer box an powerline testen

 

[lullu08]

AW: Immer wieder Freezer bei Clients trotz "normaler" ECM Zeiten beim Raspberry Pi

@Powerline
Mal zur Info, was den Zählerkasten angeht,
jede dritte Sicherung, ist die gleiche Phase!

 

[h00re]

AW: Immer wieder Freezer bei Clients trotz "normaler" ECM Zeiten beim Raspberry Pi

Schon eine Lösung gefunden?

 

[kalamari]

Bisher leider noch nicht. Hatte aber leider am letzten Wochenende auch keine Zeit für längere Tests. Werde jetzt in den nächsten Tagen einmal verschiedene Steckdosen und dann noch einmal mit meinen "alten" (zwar langsameren aber stets uzuverlässigen) dlan Adaptern testen. Hoffentlich finde ich noch eine Lösung, da es an sich ja prima mit dem Raspberry klappt und nur eben sporadisch die ECM Zeiten (nur!) beim Client hochgehen.


Melde mich dann wieder ...

Habe am letzten Wochenende jetzt noch einmal die dlan Adapter durchgetauscht und dann auch noch meine Oscam etwas "nachkonfiguriert". Die Clientboxen habe ich jetzt über Oscam (bzw. doscam) mittels camd35 Protokoll an den Raspi angebunden. Zumindest momentan läuft jetzt alles mal im Prinzip so, wie es sein soll. Lediglich ganz vereinzelt gibt es in unregelmäßigen, größeren Abständen (so alle 1-2 Stunden) hin und wieder immer noch einmal auf der Clientbox ein "Timeout" ... Im Log der Clientbox sehe ich dann, dass in diesen Fällen immer genau ein einziges CW fehlt, obwohl von Serverseite keinerlei Auffälligkeiten im Log zu sehen sind.

 

[bombadil]

AW: Immer wieder Freezer bei Clients trotz "normaler" ECM Zeiten beim Raspberry Pi

Hi,

mit welchem camd Protokoll verbindest du? Es gibt einmal das

[cs357x] UDP oder das
[cs378x] TCP.

Der Unterschied ist in den verschiedenen Verbindungsprotokollen. UDP ist ein unzuverlässiges, verbindungsloses Verbindungsprotokoll, weil der Empfänger keine Bestätiging der Verbindung übermittelt. Das kann dazu führen, dass dein Server einfach nicht weiß, dass das CW nicht angekommen ist und daher dieses nicht sofort noch einmal sendet.

TCP arbeitet hingegen verbindungsorientiert und der Sender wird vom Empfännger über den Erhalt des Datenpakets informiert.

Da könnte bei dir noch eine Fehlerquelle liegen.

Gruß
Bombadil

 

[kalamari]

AW: Immer wieder Freezer bei Clients trotz "normaler" ECM Zeiten beim Raspberry Pi

Hallo,

vielen Dank für die Info und den Tip!

Ich hatte tatsächlich einfach das erste camd Protokoll in der Reihe des WebIf angeklickt, dies war [cs357x] - habe das gestern Abend dann gleich auf [cs378x] abgeändert und werde jetzt beobachten, ob damit die gelegentlichen "Timeouts" immer noch auftreten.

Grüße