niemand0815

bevor ichs vergesse: die version .99 meldet als versionsnummer beim aufruf 0.98 :-)

wir sollten mit den tests bei der b22 nochmal neu anfangen da neuer kernel. btw: bei spts off hatte ich bisher auch nur wenig probleme. manchmal dauert halt die erkennung länger, aber er erkennt es irgendwann und resettet. die pid's kannst du doch über die emm.info herausfinden. dort steht das in der ersten zeile mit drin. bei fta ist die datei nicht da, aber da soll der checker ja eh nicht laufen.

@schubsi: teste mal was: schalte mal avia_check per kill ab. dann schau wie oft vom avia-watchdog etc ein risc crash oder decoding stopped kommt. danach schalte avia_check ein (per direktaufruf) und vergleiche. bei mir kommt im betrieb ohne avia_check fast nie ein anderer watchdog reset. sobald ich avia_check anschalte sehr viel häufiger. ich vermute evtl irgendein timingproblem zwischen den einzelnen watchdogs (wie viele laufen denn da? avia, enx, avia_check, sectionsd, ...) diese häufigeren resets bei mir passieren ohne grund. das bild bleibt vorher nicht stehen und der ton ist auch ok. was imho auch für ein timingproblem spricht. das soll nicht heissen das ich mit dem ergebnis unzufrieden bin, nur müssen wir bedenken das jede box anders reagiert. mir ist bei meiner box aufgefallen das seit dem der 20% anstieg in der last passiert ist (ich glaub das war nach der 0.94) diese häufigen resets passieren.

geh du erst mal in urlaub :-) kann man den programmwechsel über eines der files im tmp erkennen? beispiel: die pid steht ja in der ecm.info drin, und wenn die leer ist dann braucht man avia-check sowieso nicht (da fta). da steht auch drin ob es via e oder card entschlüsselt wird, eventuell reichen die infos dann ja aus. geschickt wäre natürlich wenn man die zapit so modifizieren könnte das sie avia-check ein umschaltsignal gibt. und ein stopsignal bei fta. leider ist das denke ich nicht möglich einfach zu implementieren. zum 1a: zzt (b20) geht bei mir der ucode1a nicht bei non-fta. aber avia-check scheint bei mir auf ohne spts zu laufen, nur eben etwas instabiler, weshalb ich wieder auf spts an gewechselt habe. warum geht eigentlich der 1a nicht? früher ging der doch ohne probleme. hat sich eigentlich bei dir schon mal jemand der programmieren kann wegen des sourcecodes gemeldet? EDIT: es wäre schon wenn du vor deinem urlaub noch die version mit direktem reset über die gtproc veröffentlichen könntest. vielleicht ist dann ein teil der prozessorlast ja weg (der system und useranteil beim renicen könnte davon kommen).

ah. dann hab ich dich falsch verstanden. wie gesagt, das es geht hat newcode ja bewiesen, und ich denke wenn man vielleicht das umschaltresetten abschalten könnte (vielleicht ja per parameter zu- und abschaltbar je nach bedarf) dann wäre es reif für version 1.00 danach dann feintuning: codepolice (resourcensparen, schlankermachen, verfeinern) und bugfixing. danach vielleicht wenn neue ideen kommen neue features *g*

naja, wenn nichts verbessert werden soll brauchen wir ja auch keine neuen images ;-) ihr seht das immer aus der sicht der extrem-zwitscherboxen. aber die grauzone mit den nicht ganz so zickigen hat eben das problem das beim umschalten das bild kommt und der ton, und dann ein paar sekunden später ein sichtbarer(!) reset durchgeführt wird. und das es prinzipiell funktioniert ist ja nachgewiesen, wie gesagt bedeutet das normalerweise das an den feinheiten gefeilt werden kann.

wie gesagt, bei mir habe ich mit aviacheck öfters "risc crashs" und enx-resets sowie rezaps als ohne. somit gehe ich einfach mal davon aus das bei grenzwertigen boxen (die ab und zu zicken aber eben oft auch normal laufen) die erhöhte cpu last evtl doch negative auswirkungen auf die anderen watchdogs hat. und wie gesagt ist das nicht kritisch oder ein echtes problem. ich denke wir kommen nur langsam in eine phase von avia-check wo man auch schönheitsreperaturen machen kann ;-) dazu gehört eben auch das einsparen von resourcen wenn möglich.

@newcode: missverständnis. du sagtest vorher mal das wenn ich mit renice deine prozesse auf -n 20 setze alles was sie tun damit laufen sollte. nur wenn ich das tue dann ist nur 50% der "mehrlast" durch avia-check im nice, der rest weiter bei system und user. micht wunderte auch nur der starke anstieg der last ich glaube nach der 0.94 oder so. genau um die menge welche man eben nicht nicen kann. aber viel wichtiger wäre mir das kein unnötiger reset nach dem umschalten gemacht wird. denn das stört schon gewaltig. p.s: im pes mode wurden bei mir bisher alle zwitscherer erkannt. ucode14/vb22

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)

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.

@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?

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.

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?

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.

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.

@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.

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.

@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.

... 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.

@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).

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.

@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)

@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.

@all: hab mal das enx-reset plugin angepasst für alle images die unter /bin/enxreset den enxreset liegen haben. danach braucht man die shell0-datei nicht mehr :-) nur hab ich keine ahnung wie man das hier anhängt muss ich halt beschreiben wie man es umbaut: die enxreset.so datei in einem hexeditor öffnen und nach "/var/plugins/shell0" im asc-bereich suchen. das dann durch "/bin/enxreset" ersetzen und ggf im hex-bereich mit "00" auffüllen. danach müssen nur noch die .so und .cfg nach /var/tuxbox/plugins. die shell0 wird nicht mehr benötigt. einziges problem dabei: die kiste versucht nach dem plugin was mit "/dev/input/event1" zu machen, das gibts aber nicht. hab nicht geschafft die zugehörige fehlermeldung wegzubekommen.

@newcode: hab im beta19 thread gepostet das snowhead die 0.95 einbauen soll. die 0.94 die drin ist macht bei mir etwas mucken da sie zu früh hochgezogen wird. die 0.95 läuft aber bei 10-20% last durch sie scheinbar stabil. eine frage: würde es sinn machen die 3 prozesse die laufen auf 20 zu renicen? damit hätte man die 10-20% last des daemons vollständig in der nice-prio laufen und könnte ggf somit das gesamtsystem entlasten und verhindern das andere dinge langsamer laufen. denk mal drüber nach :-) laufen tut's, hab nämlich mal manuell renice -n 20 -p pid1 pid2 pid3 abgesetzt. noch ne frage: gibt die 0.95 consolemeldungen aus? wenn ja, kannst du da [avia_check] voranstellen damit man diese einfach erkennt? und ne anmerkung: könntest du dich mit snowhead auf einen namen (avia-check bei dir, avia_check im image) einigen?