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

oder bootmanager und in die zwischenablage unter windows. oder mit telnet -f <filename mit pfad> <ipderbox>

hmm. vielleicht hilft das weiter: ab und zu hatte ich schon den effekt das z.B. beim keywelt-menüaufruf oder anderen pluginaufrufen plötzlich im hintergrund die watchdogs losgelaufen sind. ganz unabhängig voneinander sind also die einzelnen komponenten nicht.... aber das könnte das problem erklären: wenn während des suchlaufs kein bild erzeugt wird hat der avia nix zu tun, somit kommen keine interrupts => die watchdogs legen los. und das könnte dann den suchlauf stören (rumzappen während der suchlauf auch zappt ist vielleicht keine so gute idee).

@best-of-me: wenn du ein paar posts weiter oben schaust steht da die antwort. (auf die installationsfrage)

um das dann eindeutig zu kennzeichnen würde ich für die betas für neuere images dann als versionsnummer 2.00 vorschlagen. die betas könnten dann ja 2.00b1, 2.00b2, ... heissen. zum thema: bei den aktuellen images erreiche ich mit den neuen avia-treibern die da drin sind schon wesentlich bessere ergebnisse (der avia-watchdog schlägt endlich fast immer zu wenn das bild hängt!). zur zeit wird da massiv an den watchdogs im cvs gearbeitet, so das ggf bei zukünftigen images avia-check nicht mehr nötig sein wird (der avia-watchdog prüft ob weiterhin eine av und eine audio dekodierung stattfindet und macht wenn nicht einen reset auf den chip, wenn ich die funktion richtig verstanden hab). sprich: jeder sollte bei änderungen am cvs seines images mal prüfen ob es inzwischen nicht auch ohne avia-check geht. besonders diejenigen welche mit dem RC1 testen sollten das mal probieren (ist ja auch nicht viel aufwand). edit: kann mal jemand den 1. post hier abändern um die avia-check installationsanleitung für ältere images reinzustellen und den link zur v1? ggf auch die v1 in das dlc spielen? tnx

auf 0 natürlich. aus gibt es da nicht (das gt-proc ein/aus zwei darüber hat mit dem enx-reset NICHTS zu tun!). avia_check braucht den aktivierten gt-proc modus (also gt-proc auf ein), da darüber der reset des enx abgewickelt wird (wie beim enx-reset plugin auch). (sprich: das enx-reset plugin muss funktionieren, dann geht auch der avia-check). da habt ihr beim flüstern wohl stille post gespielt und einen grossteil der info verloren ;-)

die nokias gehen teilweise für 200-250 über ebay, dafür bekommt man die 600'er dreambox. und was die mehr kann? die ist neu und hat garantie und support :-) achja, und ne neuere cpu und andere nettigkeiten. aber wir sind etwas offtopic geraten :-)

interessant. da bin ich dann mal auf die weitere entwicklung gespannt. zzt scheinen die jungs ja an den avia treibern zu arbeiten, vielleicht bekommen sie das problem ja komplett in den griff. heisst für uns aber: immer auch mal ohne avia-check testen als gegenprobe.

also ich würd ja noch ein paar wochen warten bis vielleicht p* wieder zu ist. dann sinken die ebay preise wieder dramatisch *eg* und für das geld das eine nokia bei ebay kostet würd ich sowieso ne db600 kaufen. oder 100 drauflegen und ne kathi.

auf solche posts antworte ich nicht. ich bin grundsätzlich zu faul infos für andere zusammenzutragen. tsts

könnte ein interessanter hinweis sein. ist das in den aktuellen kernel schon eingebaut? wir müssen vor allem aufpassen das der avia_check und der avia_watchdog nicht irgendwann das selbe tun! besonders interessant finde ich die idee für die ursache: die watchdogs verursachen so viel verkehr das der bus überlastet wird. noch ein punkt das avia_check imho nicht "agressiv" mit resourcen umgehen sollte. interessanter thread.