Sagem Zwitscher-Box

[bahnbooster]

hast Du SAT oder Kabel ? Im Kabel sind diese Sender nicht FTA. Und newcode hat schon gesagt, dass avia_check nicht wirklich gut funktioniert im PES - Mode.

[niemand0815]

@bb: es geht um was anderes. warum andere wd bei aktivem aviacheck wohl beeinträchtigt werden obwohl avia_check bei den sendern gar nicht aktiv werden sollte. sprich: ob avia_check vielleicht indirekt irgendwie das system beeinflusst.

und ich habe natürlich sat. sonst wären die ja nicht fta :-)

und newcode weiss das ich eine 1xi-sagem-schwarz-sat habe.

 

und bedenkt bitte vor irgendwelchen "bei mir isses nicht so" posts das jede box anders ist.

 

wenn ich grad dabei bin:

ucode14, avia022, spts+pm+hwsections an sowie alle wd's.

gt-proc einstellungen beta20default.

 

und mir geht es darum rauszufinden (ich wiedehole mich, gell?) wie es sein kann das wenn man die avia-checks reniced trotzdem noch 20% systemlast mehr laufen als ohne aktives avia_check (das sind genau die 20% die die aktuellen check-versionen mehr an last verursachen als die alten).

 

ich vermute hier wirklich eine indirekte systembelastung, vielleicht durch belegte handles oder andere "temporär volle" resourcen.

 

EDIT:

hat übrigens jemand ne idee wie man der box das knacken beim umschalten abgewöhnen kann bei ucode14/vb022 und spts=an?

 

EDIt2:

@bb:

ausserdem hat newcode geschrieben das die hängerdetektion ohne spts nicht zuverlässig funktioniert, es also zu zwitscherern die nicht erkannt werden kommt.

das ist genau das gegenteil von dem was ich beobachte :-)

ich habe eher zu viele resets mit check aktiv.

bearbeitet 28. Oktober 2007 von niemand0815

[bahnbooster]

allet kloar Kann man wirklich nicht vergleichen, da ich beispielsweise HW Sections nicht anschalten kann (Dauer Bildrucken). Dann halt ich mich lieber raus .

[newcode]

@niemand0815

 

Beim Umschalten zwischen FTA Programmen darf kein Reset kommen.

 

Schau doch bitte mal nach, ob die Datei /tmp/ecm.info wirklich gelöscht wird, wenn

Du von einem crypted auf ein FTA Programm schaltest.

[niemand0815]

die ecm.info wird bei mir bei jedem umschalten erzeugt.

auch zwischen fta-sendern.

 

setup: m*d1.25 als einziger camd.

ist das bei der c*d3 anders?

 

EDIT:

auch im multicam m*d.125 mit camd2 ist das so.

die datei ist leer aber vorhanden.

löscht man sie ist sie beim nächsten umschalten wieder da.

bearbeitet 28. Oktober 2007 von niemand0815

[newcode]

@niemand0815

 

Ja, da wird die nur erzeugt, wenn ein verschlüsseltes Programm empfangen wird. Deswegen geht avia_check bei Dir auch nicht in den inaktiven Zustand.

 

Du kannst die Datei bei einem FTA Programm mal löschen und wirst sehen, daß dann keine Resets mehr ausgelöst werden.

 

Grüße

[niemand0815]

hab ich schon gesehen.

 

gibts keine möglichkeit das für alle c*d's gültig zu machen?

 

langsam sind die einschränkungen schon etwas störend:

zwingend c*d3, spts an, am besten noch ucode14 und avia022.

 

besser wäre denke ich wirklich etwas zu finden was sowohl mit jeder c*d als auch ohne spts funktioniert (wobei man letzeres noch umschiffen kann).

 

(wäre es hier sinnvoll wenn die ecm.info vorhanden ist zu prüfen ob diese leer ist? bei jeder mit dem osd laufenden camd sollte diese doch was enthalten wenn non-fta und leer oder nicht vorhanden sein bei fta, oder?)

 

was anderes:

wie erklärst du die 20% system-load wenn man die 3 prozesse reniced?

also wie oben beschrieben, renice auf den daemon und dann hat man die gewohnten 40% im nice-load, aber eben immer noch 20% im system-load.

bearbeitet 28. Oktober 2007 von niemand0815

[newcode]

@niemand0815

 

Ist bei FTA Programmen die ecm.info bei Dir denn leer ?

 

Die Rechenlast im inaktiven Modus ist die Last der Verwaltungsaufgaben. Das ist nicht viel. Die Differenz zum aktiven Modus ist der Meßvorgang. Der ist rechenintensiv.

 

Um Zwitscherproblem auf eine andere Art zu lösen hab ich noch eine Idee. Vermutlich werde ich dazu aber ein Kernel-Modul patchen müssen. Und das gehört dann auch in den Fullmember Bereich.

 

Grüße

[bahnbooster]

EDIT:

auch im multicam m*d.125 mit camd2 ist das so.

die datei ist leer aber vorhanden.

löscht man sie ist sie beim nächsten umschalten wieder da.

 

das kann ich bestätigen (SAGEM, Kabel)

[schubsi]

@newcode

 

Zwischenbericht nach nem halben Tag mit avia-check 0.97:

 

Hab sie "drüberkopiert" und per Putty ohne weitere Parameter gestartet. Schick ist, dass dann die Log-Einträge zum Putty geleitet werden. Aber ich vermute mal, dass bei Beendigung der Session avia-check beendet wird, gell?

 

Ich hab mal auf einen "Problemsender" (QAM256) geschaltet und den ganzen Nachmittag Xbox gezockt :-) In der Zwischenzeit hat Tschecka (phonetisch ) 16 mal zugeschlagen, dazwischen hat er 2x nen Rezap gemacht, eben die Box aus den Standby geholt: Läuft noch :-)

Üblicherweise hab ich ein stehendes Bild oder Schwarzbild oder ...

 

Bis jetzt bin ich zufrieden, muss ich mal so sagen, die regelmäßigen Hakler (wie bei der build-in Version) treten nicht mehr auf.

 

Ich werde den Rest des Tages noch ein bissl glotzen und dann die nächsten Tage mal berichten...

 

-==[schubsi]==-

bearbeitet 28. Oktober 2007 von schubsi

[newcode]

@schubsi

 

Hi.

 

Auch wenn Du deine telnet Sitzung beendest läuft avia_check weiter. Ist ein daemon.

 

Grüße

[newcode]

@bahnbooster

 

Hi.

 

Ich habe das gerade mal getestet. Habe von PW auf ARD umgeschaltet: die ecm.info ist unverändert, also nicht leer.

 

Grüße

[niemand0815]

die frage ist also:

gibt es eine methode festzustellen ob man auf einem fta sender ist oder nicht die bei jeder cam funktioniert.

und das müsste es geben, das osd zeit es ja auch richtig an.

also:

woher kommt die anzeige der cryptmethode bzw fta im osd?

[newcode]

@niemand0815

 

Hi.

In der pmt.tmp steht das drin.

Die zweite Möglichkeit wäre, es direkt aus dem ucode zu holen. Nur werden leider die CW's im ucode auch nicht gelöscht.

Irgendwo im ucode muß es also noch einen Eintrag geben ob die CW's benutzt werden.

 

Grüße

[niemand0815]

ich denke dann solltest du den wd an die osd-anzeige koppeln, also an die pmt.tmp.

so stimmt die osd anzeige mit der wd aktivität überein.

[newcode]

@niemand0815

 

So einfach ist das nicht. Ich muß nach beidem schauen.

Wenn ich Premiere mit meiner Abo Karte sehe soll avia_check inaktiv sein. ;-)

 

Grüße

 

P.S. v0.98 läuft im Test.

[bahnbooster]

@newcode:

 

@bahnbooster

 

Hi.

 

Ich habe das gerade mal getestet. Habe von PW auf ARD umgeschaltet: die ecm.info ist unverändert, also nicht leer.

 

Grüße

hm, wenn ich von ARD auf nonFTA schalte, erhalte ich eine ecm.info die nicht leer ist . Von nonFTA auf ARD leert diese Datei (also 0 Byte Datei). Wieder zurück füllt die Datei . Das trifft auch auf die pid.info zu.

bearbeitet 29. Oktober 2007 von bahnbooster

[niemand0815]

@bb:

kann ich bestätigen.

mit m*d ist die ecm.info nach wechsel von nonfta zu fta sofort leer.

bei nonfta enthält diese alle nötigen infos.

 

da steht dann auch source=... drin.

hilft das für die karte?

 

 

edit:

hmm. wenn du die ecm.info und die cainfo.txt auswertest kannst du also theoretisch genau bestimmen ob der sender gewechselt wurde, ob es fta oder nonfta ist und ob eine karte oder ein vogel verwendet wird, korrekt?

damit müssten sich doch eigentlich alle benötigten zustände für einen stabilen lauf des daemons prüfen lassen:

 

* wurde der kanal gewechselt? (wenn ja dann waittime warten, damit wir nicht dem avia-wd in die quere kommen)

* sind wir fta?

* sind wir mit karte unterwegs?

bearbeitet 29. Oktober 2007 von niemand0815

[newcode]

Hi.

Ich habe in avia_check folgendes geändert:

 

Zuerst wird nachgeschaut ob ecm.info existiert. Wenn nein -> inaktiv

Wenn ja, wird ausgelesen wie die Länge der CAID's in pmt.tmp ist.

Ist die > 0 -> aktiv sonst inaktiv.

 

Hier die neue Version:

 

 

Have fun

 

EDIT: Ich habe den Link entfernt. Die v0.98 hatte einen Fehler. Die v0.99 findet Ihr weiter hinten.

bearbeitet 30. Oktober 2007 von newcode

[bahnbooster]

öhm, hab mal 0.98 draufgepackt und einpaar mal normal umgeschaltet. Irgendwie hat sich avia_check dabei abgeschossen - jedenfalls hatte ich nur noch Knacksen und Schwarzbild. Laut Sysinfo war kein avia_check Prozess mehr da

 

Hab jetzt nochmal per Tuxcommander gestartet, mal schauen, ob er sich auch ohne Umschalten killt. Bild und Ton waren dann sofort wieder da. Muss weiter bügeln

bearbeitet 29. Oktober 2007 von bahnbooster

[niemand0815]

avia-check wird jetzt bei fta nicht mehr aktiv, prozessorlast dort zeitweise auf 0% runter.

bei non-fta wie gehabt, bei mir bei jedem umschalten nach ein paar sekunden trotz bild und ton und genug interrupts ein reset.

 

eine andere frage:

wenn wir es schaffen bei jedem umschalten automatisch den avia-check aufrufen zu lassen dann können wir den watchdog bei fta ja komplett lahmlegen.

btw:

gibt es irgendeine möglichkeit das die zapit den aviacheck sozusagen "aufweckt" wenn er umschaltet?

zzt scheint er ja im hintergrund weiter aktiv zu sein und durch dateiprüfung aktiv auf ein umschalten zu warten. wenn wir es aber schaffen ihn irgendwie komplett "abzuschalten" wenn er nicht gebraucht wird dann wäre das optimal.

aber nur so eine idee :-)

 

wichtiger fände ich wirklich eventuell nach dem umschalten dafür zu sorgen das ein reset nur dann kommt wenn wirklich das bild steht/der ton zwitschert.

 

 

EDIT:

ich hatte eben ein komisches erlebnis, muss es aber noch verifizieren.

hab die box frisch gestartet, danach die tests gefahren. avia_check war definitiv am laufen (alle 3 prozesse da, mit ps geprüft).

hab dann die box jetzt mal ne knappe stunde auf discovery laufen lassen und wollte dann das renicen testen.

ps -ef um die pid zu finden => AVIA_CHECK WAR WEG!

ich vermute also der wd ist abgeschmiert. ich probier das jetzt nochmal. meldung war keine zu sehen.

 

EDIT2:

und nochmal verifiziert: auf einen non-fta sender geschaltet, gewartet.

regelmaessig ps | grep avia_check.

nach 1/2 stunde ohne besondere meldungen waren die prozesse weg.

keinerlei meldungen an der console zu sehen(!)

nicht mal ein reset wurde ausgelöst oder ähnliches zwischen dem letzen check wo sie noch da waren und dem wo sie weg waren.

bearbeitet 29. Oktober 2007 von niemand0815

[newcode]

Sorry.

 

Ich habe den close der pmt.tmp vergessen. Bitte unbedingt updaten sonst sind zu viele filehandles offen.

 

avia_check v0.99

 

MD5SUM: 0101fe0940c4799d7efd4e3d59e9a07a

 

Have fun

[bahnbooster]

thx

 

newcode, Du solltest mit den Versionsnummern haushalten .

[niemand0815]

0.99 läuft jetzt ohne "abzuschmieren".

 

prozessorlast bei fta immer noch recht niedrig (in abständen auf 30%, sonst 0%). bei non-fta sehr hoch (-60%).

 

weiterhin beim umschalten von nonfta unnötiger resets nach ein paar sekunden trotz funktionierendem bild.

wie gesagt, vielleicht wäre es schön das auch noch irgendwie wegzubekommen (für die bei denen eben nicht bei jedem umschalten ein hänger kommt sondern bei denen in 90% der fälle das umschalten geht).

 

frage:

kannst du eigentlich den sourcecode zur verfügung stellen?

wenn mehr leute drüberschauen kommen uns vielleicht nocht mehr ideen. gut wäre dann vielleicht ein eigener thread im "keywelt plugin" forum :-)

 

noch ne frage:

kannst du irgendeine aussage dazu machen wie viel schlechter die hängerdetektion ohne spts läuft? wie gesagt, das knacken beim umschalten nervt doch ziemlich.

alternativ dazu müsste man mal schauen ob wir die zapit so modifizieren können das der ton beim umschalten für 1-2 sekunden abgeschaltet wird :-)

 

und die wiederholungsfrage:

wie kommts das nach einem renice trotzdem die hälfte der last nicht im nice läuft? (genauere formulierung siehe vorherige posts)

bearbeitet 30. Oktober 2007 von niemand0815

[newcode]

@bahnbooster

 

Keine Sorge, kann nicht passieren. Bin ab Donnerstag erst mal ein paar Tage im Urlaub. :-)

 

@niemand0815

 

Ich habe das schon mal erklärt: wenn ich versuche Unterschiede in den Interrupts im Bereich von 20-40ms zu erkennen kostet das Prozessorzeit. Was stört Dich daran ?

Die Leute wollen doch nur in Ruhe einen Film schauen. Die Boxen sind besser benutzbar, darauf kommt es an. Außerdem will ich mehr Energie darauf verwenden die Ursache zu beseitigen.

Was den Source angeht: der ist GPL. Das heißt nicht, daß ich ihn public mache, aber jeder, der avia_check benutzt, kann ihn von mir bekommen. PM genügt (nach meinem Urlaub :-))

Im PES Mode ist die Erkennung schlecht. Bei den wenigen Tests die ich damit gemacht habe gab es in ca. 75% der Fälle keine Unterschiede in den Interrupts.

 

Grüße