niemand0815

man muss auch bedenken das es verschiedene zwitschertypen gibt die wohl unterschiedliche ursachen haben. wie ja vorher im thread schon mal festgestellt.

genau die ucodes welche im dezember default sind (welche auch immer das sind). einzige sonstige systemveränderung bei mir: hw sections an und vorhaltedauer für epg daten auf 2 tage (wobei beides nicht relevant sein sollte)

@jetsetter: * gt-proc im keywelt menü aktiviert (damit passende api geladen wird). * im gt-proc menü alles so lassen wie default * avia-check im keyweltmenü deaktiviert (wie default) * enx-reset plugin (also sh zum manuellen auslösen den enx resets) eingespielt, aber seitdem nicht gebraucht! * zusätze eingespielt wie gesagt, so lange wie bisher ging es noch nie ohne enxreset.

selbes mit der m*d. hatte die ganze zeit g*x parallel zu m*d laufen zwecks zwitscherverhinderung, aber seit root 1.1 geht es problemlos im singlecam-betrieb mit der m*d. bisher noch keinen hänger. ich vermute entweder ist es zufall oder irgendeine der vielen ursachen ist gefixt (ich gehe davon aus das es nicht bei allen so positiv wirkt). die frage ist nun: was hat das verursacht? was wurde seit dem novemberimage und den dezember-betas gefixt? btw: natürlich ohne aviacheck. also keinerlei "zwitscherbeeinflussende massnahmen" mehr nötig bei mir. vorgehensweise: dezember eingespielt, dann 1.1 root und zusätze. platz minimiert (plugins gelöscht) gt-proc aktiviert und enx-resetplugin (für notfälle) eingespielt. seit dem läuft es durch ohne einen zwitscherer.

also die idee von poiufdsapuroiq finde ich klingt wirklich schlüssig. ich freu mich drauf wenn newcode dazu noch was programmiert um es mal zu testen. zzt brauche ich aviacheck nicht, die wenigen resets riskiere ich gerne manuell da ansonsten dann spts jedesmal ein knacken beim umschalten kommt :-) ich verspreche mir von den oben genannten änderungen ggf eine bessere erkennung auch ohne spts.

ja, das board ist zzt echt grausam. ich hoffe das premiere bald endgültig zu macht das endlich ruhe ist und man sich über wichtigeres unterhalten kann. wenn wir noch weitere tests mit meiner sat sagem brauchen dann müssen wir langsam loslegen, bald hab ich nur noch ne kabel nokia :-(.

aber das hier ist doch eigentlich kein plugin installations hilfethread denke ich. zumal es dafür das plugin forum und den passenden enx-reset plugin thread gibt.

ich fahre immer im PES, nur diskutiere ich darüber nicht mehr .-) meine ausführungen von meiner regelkundestunde gelten also für PES, nicht spts. da seife selbst ja auch von einer "inzwischen anderen methode" redet denke ich es gibt nicht eine zweite möglichkeit das zwitschern festzustellen. irgendwie muss es ja möglich sein den hängenden sich nicht veränderndden av-datenstrom zu erkennen. vielleicht geht es ja so. oder man kann irgendwie den enx regelmäßig abfragen und im hängzustand reagiert er anders oder gar nicht mehr. wer weiss.

@newcode: das der enxreset das bild einfriert weiss ich, aber deswegen wundere ich mich wie es "etwas anderes" macht. dort sieht es irgendwie komplett anders aus, und das macht mich neugierig. vielleicht täuscht das nur, aber vielleicht finden wir in deren source (insofern wir drankommen) auch eine komplett neue methode für die symptombekämpfung. ausserdem reagiert sie ohne prozessorlast extrem viel schneller als avia-check. aber wir diskutieren das hier besser nicht mehr bis wir eine eindeutige mod-stellungnahme haben. EDIT: ich habe die frage aus dem vorherigen beitrag im hp-forum gestellt, es ist wirklich jegliche diskussion offensichtlich verboten. schade aber auch. somit beenden wir eben die diskussion. ich bitte die mods ggf meine fehlinterpretation zu entschuldigen und alle betreffenden posts zu löschen.

das sehe ich nicht so. das obige thema stellt keinerlei fragen ZUR besagten, sondern wir diskutieren darüber wie es etwas bestimmtes löst. die regel sagt eindeutig das fragen ZUR entsprechenden nicht erlaubt sind. damit ist meiner meinung nach gemeint das man nicht erklären darf wie sie zu installieren und zu betreiben ist. somit bliebe das einzig "anrüchige" an der diskussion in diesem thread das es nicht im full bereich ist. es wäre schön hierzu eine eindeutige klärung von einem moderator zu bekommen. wichtig wäre es vor allem weil ich glaube das man von der viel lernen kann. und zwar nicht wie man decrypted (das erledigt sich ja demnächst sowieso), sondern wie man die audio-videostreams so kontrolliert das sie recht stabil laufen. wie gesagt, es würde mir als "bessere" lösung eine art "pseudo camd" vorschweben welche nichts anderes tut als die chips zu überwachen. somit bräuchte man keine treiber etc. patchen und auch keine eigenen module zu schreiben. denn die bestimmte unnennbare funktioniert auch ohne gt-proc. @bahnbooster: den vorschlag finde ich gut. wir sollten aber vielleicht einfach einen gezielten thread zu jeder major-version von avia-check machen. hier kann ja im "sammel-und-diskussionsthread" immer auf den aktuellen verlinkt werden.

ich wäre dafür diesen thread in den full-bereich zu verschieben. hier im offenen würden wir sonst immer mehr in der grauzone um die regelverstösse reden. wenn wir das in den full bereich schieben dann sollte es aber ohne regelkonflikt möglich sein hier diese themen anzustossen. sie sind nun mal für die problemstellung extrem wichtig, da der auslöser für das was wir lösen wollen eigentlich genau das ist über das wir nicht reden dürfen. somit beisst sich da die katze in den schwanz. fazit für mich: diesen thread von der diskussion lösen und nur die die ergebnisse eines full-member-threads hier posten. anders geht es imho nicht weiter. und den letzten teil der regel 9 habe ich nicht gebrochen (ausser eben das dieser thread im offenen bereich ist), denn ich hatte keine frage zum tool das nicht genannt werden darf :-) sondern eine beobachtung gemacht. und mein kommentar bezog sich nicht mal darauf, sondern auf die frage wie die das wohl technisch löst. wenn man das hinbekäme ohne böse funktion wäre es ein phänomenaler gewinn für die community.

mich persönlich wundert dabei: wie macht es die g*x? m*d und g*x im parallelbetrieb sorgen dafür das seltene zwitscherer bei mir innerhalb von nicht mal einer sekunde gelöst werden. das wäre ja noch verständlich, aber die reset-methodik muss eine andere sein: wenn aviacheck resettet und aktiv wird dann geht das bild komplett weg und der ton setzt kurz aus => ist merkbar bei der g*x kommt es kurz zu kästchenbildung (wie bei schlechtem empfang) und der ton hakt kurz. das ganze ist dort aber weit weniger störend. interessant wäre bestimmt eine cam die genau diese funktion der g*x nachahmt. denn die entschlüsselung der sender geht in meinem fall definitiv nicht über die g*x, sondern über die m*d, da im "alleinbetrieb" die g*x bei mir irgendwie nichts tut :-) interessant finde ich das die g*x beim resetten kurz im ton knackt, besonders zu merken wenn man auf einen inaktiven sender schaltet. vielleicht können wir uns da ja ideen holen wie wir es besser machen können :-)

enx plugin einspielen, dann bei den plugins dafür sorgen das die blaue taste im blaue taste menü auf enxplugin zeigt (also erstes plugin in der liste). dann hast du "blau-blau" für enxreset.

meine wünsche für eine neue version: * parameter um den reset beim umschalten abschalten zu können :-) * irgendeine möglichkeit finden im pes mode zu arbeiten das mit dem umschalten beim reset ist immer, ausser man schaltet innerhalb des pausenwertes von def. 5s weiter. das mit dem zu frühen ansprechen habe ich auch, und zwar sowohl im pes als auch im spts mode. entweder merkt er früh einen sich anbahnenden zwitscherer oder reagiert unnötig. ich tendiere eher dazu an "unnötig" zu glauben. schwellwertveränderungen haben bei mir da auch wenig gebracht, komischerweise. ebenfalls resettet der avia_check bei hoher prozessorlast (z.B. beim beenden von plugins etc), was aber denke ich an dem kurzen bis langen schwarzbild beim beenden liegen kann. @newcode: mich würde mal interessieren wie das die systemtreiber in avia_av.o machen. die sollen ja angeblich den videostrom überprüfen und sobald dort nichts mehr kommt resetten. im tuxforum hab ich mal gelesen das einige das auf die prüfung des audiostreams umgeschaltet hatten und damit besseren erfolgt hatten. die frage die sich mir stellt ist: bekommen wir ein besseres ergebnis wenn wir prüfen ob das bild sich noch "bewegt"? wie könnte man so eine prüfung realisieren? denn sowohl bei zwitscherern als auch beim schwarzbild bleibt das bild ja sekundenlang stehen. ansonsten ist es doch recht ungewöhnlich wenn ein fernsehbild 1 sekunde lang ungeändert stehenbleibt, so das hier ggf auch noch ein ansatz für eine zwitscherprüfung sein könnte. alles in allem bin ich aber schon mit der 2.0 recht zufrieden (bis auf den bei mir ungewollten umschaltreset). vorschlag für zukünftige versionen bezüglich umschaltreset: wenn nach dem umschalten 5 sekunden lang keine interrupts kamen dann resetten, sonst nicht. die pause für die "umschaltschwarzbilder" ist damit genausolang, aber alle mit bild nach dem umschalten werden nicht unnötig resettet. oder eben die zapit so modifizieren das beim umschalten automatisch resettet wird.

@newcode: hab grad gesehen das im aktuellen prerelease image (oder wie nennt man die aktuellen rc's) die 2.0 deiner avia_check drin ist. wann hast du die veröffentlicht bzw was ist da neues dran? @bahnbooster: die RC3 ist kein gutes beispiel, da lief meine box auch nicht so stabil wie mit der RC2. ich hoffe die v1 ist wieder wie die RC2. probier es also immer mal wieder ohne avia_check wenn eine neue version rauskommt :-)