Sagem Zwitscher-Box

[faze]

nach langem probieren habe ich es irgendwie hinbekommen avia check über den tux box commander zu starten, zumindest sagt "ps" mir das es läuft. Den SPTS Mode hab ich eingeschaltet, gibt es jetzt noch irgendetwas zu beachten?? Muss ich z.B. noch irgenwelche Einträge in der start neutrino machen oder ähnliches, ich hab mir zwar alles durchgelesen was avia check betrifft aber trotzdem oder vllt. gerade deshalb blick ich jetzt überhaupt nicht mehr durch. (Das avia check läuft ist reiner Zufall, irgendwie hat mich der Tuxbox Commander auf einmal gefragt ob ich es starten möchte wieso weiß ich aber selbst nicht )

[niemand0815]

@newcode:

muss spts jetzt an oder aus sein?

bei ucode14 und spts an hab ich nämlich das problem das es beim umschalten "knackt". mit ucode1a geht es dann, aber dafür hab ich mehr zwitscheranfälle :-)

ich hab normal hwsections und spts aus beim ucode014 und die box läuft inzwischen fast ohne zwitschern. das wäre mir am liebsten *g*

 

ich werd den 0.96 trotzdem mal aufspielen auf die b19 zum testen.

[mike99]

Ich habe SPTS zur zeit noch aus mit 014, einfach testen (sieht erstmal nicht schlecht aus).

bearbeitet 23. Oktober 2007 von mike99

[bahnbooster]

wie newcode schon sagte, ist die Erkennung im PES Mode (SPTS aus) wesentlich schlechter, da der AVIA weiter läuft. Um zuverlässig den ENX - Freeze zu erkennen, sollte SPTS an sein.

 

@sutol:

 

Der Chip wird auf jeden fall zu heiß. Besitze aber leider kein IR Thermometer um mal genau zum messen.

 

Dann miss doch gleich mal am Netzteil nach, Du wirst Dich wundern, wie heiss das punktuell ist . Die Temperatur spielt vielleicht auch ne Rolle, aber bedenke, dass es mit Karte nicht zwitschert.

bearbeitet 23. Oktober 2007 von bahnbooster

[niemand0815]

@newcode bzgl b20 und avia-check 0.96:

 

prozessorlast:

----------------

kann sein das die 0.96 mehr last erzeugt als die 0.95? ich komme mit 20/4 auf eine last von 40-60% nur durch avia_check, mit 10/4 sogar noch höher.

 

das kommt mir etwas hoch vor.

 

eine frage:

kannst du den ganzen watchdog und alle seine aktionen mal auf nice 20 setzen? dann sieht man im sysinfo genau das es unkritische last ist (da es dann als nice und nicht als system load angezeigt wird).

ein renice -n 20 -p pids bringt ja leider nicht viel da das nur deine 3 steuerprozesse (warum eigentlich 3?) niced, aber nicht was immer die danach noch "spawnen".

 

 

"resource unavailable" mit 0.96 wieder da:

-------------------------------------------------

übrigen hat die 0.96 wieder das resource unavailable problem der 0.94 welches mit der 0.95 eigentlich weg war.

wollte das nur nicht im beta thread posten.

 

 

zu agressives vorgehen bei defaultwerten

------------------------------------------------

bei deinen defaultwerten von 10/4 kommen bei mir viele unnötige resets obwohl spts aus ist. mit 20/4 klappt es wesentlich stabiler.

(ucode14,avia022,hwsec=aus,spts=aus,rest an im den treiberoptionen,gtproc auf b20 defaults)

 

 

reset beim umschalten

--------------------------

was mir bei der 0.96 auch erstmals aufgefallen ist: nach jedem programmwechsel kommt ein reset. das führt dazu das das bild kommt und dann kurz wieder schwarz wird. lässt sich das irgendwie verhindern?

(z.B. wenn progid vorheriger aufruf <> aktuelle progid dann kein reset ausführen, beim nächsten durchlauf [also nach z.B. 200ms] würde dann ja wieder ein reset durchgeführt)

bearbeitet 24. Oktober 2007 von niemand0815

[newcode]

@niemand0815

 

Ich habe nur die Auswertung der Kernelmessages eingebaut. Das erhöht die Rechenlast nur beim Zwitschern. Die Einstellung des Grenzwertes für den Interrupt hat keinen Einfluß auf die Last. Hast Du Probleme mit irgenwelchen Reaktionszeiten ?

 

Es gibt nur die drei Threads. Zwei sind von mir, der dritte vom Compiler. Weitere Threads werden nicht erzeugt. Dein renice ist also genau so gut wie meins. Selbst wenn ich weitere Threads erzeugen würde hätten die die selbe dynamische Priorität.

 

Mit resources unavailable hab ich nichts zu tun. :-) Mach meine Box (Kabel) auch wenn ich neu geflasht habe. In den services stehen dann Sat Werte. avia_check läuft dann noch garnicht.

 

Ich fahre meißtens sogar mit 8/4. Die Fehlresets (ob es wirlich welche sind weiß man nicht) halten sich in Grenzen.

 

Die Resets beim Umschalten hat das 2006er Image immer gemacht (wenn man es so konfiguriert hat). Die betas machen das nicht mehr. Da das zwitschern oft direkt nach dem Umschalten beginnt, finde ich das O.K.

 

Grüße

[niemand0815]

hab nochmal mit diversen werten probiert. ab 40/4 sind die umschaltresets weg. unnötige hab ich da auch nicht mehr.

 

ich vermute alles hängt extrem vom zwitschertyp der box ab. bei den betas hab ich ja wie vorher schon berichtet sowieso kaum noch bis gar kein zwitschern mehr.

 

eventuell muss der user da ziemlich experimentieren bis ein guter wert rauskommt. wenn man es nämlich anscheinend für den einen boxtyp gut macht ist es für den anderen schlecht.

 

bei 400 hab ich minimale verzögerung wenn es mal kurz hängt.

fast nicht merkbar, auf jeden fall im vergleich zu früher sehr wenig störend.

 

bei weniger als 200 hab ich merkbare ruckler die, da sehr häufig, wirklich extrem stören.

 

der reset beim umschalten im 2006er war anders, da er direkt BEIM umschalten durchgeführt wurde. somit war er nicht zu sehen.

das problem jetzt ist das man es sieht, denn das bild und der ton kommen, danach gehen sie wieder weg :-)

das stört beim zappen doch etwas.

 

btw:

du hast doch ucode14 mit spts und avia022 oder 028 in verwendung, oder? hast du auch starkes knacken beim umschalten in dieser kombination? das hatte ich vorher nie, aber seit beta10 ungefähr hab ich das in dieser kombi so das ich nicht mehr mit spts fahren kann.

 

EDIT:

nochmal zu checkwerten (hab etwas mehr rumprobiert):

bei 100 und 200 habe ich sogar beim wechsel von ard zu zdf und vice versa resets und rezaps.

mal abgesehen von den umschaltresets und einem rezap bei dem nach wechsel auf discovery channel ich mich plötzlich gleich im zdf wiederfand, von dem ich eigentlich grad weggewechselt bin :-)

 

ich denke der optimale wert ist wirklich von box zu box verschieden, denn die zeiten die die box zum "eintunen" und zur initialisierung eines stabilen bildes braucht ist wohl stark unterschiedlich.

die frage ist ob der watchdog feststellen kann ab wan die box sich stabil auf einen sender eingetuned hat und alles läuft, so das es erst DANN in eine überwachung mit niedriger frequenz wechseln kann.

im detail:

nach einem programmwechsel sollte das plugin 5*checktimer warten bis es losgeht. danach wieder prüfung alle checktimer.

eventuell könnte man so erreichen das nach dem programmwechsel keine unnötigen resets stattfinden, aber trotzdem während des stabilen schauens schnell reagiert wird.

checktimer wäre der wert welcher zzt defaultmässig auf 100ms steht.

bearbeitet 24. Oktober 2007 von niemand0815

[mike99]

Da das zwitschern oft direkt nach dem Umschalten beginnt, finde ich das O.K.

Das sehe ich auch so, Totalabstürze hatte ich keine mehr die re-Zap und der Reset haben alles alleine gerade gebogen. Mit den Werten experimentiere ich noch rum zwischen 8-14 zu 4 im PES-Mode.

 

Zum SPTS konnte ich noch keinen richtigen Unterschied feststellen, welchen Mode benutzt du?

 

Habe auch mal höhere Werte getestet aber zb. 20/4, brachte keine Punkte.

Mit den Umschaltresets kann ich leben.

 

Gruß Mike

[faze]

Leute hat eigentlich schon jemand bemerkt das die *box auf Brummi Star läuft?!

[Pandorra]

Moin moin,

 

Zitat:

 

die Ursache für das zwitschern der Sagem Box liegt an dem Netzteil, entweder Ihr besorgt euch ein neues Netzteil oder ihr schaut mal (wenn ihr ein weißes Netzteil habt) auf den Widerstand mit der Bezeichnung RR1516 direkt am Kondensator ob der noch in Ordnung ist, wenn dieser nicht mehr erkennbar ist dann austauschen oder einfach mal nachlöten.

 

RR 1516= Braun Schwarz Rot Gold = 1 KOhm

 

muss aber ein weißes Netzteil sein bei einem Braunen sieht der Fehler anders aus.

Habe schon ein paar Boxen mit einem neuen Widerstand bestückt: alle kein zwitschern mehr. Bei 2 Boxen das braune Netzteil mit einem weißen Netzteil ausgetauscht funktioniert.

 

MfG

 

45

 

Zitat ende

 

 

Das hab ich in meinem " Hausboard " gefunden.Bevor ich jetzt zerrissen werde, sollte man einfach mal dieses oben Beschriebene ( auch wenn der Widerstand super aussieht ) befolgen, damit diese Fehlerquelle definitiv ausgeschlossen werden kann.

 

MfG

 

Pandorra

[Xander]

zum 73 1/2 mal

 

Der Widerstantausch bringt nichts in Bezug auf das Zwitschern aus den Lautsprechern.

 

Gruß Xander

[bahnbooster]

@niemand0815:

 

hast Du standardmäßig SPTS aus ?? Greift avia_check dabei zuverlässig ?? Ich hab mittlerweile SPTS immer an, verzichte daher auf AC3. Im PES Mode zwitscherte es immer fröhlich weiter, ließ sich dann aber durch umschalten ...

 

was mir bei der 0.96 auch erstmals aufgefallen ist: nach jedem programmwechsel kommt ein reset.

 

... beheben

[newcode]

Hi.

 

Habe wieder eine neue Version fertig.

 

avia_check v0.97

 

MD5SUM: 052f7589382088107c5097879cedb6ad

 

Es gibt keine neuen Features. Ich habe nur den Code bereinigt, ist jetzt 1,5K kleiner.

Nach ca. 48h Test habe ich die Standardeinstellung auf 90ms/5s festgelegt.

 

Ich habe bei mir damit im SPTS Mode keine Fehlauslösungen.

Eine Pause von 5s ist erforderlich damit der Avia Watchdog erkannt wird. Bei 4s schlüpft der manchmal durch.

Kleinere Werte als 9/5 setzt avia_check auf die Standardwerte.

 

Have fun

[bahnbooster]

@newcode:

 

wolltest Du nicht noch einen Log - Schalter mit dran packen ? Aber danke für Deine Arbeit . Läuft im SPTS - Mode tadellos.

[niemand0815]

Es gibt nur die drei Threads. Zwei sind von mir, der dritte vom Compiler. Weitere Threads werden nicht erzeugt. Dein renice ist also genau so gut wie meins. Selbst wenn ich weitere Threads erzeugen würde hätten die die selbe dynamische Priorität.

@newcode:

ich hab mal was probiert:

in der beta 20 hab ich ja mit avia_check über 50% last (ohne 0%).

wenn ich jetzt die 3 prozesse von dir mit renice -n 20 -p 399 400 401 renice dann hab ich die von den früheren (0.94 und vorher) gewohnten 20% als nice load.

ABER:

die seit den neueren versionen vorhandenen zusätzlichen 30% sind als system load verzeichnet.

 

wie du das beschreibst dürfte das aber nicht von avia-check direkt kommen (da die hauptprozesse ja geniced sind). folglich muss seit der 0.95 oder 0.96 irgendetwas einen anderen (system)prozess zu höherer load veranlassen.

 

das ist übrigens dauerhaft, auch wenn keine resets oder rezaps stattfinden. und sowohl auf kodierten als auf auf freetv.

 

vielleicht hift dir das es einzugrenzen. und vielleicht ist es ja nicht schlimm, aber komisch finde ich das schon.

 

zumal man die hohe last manchmal (nicht immer) an langsamem menüaufbau merkt (was eindeutig bei ausgeschaltetem avia-check in der b20 nicht bemerkbar ist).

[niemand0815]

@niemand0815:

 

hast Du standardmäßig SPTS aus ?? Greift avia_check dabei zuverlässig ?? Ich hab mittlerweile SPTS immer an, verzichte daher auf AC3. Im PES Mode zwitscherte es immer fröhlich weiter, ließ sich dann aber durch umschalten ...

 

was mir bei der 0.96 auch erstmals aufgefallen ist: nach jedem programmwechsel kommt ein reset.

 

... beheben

ich habe zzt spts aus da mit ucode 14 und spts bei mir massives "knacken" beim umschalten auftritt.

 

die ucode21 kann ich mit spts leider nicht testen da sie bei mir in der b20 nicht richtig läuft.

 

ich hatte bisher noch keinen zwitscherer der nicht automatisch behoben wurde, wobei ich vermute das oft irgendein anderer watchdog zuschlägt und NICHT der avia-check.

ohne avia-check hab ich nämlich auch in den aktuellsten betas kaum zwitscherer.

 

probleme habe ich das der avia-check eher zu schnell zuschlägt, wenn es gar nicht nötig wäre (z.B. beim umschalten trotz bild und ton). ich vermute ich liege ganz an der minimalgrenze von der interruptzahl her.

 

@newcode:

die 0.97 läuft besser als die 0.96 von der "fehlerkennungsrate" her. bei deinen defaults (90ms/5s). ich vermute es lag wohl an den 4s die zu wenig waren, mit dem parameter hatte ich nie herumgespielt *g*.

 

edit:

@newcode:

noch eine neue beobachtung:

ich hatte schon ein paarmal den effekt das es mit dem rezap probleme gab.

beispiel:

ich war auf ard, und habe dann auf zdf gezapt, dann hat das script zugeschlagen.

nur hat es mich wieder auf die ard zurückversetzt.

das wäre ja nicht zu schlimmt, aber beim durchzappen der kanäle hatte ich jetzt schon 4-5 mal den effekt das plötzlich die box ganz von selbst anfing 20-30 mal kanäle hochzuschalten.

beispiel:

ich war auf ard, hab dann zdf, swr, br3, hr3, sat1 gezappt und wollte stehenbleiben, nur hat die box munter die nächten 20-30 kanäle weitergezappt bis sie dann irgendwann von selbst aufhörte. die fb war in der zeit batterielos (um zu verhindern das sie sendet) und die wiederholungsverzögerung steht bei mir auf 999.

ohne avia_check ist das verhalten definitiv nicht zu beobachten (hab extra gewarten und das lange beobachtet um das sicherzustellen).

wie gesagt, es lässt sich leider nicht eindeutig provozieren.

das zeigt mir aber das avia_check vielleicht wirklich nicht direkt nach dem umschalten aktiv werden sollte (5sekunden wartezeit nach dem umschalten für den avia-wd, dafür könnte ja der selbe parameter wie die zeit zwischen dem aktivwerden verwendet werden).

das würde den "bild schwarz" effekt der nach dem umschalten eintritt ja trotzdem noch beseitigen (nur eben mit 5s wartezeit), dafür aber die unnötigen umschaltresets/rezaps verhindern.

bearbeitet 27. Oktober 2007 von niemand0815

[newcode]

@niemand0815

Wenn Du zwischen ÖR Sendern hin und herschaltest macht avia_check nichts. Ist dann inaktiv. Schau mal in dein Log was da los ist.

 

Der rezap nach dem Umschalten wird nur gemacht wenn der Avia Watchdog ausgelöst hat. Der enxreset hat den Avia zum Absturz gebracht und das Bild ist dann sowieso schon schwarz.

Das tritt auch bei Boxen auf die nicht zwitschern (Schwarzbildbug des VB022).

 

Grüße

[waddi]

Kann mir jemand erklären, warum ein GLJ Image auf einer Sagem 2xi Kabel 2 Wochen lang läuft, aber sobald ich das Keywelt Image drauf spiele, die Box nach 30 Sekunden steht und sich noch nicht mal mehr neu bespielen lässt, nur mit Nullmodemkabel und Hyperterminal bekomm ich dann wieder ein anderes Image drauf und das läuft dann wieder?? Jetzt 4 x probiert, bevor ich hier frage, immer das gleiche. Letztes offizielles Image mod bei merkwürden.

bearbeitet 27. Oktober 2007 von waddi

[newcode]

@waddi

 

Hat das irgendwas mit dem Thread hier zu tun ???

[waddi]

naja, irgendwie schon dachte ich

[bahnbooster]

@Waddi:

 

nicht wirklich hier in diesem Thread, da es hier nur um das SAGEM Zwitscher Problem geht

bearbeitet 27. Oktober 2007 von bahnbooster

[waddi]

ich hatte die Bezeichnung Zicke in der Überschrift gelesen, sorry

[niemand0815]

@niemand0815

Wenn Du zwischen ÖR Sendern hin und herschaltest macht avia_check nichts. Ist dann inaktiv. Schau mal in dein Log was da los ist.

@newcode:

das komische ist:

MIT aviacheck schlägt bei JEDEM umschalten der avia watchdog los.

OHNE aviacheck nicht (per kill prozess gekillt und schon ist der effekt weg).

 

das ganze ist mir sehr suspekt, könnte es sein das die neueren avia_check versionen immer mehr resourcen brauchen und das deswegen andere dinge beeinflusst werden?

 

im log sieht man übrigens manchmal nur enx resets, manchmal avia resets, und oft sogar rezaps.

 

ich versuch nochmal ein log zu ziehen und zu posten, hab nur zzt keins bei der hand.

 

frage:

wäre es schwierig den avia-check bei jedem auslösen und genau auf der console ausgeben zu lassen was er macht (mit vorangestelltem "[aviacheck]")?

 

also zb:

"[aviacheck]enxreset"

"[aviacheck]rezap"

...

somit könnte ich aviacheck als direkte ursache ausschliessen und wir könnten uns darauf konzentrieren herauszufinden warum er andere prozesse in aktion versetzt (wenn es denn so ist).

das ganze würde sich aber mit meiner beobachtung decken das der aviacheck inzwischen mehr system als eigene prozessorlast verursacht.

 

EDIT:

generell deckt sich das oben mit meiner beobachtung das ich mit aktivem avia_check MEHR bildaussetzer habe als ich ohne avia_check zwitscherer habe.

ohne check hab ich zzt nur 3-4 zwitscherer pro tag, mit hab ich 10-20 watchdog-induzierte bildruckler PRO STUNDE (bei non-FTA).

 

witzigerweise fällt mir gerade auf das ich mit check sogar bei FTA sendern schon WD-Bildruckler hatte, obwohl dort nie zwitscherer oder ähnliches auftreten.

 

mit der scriptversion war das definitiv noch nicht so. ich kann dir aber nicht genau sagen ab welcher version sich diese effekte eingeschlichen haben. mir kommt es aber vor wie wenn es mit der zunehmenden prozessorlast zusammenhängt.

bearbeitet 28. Oktober 2007 von niemand0815

[newcode]

@niemand0815

 

Hi.

avia_check macht im SPTS Mode maximal drei Dinge nach dem Zwitschern.

 

1) enxreset (immer)

2) AudioPid neu schreiben (immer)

3) 5s lang in den Kernel-Messages lesen ob der avia Watchdog ausgelöst wird. Wenn ja, rezap.

 

Im Log erkennst Du den avia Watchdog an der Meldung "... video decoding stopped ...".

Und der rezap ist im Log nicht zu übersehen.

Alle Infos sind also im Log schon drin, es macht ja keinen Sinn, sie doppelt reinzuschreiben.

 

Poste mal ein Logfile.

 

Grüße

[niemand0815]

so, hier die logfiles.

hin und herzappen zwischen RTL2 und SRTL, also beide FTA.

 

mit avia_check 0.97 bei defaultwerten (9/5)

PES, queue 0 normal.
[CBasicClient] connect failed: /tmp/camd.sock01
/tmp/camd.sock01: No such file or directory
[CBasicClient] connect failed: /tmp/camd.sock02
/tmp/camd.sock02: No such file or directory
PES, queue 0 normal.
[CBasicClient] connect failed: /tmp/camd.sock01
/tmp/camd.sock01: No such file or directory
[CBasicClient] connect failed: /tmp/camd.sock02
/tmp/camd.sock02: No such file or directory
avia_av_wdt_thread: video decoding stopped ==> restart
PES, queue 0 normal.
[CBasicClient] connect failed: /tmp/camd.sock01
/tmp/camd.sock01: No such file or directory
[CBasicClient] connect failed: /tmp/camd.sock02
/tmp/camd.sock02: No such file or directory
Versuche Reset...
avia_gt_proc: START - reINIT demux
avia_gt_proc:  END  - reINIT demux
null nach /proc/bus/gtx geschrieben
PES, queue 0 normal.
Versuche Reset...
avia_gt_proc: START - reINIT demux
avia_gt_proc:  END  - reINIT demux
PES, queue 0 normal.
[CBasicClient] connect failed: /tmp/camd.sock01
/tmp/camd.sock01: No such file or directory
[CBasicClient] connect failed: /tmp/camd.sock02
/tmp/camd.sock02: No such file or directory
null nach /proc/bus/gtx geschrieben
PES, queue 0 normal.
Versuche Reset...
avia_gt_proc: START - reINIT demux
avia_gt_proc:  END  - reINIT demux
PES, queue 0 normal.
[CBasicClient] connect failed: /tmp/camd.sock01
/tmp/camd.sock01: No such file or directory
null nach /proc/bus/gtx geschrieben
[CBasicClient] connect failed: /tmp/camd.sock02
avia_av_wdt_thread: video decoding stopped ==> restart
/tmp/camd.sock02: No such file or directory
PES, queue 0 normal.

 

dann ein kill 399 um den aviacheck loszubekommen per telnet abgesetzt und genauso weitergezappt:

PES, queue 0 normal.
[CBasicClient] connect failed: /tmp/camd.sock01
/tmp/camd.sock01: No such file or directory
[CBasicClient] connect failed: /tmp/camd.sock02
/tmp/camd.sock02: No such file or directory
PES, queue 0 normal.
[CBasicClient] connect failed: /tmp/camd.sock01
/tmp/camd.sock01: No such file or directory
[CBasicClient] connect failed: /tmp/camd.sock02
/tmp/camd.sock02: No such file or directory
PES, queue 0 normal.
[CBasicClient] connect failed: /tmp/camd.sock01
/tmp/camd.sock01: No such file or directory
[CBasicClient] connect failed: /tmp/camd.sock02
/tmp/camd.sock02: No such file or directory
PES, queue 0 normal.
[CBasicClient] connect failed: /tmp/camd.sock01
/tmp/camd.sock01: No such file or directory
[CBasicClient] connect failed: /tmp/camd.sock02
/tmp/camd.sock02: No such file or directory
PES, queue 0 normal.
[CBasicClient] connect failed: /tmp/camd.sock01
/tmp/camd.sock01: No such file or directory
[CBasicClient] connect failed: /tmp/camd.sock02
/tmp/camd.sock02: No such file or directory
PES, queue 0 normal.
[CBasicClient] connect failed: /tmp/camd.sock01
/tmp/camd.sock01: No such file or directory
[CBasicClient] connect failed: /tmp/camd.sock02
/tmp/camd.sock02: No such file or directory

 

man sieht das sofort, denn nach jedem umschalten kommt das bild, danach wird es kurz schwarz (wie schon vorher beschrieben).

 

es gibt also definitiv ein anderes verhalten mit und ohne avia-check.

obwohl es so aussieht als ob avia-check selbst wirklich nicht aktiv wird.

 

deswegen meine frage:

könnte es sein das avia_check irgendwie resourcen o.a. blockiert (handles, files etc) so das andere watchdogs nicht mehr darauf zugreifen können? ds würde denke ich evtl die hohe prozessorlast erklären als auch den effekt das der avia-wd mit avia_check öfter zuschlägt.

 

EDIT:

eventuell wäre interessant herauszufinden ob sich bezüglich der gt-proc watchdogs oder ab interruptverhalten was am cvs im laufe der betas verändert hat.

bearbeitet 28. Oktober 2007 von niemand0815