Langzeitbeobachtung ECM Zeit bzw. max Anzahl an Klienten

[czutok]

AW: Langzeitbeobachtung ECM Zeit bzw. max Anzahl an Klienten

die cccam macht sogar 1000 oder 5000 leuten das ist nicht das problem

das schwechste mitglid in der ganze geschihte ist immer die karte

 

[carhatt]

AW: Langzeitbeobachtung ECM Zeit bzw. max Anzahl an Klienten

auf wieviel mhz lauft die karte, 15 clienten auf 2 karten sollte eigentlich keine probleme sein

 

[doc.error]

AW: Langzeitbeobachtung ECM Zeit bzw. max Anzahl an Klienten

beide mit 9mhz , aber die Clienten werden vom Server angenommen und in der nachste Sekunde vom Server " kik" oder bad response und bad command . Und das ohne Ecms zu wollen!!

 

[Underdog81]

AW: Langzeitbeobachtung ECM Zeit bzw. max Anzahl an Klienten

jo das is ne alte geschichte, entweder hilft da den server neu aufsetzen oder andere Version. Neue Dyndns und andern Port nehmen bei CCcam.
Wir haben nie wirklich herausbekommen was da los is.

 

[spider6367]

AW: Langzeitbeobachtung ECM Zeit bzw. max Anzahl an Klienten

Wir haben nie wirklich herausbekommen was da los is.

In einem anderen Board hat es jemand sehr gut erläutert:

das kann an folgenden liegen:
1. Schlechte verbindungen der peers ( hoher ping oder langsame leitung )
Begründung: die peers können die karten infos nicht so schnell verarbeiten und senden dann nen bad command durch nen bug in cccam löst das dann ne ketten reaktion aus.

Lösungen:
1. Weniger hops nehmen an karten ( ich kann hier nur lokale nehmen da ich sonst das prob bekomme )
2. Peers sotieren nach ping niedrigen zuerst in der cccam.cfg
3. hilft das nicht kannst du nur peers entfernen ( vorrübergehend ) mit diesen rücksprache halten über deren verbindung und diesen eventuell nur noch deine lokale karte zur verfügung stellen dann bekommen diese nicht soviele karten daten.

In den meisten fällen hilft es schon einfach die karten daten zu reduzieren.

Dieses problem tritt bei allen cccam versionen auf bei der einen häufiger als bei der anderen.

Ich kann aus diesem grund nur peers nehmen bis max 100ms und share nur lokal gegen lokal und nehme seit langem schon keine neuen peers mehr auf.
Bei mir liegt es aber da drann das ich selber nur nen langsamen upload habe.

Bei gbox/mbox hatte ich da nie probleme aber bei dem gbox protokol werden die karten daten auch nicht alle paar sekunden aktualisiert und auch alles über udp da interessiert es den server nicht ob das paket genommen wird oder nicht es wird nur verschickt ohne warten auf antwort...

z.b hohe pings weil noch filesharing oder sowas läuft, wenn solche clients dann nicht schnell genug die daten von cccam verarbeiten komt ein bad command, wenn das mal passiert ist es nicht schlimm aber wenn mehrere hintereinander kommen wird oft ne ketten reaktion ausgelöst was zu den disconnects aller clients führt.

Ich fahre damit recht gut nur lines mit niedrigen pings zu haben, bei vielen reicht schon ein hop weniger an karten zu sharen.

Es kann auch sein das, das problem mal auftritt und dann garnicht mehr, könnte ja sein das gerade zufällig ein paar peers ihre leitung zu 100% benutzt haben und dadurch fehler verursacht haben.

Das problem ist ja nicht das bad command.
Das problem ist das cccam da schon ewig nen bug hat und ne ketten reaktion ausgelöst wird... wenn nur der client der das bad command verursacht disconnected würde wäre es nicht schlimm...

Ich hatte auch mal nen peer der alle paar min disconnected wurde bei dem lag es am router der hatte aber auch bad commands bei mir ausgelöst, router getauscht und jetzt hat und verursacht der peer keine probleme mehr...

Es kann auch einfach sein das man zuviele peers hat, sollte aber auf nem root server + schneller verbindung nicht zutreffen denke ich mal...

Loggen, gucken ob immer die selben user es auslösen wenn ja mit denen sprechen was da schief läuft, bei mir waren es meist unterschiedliche peers in willkürlicher reihenfolge...

Zusätzlich habe ich die Erfahrung machen können, dass zB User mit "Fremdboxen" (Edision, Opticum, andere Gurken) diese Kettenreaktionen auslösen. Am besten aussperren, indem man "MINIMUM CLIENT VERSION : 2.1.3" setzt. Dann rennen sie von alleine zu Dream Multimedia.....

 

[doc.error]

AW: Langzeitbeobachtung ECM Zeit bzw. max Anzahl an Klienten

Hallo Spider , ich danke Dir für die schnelle Hilfe. jetzt wird mir einiges klar. Ich berichte über Erfolge.... danke

 

[doc.error]

AW: Langzeitbeobachtung ECM Zeit bzw. max Anzahl an Klienten

Super danke . Nun lüpt es wieder ......!!!!! hops verkürzt und alles ist wieder ok

 

[MOSCH69]

AW: Langzeitbeobachtung ECM Zeit bzw. max Anzahl an Klienten

Zitat:
Zusätzlich habe ich die Erfahrung machen können, dass zB User mit "Fremdboxen" (Edision, Opticum, andere Gurken) diese Kettenreaktionen auslösen. Am besten aussperren, indem man "MINIMUM CLIENT VERSION : 2.1.3" setzt. Dann rennen sie von alleine zu Dream Multimedia....


Also ich habe auch ein paar Optis im Netzwerk. Keine Probleme damit. Ausserdem versteh ich nicht ganz, warum sie bei Minimum .....2.1.3 zu Dreams wechseln sollen. Die meisten Optis haben mitlerweile die 2.1.3 implementiert, zumindest bei den 9600 Modellen. Wie ich schon sagte, keine Probleme damit und sie rennen genau so gut, wie eine 800 von Dream

 

[heavenware]

AW: Langzeitbeobachtung ECM Zeit bzw. max Anzahl an Klienten

bei mir sind einige Edidion Minis VIPs im NEtzwerk und auch die laufen megastabil (sieht man mal von NDS Programmen ab)...
denke daß die Ursache für die reconnects eine andere ist..
bei mir kommt es mal vor mal kommt es dann mehrere Tage dann nicht vor....

 

[lullu08]

AW: Langzeitbeobachtung ECM Zeit bzw. max Anzahl an Klienten

Wie gesagt, ich habe schon länger CS und wenn du 15 Leute hättest, dann sind eh nie alle gleichzeitig Online, das gibs fast gar nicht.

das ist einerseits richtig,
leider schalten die dbox, dream im Standby nicht ab, sondern saugen weiter von der Karte, sodass praktisch alle online bleiben auf dem letzten eingeschalteten Kanal.

 

[rolu2]

AW: Langzeitbeobachtung ECM Zeit bzw. max Anzahl an Klienten

Dir DM800 schaltet ab und bei der Dbox kann man das anpassen in der Standby on und Standby off

 

[lullu08]

AW: Langzeitbeobachtung ECM Zeit bzw. max Anzahl an Klienten

kennst ein image bei dem das auch funzt für die dbox2 ?

Bei keywelt startet das cam nicht von selbst
und bei GLj gibts keine Lösung die auch funktioniert so weit ich gelesen haben..sei denn mann schaltet ganz ab mit 3 sekunden auf rot zB.

 

[rolu2]

AW: Langzeitbeobachtung ECM Zeit bzw. max Anzahl an Klienten

Das brauch auch niht von selbst starten.
Man kann der Box sagen, das sie wenn sie in den Standby geht auf einen FTA-Kanal schalten soll

das in die standby on

wget -q -Y off -O /tmp/aktueller_kanal

Sie müssen registriert sein, um Links zu sehen.

pzapit 2 2

die erste 2 ist das 2 Bouquets, die zweite 2 der 2 Kanal darin.Muss angepasst werden

das in die standby off

wget -q -Y off -O /dev/null

Sie müssen registriert sein, um Links zu sehen.

/tmp/aktueller_kanal`
rm /tmp/aktueller_kanal

beides unter dem letzten fi anhängen

 

[sky pirate]

AW: Langzeitbeobachtung ECM Zeit bzw. max Anzahl an Klienten

hoer mal rolu, wie geht das bei dreamboxen 500, dein link klappt nicht, aber die sache interrressiert mich.
kannst du mal genauer werden

wie macht man dass die box im standby auf fta schaltet.
danke
el pirate:smoke:

 

[rolu2]

AW: Langzeitbeobachtung ECM Zeit bzw. max Anzahl an Klienten

Hi @ sky pirate

Das oben ist kein Link. Das muss jeweils in die Standy.on und Standby.off rein. Klppt 100 % bei einr dbox2, ob das bei der DM500 geht weiß ich nicht. Habe keine und kenne auch nicht den Aufbau. Hier nochmal die komplette Standby on und off

Standby.on

Spoiler

#!/bin/sh
# Version 0.4
aviaext --iec-off
if [ -e /var/etc/.stb_off_camd ]; then
/var/plugins/operations camd_stop &
fi
if [ -e /var/etc/.lcdwetter ] ; then
touch /tmp/.lcdwetter
/var/plugins/tuxwet/lcdwetter &
elif [ -e /var/etc/.lcd_stbclock_analog ]; then
touch /tmp/lcd.locked
analclock &
elif [ -e /var/etc/.lcd_stbclock_bcd ]; then
touch /tmp/lcd.locked
bcdclock &
elif [ -e /var/etc/.lcd_stbclock_animation ]; then
touch /tmp/lcd.locked
aniplay /var/tuxbox/config/neutrino/icons/lcd.ani &
fi
if [ -e /var/etc/.stb_off_sectionsd ]; then
touch /tmp/.daemon_h &
if pidof daemon_h > /dev/null; then killall daemon_h; fi &
touch /tmp/.daemon_h &
sleep 10 && killall -9 sectionsd &
fi
if [ -e /var/etc/.stb_off_tuxmaild ]; then
kill -12 `pidof tuxmaild` &
if [ -e /tmp/tuxcald.pid ]; then kill -usr2 $(cat /tmp/tuxcald.pid); fi
fi
if [ -e /dev/ide/host0/bus0/target0/lun0/disc ]; then
hdparm -y /dev/ide/host0/bus0/target0/lun0/disc
fi
wget -q -Y off -O /tmp/aktueller_kanal

Sie müssen registriert sein, um Links zu sehen.

pzapit 2 2

Standby.off

Spoiler

#!/bin/sh
# Version 0.4
aviaext --iec-on
if [ -e /proc/clock ] || pidof ntpd > /dev/null; then
START="sectionsd -tc"
else
START=sectionsd
fi
if [ -e /var/etc/.stb_off_camd ]; then
/var/plugins/operations camd_start
/var/plugins/operations rezap &
fi
if [ -e /var/etc/.stb_off_sectionsd ]; then
if ! pidof sectionsd > /dev/null; then $START; fi &
[ -e /tmp/.daemon_h ] && rm /tmp/.daemon_h
fi
if [ -e /var/etc/.stb_off_tuxmaild ]; then
kill -10 `pidof tuxmaild` &
if [ -e /tmp/tuxcald.pid ]; then kill -usr1 $(cat /tmp/tuxcald.pid); fi
if [ -e /tmp/tuxcald.pid ]; then kill -hup $(cat /tmp/tuxcald.pid); fi
fi
if [ -e /tmp/.lcdwetter ] ; then
rm -f /tmp/.lcdwetter
elif pidof analclock > /dev/null ; then
killall analclock
rm -f /tmp/lcd.locked
elif pidof bcdclock > /dev/null ; then
killall bcdclock
rm -f /tmp/lcd.locked
elif pidof aniplay > /dev/null ; then
killall aniplay
rm -f /tmp/lcd.locked
fi
wget -q -Y off -O /dev/null

Sie müssen registriert sein, um Links zu sehen.

/tmp/aktueller_kanal`
rm /tmp/aktueller_kanal