Sagem Zwitscher-Box

[newcode]

@bahnbooster

Die Interrupts werden in /proc/interrupts gezählt. Kann man einfach mit cat auslesen.

 

@gerry6n

Hast Du mal nachgeschaut (ps) ob das Script läuft ?

[faze]

Nur mal so zum Verständniss ihr habt jetzt also ein script geschrieben, welches genau

wie die *box das zwitschern selber erkennt und automatisch beendet??

 

 

Edit: Falls dem so sein sollte, dann verneige ich mich zuerst einmal in Ehrfurcht, und danach würde ich um eine kurze Anleitung bitten wo welche skripte hinkopiert werden müssen und was für einstellungen man noch machen muss denn irgendwie hab ich mir da bisher keinen wirklichen Überblick durch eure Postings machen können.

 

Zu meiner Box:

 

aktuelles GLJ Image

MG Camd 2.5

U_Code 0014

 

 

Grüße

 

faze

bearbeitet 2. Oktober 2007 von faze

[gerry6n]

@newcode

Wo kann ich sehen ob das Script läuft?

Mit Hyperterm habe ich das hier bekomme wen ich das Script starten will :

 

[CPlugins] executing /var/t

uxbox/plugins/avia-check.sh

/var/tuxbox/plugins/avia-check.sh: /var/tuxbox/plugin

: not foundk.sh: 1:

/var/tuxbox/plugins/avia-check.sh: /var/tuxbox/plugins/avia-check.sh:

20: Syntax error: "done" unexpected (expecting "fi")

 

 

 

Mfg Gerry

[newcode]

@gerry6n

 

Du hast zwei Fehler.

Zum ersten sollte das Script nach /var/plugins.

Außerdem scheinst Du auch noch beim eintippen des Scripts einen Fehler gemacht zu haben.

 

Sehen ob das Script läuft kanst Du mit telnet. Ist bei jedem Windows dabei.

telnet starten, IP der Box eingeben, als root einloggen, und dann der Befehl ps.

 

Der Name des Scripts muß in der Liste auftauchen, sonst läufts nicht.

 

P.S. Während ich schreibe hat meine Box 3 mal gezwitschert und wurde resetted.

[niemand0815]

@faze:

ja, schaut so aus. nur anders. es wird nur geprüft ob noch avia interrupts kommen und dann ein enxreset gemacht wenn keine kommen.

 

generell sollten das aber erst mal nur erfahrene nutzer einbauen, denke ich.

 

@newcode:

hier auch nachdem ich auf "deine" avia und ucode combi gewechselt hab. es scheint je nach avia version unterschiedliche interruptmengen zu geben (irgendwie war das ja zu erwarten) und bei manchen avias kommen trotz hängendem enx noch interrupts an. mit der von dir beschriebenen version aber nicht.

 

probleme scheint es manchmal beim umschalten zu geben, schwarzbild mit ton oder bildhänger mit normalem ton. ich gehe mal vom fehlenden "umschaltreset" aus. der ist ja glaube ich in den betas noch nicht drin, wenn ich mich nicht irre. oder?

[newcode]

@faze

 

Das funktioniert noch nicht mit Deiner camd. Ich benutze eine andere mit der Version 894beta1.

Das auf andere zu erweitern ist abhängig von der Nachfrage.

[newcode]

@niemand0815

 

Das mit dem umschalten ist richtig. Ist in den betas nicht drin. Ich denke es war früher in der zapit. Ich könnte das ins Script einbauen, das würde die Ausführung aber weiter verlangsamen. Deswegen halte ich es nicht für sinvoll.

 

Grüße

[det-box]

@newcode:

hatte eben wieder einen hänger trotz script.

was mir dabei auffiel:

es kamen pro sekunden 200-300 interrupts für den avia.

normalerweise hab ich da immer nur 100-150 gesehen.

Mal ne Frage, wo sehe ich denn diese Interrupts ???

 

EDIT: Ich krieg nichtmal das Script zum Laufen :" /var/plugins/operations: 732: /var/plugins/avia_check.sh: not found " ???

 

Die Datei ist da und heisst auch genauso und hat 755.

ist wahrscheinlich nicht im Linuxformat

 

Tuxcommander auf Datei gehen, Taste 4 , Taste blau , Home, speichern Ok, Ok

 

dann sollte es gehen

 

 

Det

[bahnbooster]

@det-box:

 

jep, das wars bisher hab ich immer alles mit dem Notepad++ gemacht und funktionierte alles. Aber scheinbar ist Linux doch sehr pingelig .

bearbeitet 9. Oktober 2007 von bahnbooster

[Fazz]

@newcode:

 

Meine Avia Firm. ist die 0028. Die 0022 und 0030 laufen schlechter. Zum Teil habe ich damit Verzerrungen im unteren Bildviertel.

 

Hoffentlich ist das keine dumme Frage:

kann es ev. was bringen das Script als Hintergrundprozess laufen zu lassen??

("&" - Zeichen ganz ans ende, also noch hinters done)

 

 

 

BTW:

die Mittelwertberechnung im DualPes hab ich verworfen, da manchmal keine Abweichung vom Mittelwert vorhanden war, bzw. erst nach etlichen sekunden gezwitscher, endlich eine Schwelle erreicht war.

 

greetz,

Fazz

bearbeitet 3. Oktober 2007 von Fazz

[cy_coe]

@newcode

@faze

Das funktioniert noch nicht mit Deiner camd.

äh, bist Du Dir da sicher? Bei mir läuft mgcamd1.25 (avia 022, ucode 0014) und ich hab das avia-check v0.201 eingebaut. Starten laß ich das durch start_neutrino ->

 

 (...)
#/var/plugins/operations sect_renice &
/var/plugins/operations epg_reinit &

if [ -e /var/plugins/woltimer/.wol_auto ]; then
touch /var/plugins/woltimer/.wol
sleep 40 && /var/plugins/woltimer/woltimerd &
fi;

/var/plugins/avia-check.sh &

KEEP_ALIVE=1
while  expr $KEEP_ALIVE != 0 > /dev/null
do
neutrino -u -f
KEEP_ALIVE=$?
done
(...)

 

...und es läuft bestens - bisher erst ein mal zwitschern, daß ich mit dem manuellen ENX-Reset beheben mußte.

 

Bin jetzt erstmal hochzufrieden mit der v0.201. Und Ehre, wem Ehre gebührt: ganz großes Respekt!

[newcode]

@cy_coe

Ich habe nur mit camd3 getestet und deshalb den Start auch mit der camd3 verknüpft.

Es kann sein, daß es auch mit anderen camd's läuft.

 

Wenn Du Version 0.2 benutzt den Movieplayer nur aus FTA Programmen starten.

[newcode]

@Fazz

Das "&" braucht man beim Aufruf des Scripts und nicht im Script.

Wenn Du nochmal liest wie das Script gestartet werden soll, wirst Du das "&" auch finden.

[gerry6n]

@niemand0815

@newcode

und alle die mit gewirkt haben

 

Vielen Dank für das Script, es läuft super. RESPEKT für und nochmal Danke für eure Mühe.

 

Mein Problem war, dass ich das Script im Proton editor geschrieben habe und der nur irgendwas mit reinpakte was linux nicht versteht.

 

EDIT: Ich verwende das KW Image Beta 10 mit avia 600 vb028 und ucode 0014.

Leider funktioniert das Script nicht mit dem ucode 001a. Mit diesem hatt ich bisher am wenigsten gezwitscher.

bearbeitet 3. Oktober 2007 von gerry6n

[schubsi]

Moins...

 

Aaaaalso: Der Betrieb des sectionsd mit niedrigerer Priorität (-15) verlängert den Zeitraum bis zum ersten Bildhänger um einiges. Gestern lief die Box von ca. 11:30 bis ca. 19:10 unauffällig, d. h. es mag zwischendurch kurze Bildhakler gegeben haben (die ich nicht bemerkt habe, die box lief unbeaufsichtigt), jedoch gings dann doch irgendwann wieder los, umzappen löste das Problem wieder, also kein tiefergreifender Freeze ("Kanal nicht verfügbar")...

 

Die Kombination mit dem µcode.001A scheint deutlich weniger anfällig für Bildhakler oder Freezes zu sein, jedoch kommen sie bei mir auch in dieser Konstellation vor.

 

Interessante Beobachtung: Habe die Einstellungen so verändert, dass sectionsd im Standby-Modus NICHT ausgeführt wird. Und siehe da: Die Box ist über nacht mit µcode.0014 durchgelaufen !!! Das hat sie eigentlich noch nie gemacht...

 

Diese Beobachtung verstärkt meine Befürchtung, dass der EPG-Kram der Verursacher der Hakler sein könnte.

 

Ich werde später (heute abend) mal ein Skript zusammenbasteln, welches mir das manuelle Beenden des sectionsd (killall -9 sectionsd) und das erneute manuelle Starten erlaubt. Wenn ich in Ruhe einen Film sehen möchte, dann brauche ich so lange kein EPG. Ob das dann der Bringer sein wird, lässt sich nur in einem längeren Testlauf feststellen.

 

Vielleicht möcht das ja jemand parallel testen?

 

Ich melde mich wieder, wenn ich was neues weiß...

 

-==[schubsi]==-

[The Invisible]

gibts ne möglichkeit den epg kram komplett abzuschalten? darauf könnt ich gut verzichten wenn dass das zwitschern entfernt. ..man kann ja net alles haben :-)

[niemand0815]

ich hab in der 10'er beta jetzt auch eine nette beobachtung gemacht:

einstellungen wie in der beta7 führten dazu das oft nach dem umschalten das bild schwarz wurde. rezap half.

aber jetzt kommts:

ich hab dann mit allen möglichen einstellungen rumprobiert, nichts half.

dann hab ich im epg-menü das dsnice (heisst der so? ich bin mir nicht mehr sicher schaut selbst nach) watchdog aktiviert.

seit dem lief die box ohne schwarzbilder beim umschalten. ok.

aber jetzt kommt es richtig dick:

danach hatte ich auch nur noch sehr selten zwitschern, selbst ohne script (ich lasse mir die resets durch das script in ein log mitschreiben, deswegen kann ich sehr genau sagen ob einer statt gefunden hat).

 

da dieser watchdog wenn ich richtig vermute(!) (ich hab nichts dazu gefunden) auch mit dem epg zu tun hat könnte das deine beobachtung nochmal stützen.

natürlich könnte das zwitschern auch mit cpu last zu tun haben und je mehr man aktiviert desto besser wird es *g*

 

was macht dieser watchdog eigentlich genau?

[bahnbooster]

Gelöscht

bearbeitet 9. Oktober 2007 von bahnbooster

[niemand0815]

@bahnbooster:

kein dank an mich, ich teste das nur!

das script haben wir newcode zu verdanken.

 

der watchdog wurde wie ich das sehe laut der statusanzeige NICHT ausgelöst.

komisch ist das schon.

[cy_coe]

@ schubsi

Deine Beobachtungen kann ich bestätigen.

Ich hatte mal zum Testen das neue beta10 installiert und dann auch wieder ein Zwitscherproblem, das ich nur mit Reboot hätte beheben können. Da ich auch den EPG als Verursacher vermute, hab ich mal killall sectionsd ausgeführt. Und siehe da, die box hat sich sofort wieder gefangen!

 

@ gerry6n

Proton hab ich unter Windows auch immer benutzt, um Dateien linux-konform bearbeiten zu können. Schau mal nach, ob Du Proton nicht explizit sagen mußt, daß die Datei im linux- (oder unix-)format abgespeichert werden soll... Proton kann das - glaubs mir.

bearbeitet 3. Oktober 2007 von cy_coe

[newcode]

Hier noch ne neue Version vom avia-check. Die beseitigt (hoffentlich :-) ) ein Problem bei der Kanalsuche.

#!/bin/sh
# avia-check.sh  v0.33

OLDCOUNT=0
SECS=1
while sleep $SECS; do
 ZAPIT=$(pidof zapit | grep -e "[0-9]\+ [0-9]\+ [0-9]\+")
 while [[ -n "$ZAPIT" ]]; do
while [[ -n "$ZAPIT" ]]; do
  sleep 10
  ZAPIT=$(pidof zapit | grep -e "[0-9]\+ [0-9]\+ [0-9]\+")
done
sleep 10
 done
 TUNER=$(pidof kdvb-fe-0:0)
 if [ -f /tmp/ecm.info ] && [ -n "$TUNER" ]; then
COUNT=$(grep avia$ /proc/interrupts)
if [ "$COUNT" = "$OLDCOUNT" ]; then
  /bin/enxreset 1>/dev/null 2>/dev/null
  AUDIO=$(/bin/pzapit --getpids | grep "*audio" | cut -b 8)
  /bin/pzapit -a $AUDIO
  OLDCOUNT=0
else
  if [ -n "$(/bin/pzapit --getpids | grep "video")" ]; then SECS=1; else SECS=3; fi
  OLDCOUNT=$COUNT
fi
 fi
done

 

Ich hoffe die nächste Version kriege ich in C hin.

bearbeitet 3. Oktober 2007 von newcode

[Gast zyklop]

Hy Freaks !!

 

Als alter "Elektroniker und Datenfreaggle" hat mich hier ein Thread auf eine geniale Idee gebracht.

 

Es wurde gemunkelt, daß die Synchronität zwischen ENx und Proz in Form der Interrupts ausblieb, daher der ENx Reset, richtig ?! (--> = Neusynchronisation)

 

Aus Erfahrung heraus weiss ich, daß Quarze in Schwingkreisen, erhebliche Abweichungen bei Alterung und/oder ungenauer Produktion aufweisen können.

Ebenso die am Schwingkreis beteiligten Bauteile (Kondensatoren etc)

 

Wenn ich mir das Layout der Sagem mal ansehe, sehe ich einen minderwertigen 27 MHZ Quartz für den ENx und einen 8,388 MHz für den Cardreader.

(Der Proz hat einen hochwertigen gekapselten, der bei mir allerdings rein optisch nach nachlöten schreit....)

 

Was jetzt, wenn der 27 MHz nicht richtig tickt ??!! Mit Karte läuft es ja anscheinend.....kann die Box das ausreichend lange puffern ??

(Da wäre auch noch ein LV125 Chip "Quadruple BUS BUFFER GATES" der auch die Ursache sein könnte) der besagte Puffer halt.....

 

Bei unterschiedlicher Temperatur dauert es unterschiedlich lange bis zum Zwitschern ?!! (Anderes Schwingverhalten ?!)

 

Bei unterschiedlichen Images kommt es zu mehr oder weniger Interrupts als Ursache für den Synchronverlust ??!!!!

 

Nur so als Anregung, leider habe ich nur eine von SAT auf KABEL umgebaute "Zwitscher - Sagem"....... und es mangelt am Kabelanschluss.............

 

Im Übrigen hat der Tunerumbau NICHTS am Zwitschern verbessert...habe nur leider den Sattuner gehimmelt......... (Zuviel Kältespray zum testen und pffftt.......)

 

Würde mich bereit erklären, weiter an der ELEKTRONIK rumzulöten, wenn jemand einen heilen SAT Tuner oder defekte SATBOX für mich hätte, kann schliesslich nicht immer 24h zum Testen zum Kollegen gehen..........

 

Eine defekte "vorher ging sie" Box zum ENx Schlachten wäre auch mal ein Ansatz....

 

Ich bleibe weiter fest der Überzeugung, daß Eure Scripts nur einen Hardwarefehler besänftigen, aber nicht beseitigen können.....

 

Grüße

 

ZYKLOP

bearbeitet 3. Oktober 2007 von zyklop

[Gast zyklop]

Hy Freaks !!

 

Um die These mal zu erweitern:

 

Habe gerade bei einem Kumpel (schwarze sagem ohne Probs) auf den Quartz geschaut,

ist ein "27.000 NDK:03" der ist auch am Rumpf (Masse) verlötet....

 

Meine Zwitscherbox hat einen "HKC 27000 BO" , ist nicht an der Masse gelötet !! (frei beweglich !!)

 

Kann das Bitte mal jemand (am Besten ALLE, auch die gehenden Boxen) nachvollziehen ?!

 

Grüße

 

ZYKLOP

 

PS: Im übrigen hat meine "Ver-" Bastelbox auch mit der Betanova und dem Sattuner schon "Hänger" gehabt (Weiss ich vom Vorbesitzer, aus der Verwandschaft..)

bearbeitet 3. Oktober 2007 von zyklop

[The Invisible]

wenn du mir anhand von nem bild zeigst wo genau der ist kann ich auf ner schwarzen die nicht zwitschert mal nachschauen.

[Gast zyklop]

etwas seitlich zwischen AVIA600 und dem eNX Chip in richtung Tuner auf dem Hauptboard (aber nicht der auf dem Tuner !!)

 

Grüße

 

ZYKLOP

bearbeitet 3. Oktober 2007 von zyklop