wenn die Entwickler wollten könnten Sie in den Treibern viel mehr logging enabeln und auch der kernel kann wesentlich gesprächiger sein.
Aber egal, ich habe das Problem zum Glück nicht und mir steht da auch kein Urteil zu.
wenn die Entwickler wollten könnten Sie in den Treibern viel mehr logging enabeln und auch der kernel kann wesentlich gesprächiger sein.
Aber egal, ich habe das Problem zum Glück nicht und mir steht da auch kein Urteil zu.
Der Ton hier wird ja leider immer schlimmer. Aber irgendwie kann man auch verstehen warum.
Man kann beide Seiten verstehen. Allerdings erwartet man als Käufer auch ein mängelfreies Produkt.
Manche Entwickler fühlen sich hier schon manchmal sehr schnell angegriffen. Ich dachte ihr arbeitet nicht für DP. Klingt ja manchmal so wie im heise-Forum wenn Apple angegriffen wird. Wenn da DP jetzt ein nicht ganz so perfektes Gerät hat hat müsst ihr das nicht schönreden. Don't blame on the others!
Man könnte jetzt natürlich so lange die Box tauschen bis man eine bekommt die den Fehler nicht hat. Muß sicherlich nicht so oft sein, da nur einige wenige Boxen (User) diesen Fehler haben.
Ich werden meine wahrscheinlich demnächst wegen Produktmangels zurückgeben. Der Combo-Tuner ist "Schrott" im Kabel, läuft nur richtig mit einem Verstärker und keinen Interessiert es wirklich. Im Gegenteil hier wird meist geschrieben das die Kabelanlagen bei den Usern Mist sind o.ä.
Und bei dem Thema hier ist es ähnlich. Auch lese ich in letzer Zeit häufiger von toten DM900's. Aber letzteres ist wahrscheinlich eher nur eine persönliche Empfindung.
sagen wir mal so ... ich bin hier auch nur .... user ...
Und ja ich kann normal neue Ansätze schneller aushecken als Ihr Sie verwerfen könnt, aber mir ist in der Zwischenzeit meine Zeit auch oft schon zu schade und dann müsst Ihr auch verstehen wenn Leute wie Swiss und ich in den Waldorf und Statler Modus gehen
Selten so gelacht
Wenn ich mal wieder nach Wien fahre, sollten wir zusammen in's Theater gehen. Du darfst aussuchen ob du Statler oder Waldorf bist.
Auch wenn ich das Alter der beiden noch nicht ganz erreicht habe.
Nur wenn Kermit und Miss Piggy auf der Bühne stehen oder zur Not noch Fozzie Bär.
Und es geht auch nicht um das Lästern, da hätten wir besseres zu tun. Aber Biertrinken geht immer ...
Ich habe noch keine Ahnung, ob es was zu bedeutet hat...
Vielleicht hat aber jemand Lust Folgendes nachzustellen und Feedback zu geben:
Was braucht man dazu :
- Putty/SSH
- Mehrere Aufnahmen vom gleichen Sender und von unterschiedlichen Sender
Worum geht es:
Der Prozess "enigma2" hat mehrere Threads, darunter einen "gRC", der sich - zumindest bei mir - "seltsam" verhält. Seine Last variiert je nach Live-Bild oder Aufnahme in Abhängigkeit des Senders / der Aufnahme. Ein Muster habe ich noch nicht erkennen können. Mal macht er kaum was, mal läuft er dauerhaft bei rund 20-30% CPU.
Wie vorgehen:
- Putty/SSH Session öffnen.
- Mit "pidof enigma2" die Prozess-ID von enigma2 ermitteln
- Mit "top -p [pid_von_enigma]" die Überwachung starten, also bsp. "top -p 272"
Wenn "top" läuft:
- Shift-H drücken (Schaltet Thread-Anzeige ein)
- Shift-V drücken (Baum-Ansicht einschalten)
- s drücken und dann 0.3 eingeben (Setzt Aktualisierungsintervall runter)
Das Ganze sieht dann ungefähr so aus:
top - 13:17:44 up 7:53, 2 users, load average: 0.20, 0.10, 0.14
Threads: 16 total, 0 running, 16 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.5 us, 1.0 sy, 0.0 ni, 97.2 id, 0.0 wa, 0.0 hi, 1.3 si, 0.0 st
KiB Mem : 1023296 total, 458716 free, 121080 used, 443500 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 838164 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
261 root 20 0 385632 105880 26308 S 1.0 10.3 7:40.82 enigma2
294 root 20 0 385632 105880 26308 S 0.0 10.3 0:06.74 `- eLogOutput
296 root 20 0 385632 105880 26308 S 0.0 10.3 0:00.01 `- eDVBFrontend
298 root 20 0 385632 105880 26308 S 0.0 10.3 0:00.00 `- eDVBFrontend
299 root 25 5 385632 105880 26308 S 0.0 10.3 0:00.00 `- enigma2
300 root 20 0 385632 105880 26308 S 0.0 10.3 0:00.01 `- eFileMonitor
301 root 20 0 385632 105880 26308 S 0.0 10.3 0:01.62 `- QDBusConnection
302 root 20 0 385632 105880 26308 S 0.0 10.3 0:00.60 `- talloc
303 root 20 0 385632 105880 26308 S 0.0 10.3 0:00.00 `- enigma2
304 root 20 0 385632 105880 26308 S 1.3 10.3 11:00.47 `- gRC
310 root 20 0 385632 105880 26308 S 0.0 10.3 0:00.00 `- enigma2
311 root 20 0 385632 105880 26308 S 0.0 10.3 0:00.00 `- eMediaScanner
359 root 25 5 385632 105880 26308 S 0.0 10.3 0:35.79 `- enigma2
389 root 24 4 385632 105880 26308 S 0.0 10.3 0:02.61 `- eEPGCache
394 root 20 0 385632 105880 26308 S 0.0 10.3 0:00.01 `- enigma2
398 root 29 9 385632 105880 26308 S 0.0 10.3 0:26.33 `- EPGDBThread
Alles anzeigen
Schaltet man nun zwischen diversen Senden um, dann wird man feststellen, dass manche Sender zu der hohen gRC Auslastung führen, manche dagegen nicht.
Bei mir haben z.B. ARD HD und Arte HD kaum Last, ZDF HD und 3Sat HD dagegen die hohe Last.
Hier stellen sich mir die ersten Fragen:
- Warum ist das so?
- Ist das bei anderen Boxen auch so oder nur auf der DM900?
Spielt man nun Aufnahmen ab, dann wird man feststellen, dass grundsätzlich dort das gleiche Verhalten sichtbar wird.
Interessanterweise gilt das aber nicht pauschal pro Sender.
Ich habe hier z.B. zwei Cinema HD Aufnahmen, wobei eine hohe gRC-Last erzeugt, die andere dagegen nicht.
Die nächste Frage, die sich mir stellt:
- Gibt es einen Zusammenhang zwischen der hohen gRC Last und den Wiedergabe-Aussetzern? Ich muss es selbst noch beobachten.
edit: Mir ist eben aufgefallen, dass beim Live-Schauen die hohe gRC-Last irgendwann runtergeht. Bei Wiedergabe von Aufnahmen aber nicht...
Aus grc.h:
Zitat/* gRC is the singleton which controls the fifo and dispatches commands */
Da finde ich folge Info aufschlussreicher:
/*
gPainter ist die high-level version. die highlevel daten werden zu low level opcodes ueber
die gRC-queue geschickt und landen beim gDC der hardwarespezifisch ist, meist aber auf einen
gPixmap aufsetzt (und damit unbeschleunigt ist).
*/
Dennoch ist mir nicht klar, warum der Thread bei Wiedergabe - und nur bei einigen Aufnahmen - dauerhaft um die 30% Last erzeugt.
Es sollte doch an dieser Stelle keinen Unterschied machen, ob die übermittelten Daten vom Livefernsehen oder von einer Wiedergabe kommen...
edit: Übrigens bleibt selbst bei Pause die Last oben... (zumindest 'ne ganze Zeit lang)
Brav, ich würde trotzdem aber auch noch die optionen vom enigma2 -h ausprobieren
z.B. --disable-opengl einfach ins /lib/system/system/enigma2.service beim statup befehl des enigma2 binaries dazu machen und/oder --paint=async oder sysnc und da gerade wenn er das Problem hat das enigma2 auch ins log schreiben muss könnte evt. auch --disable-log-thread sinn machen mal auszuprobieren. Und da wir bei vielen der optionen nicht mal wissen was Sie wirklich bewirken kann ja mal wer auch --composition=buffered oder immediate ausprobieren
Besser als Strichlisten mit den Hängern zu machen ist es noch allemal
Hi gutemine,
doch noch eine Anmerkung von mir: Wenn Du das Problem nicht hast, dann wäre es für die Leute hier schon interessant welche Boardrevision der Box Du hast. Ich gehe schwer davon aus, dass Du eine 900er Dein Eigen nennst...
Viele Grüße
prtigger
es gibt soweit ich weis keine unterschiedlichen Boardrevisionen, wenn kommt erst mit der 920 wieder was neues, aber selbst dann wird sich an Kernel und Treibern wohl wenig ändern.
Hi gutemine,
nachschauen wäre trotzdem nett. Fotos vom Board mit Problemen wurden ja schon hier gepostet. Glauben ist nicht Wissen! Alles muss ausgeschlossen werden! Sonst kommt man nicht weiter....
Danke und viele Grüße
prtigger
das Ausschlussverfahren funktioniert aber anders - wenn du viel Zeit damit verbringst unwahrscheinliche Sachen auszuschliessen wirst du nie damit fertig
Gut, wenn die Anderen hier das auch so sehen wie Du, dann ist das halt so. Mir ist es im Prinzip egal, ich muß mich mit der 900er nicht rummschlagen... Meine Erfahrung sagt mir halt etwas Anderes...
Viele Grüße
prtigger
Nicht jedes Problem ist mein Problem, ich habe schon zu viele adoptiert.
Ich verfolge den Threat nun auch schon länger. Mich würde interessieren, wie Besitzer deutscher Marken Automobile reagieren würden, wenn einige Modelle lt. Besitzer immer wieder Zündaussetzer haben und der Hersteller meint, er soll mal loggen - der Fehler sei nicht reproduzierbar. Dann liest man die Oberschlauen in diveresen Foren, die meinen mann solle die vorgegebebenen Routinen zu ändern, quasi immer im 4. Gang bergauf fahren - mal sehen, ob die Zündaussetzer dann auch noch auftauchen. Oder gleich den Chip hacken und ein wenig an den Sourcen rumspielen, das wird schon - das ist ein reiner Bedienungsfehler
Das wird der 2. "Speicherleck möglich in dbttcd?" Threat und langsam wirklich peinlich ...
Du hast dir noch nie die da angesehen oder? *duckundweg*
https://www.youtube.com/channel/UCcnmNzv0yEEYPM6Oa86unhQ
Oha, "mein" Werkstattmensch (zumindest einer von den beiden - seine Werkstatt ist der Nähe).
Zum Vergleich von Fred:
Die Autoindustrie (ziemliche viele Mitarbeiter und quasi Endlosressourcen) und eine Firma mit -ich rate jetzt mal- drei Entwicklern miteinander zu vergleichen....nunja...hinkt irgendwie....
Aber den Eindruck den du hast verstehe ich trotzdem
You hold it wrong!
Hi zusammen,
ich lese hier schon seit einigen Monaten still und heimlich mit, da ich zwar noch keine Dreambox habe, aber mit der DM900 bzw. DM920 liebäugel.
Da ich mich beruflich viel mit Linux beschäftige und schon so einiges gesehen habe, kam mir noch eine Idee, die euch evtl. helfen könnte.
Die Aussetzer scheinen ja im Treiber bzw. Kernel aufzutreten, Plugins und vielleicht auch enigma2 selbst würde ich daher eher ausschließen und mal in Richtung Kernel schauen.
Zu meiner Idee:
Der Kernel kennt ein "tolles" Feature "Transparent Hugepages", was dazu dient, dass kleine sog. Pages (sozusagen atomare Speicherbereiche) transparent zu größeren Pages zusammengefasst werden.
Sinn ist auch, dass der Speicher hier weniger fragmentiert wird - jedoch ist mir schon gegenteiliges Verhalten aufgefallen, was dazu führt, dass der Speicher eher stärker fragmentiert.
Neben der Fragmentierung, die ggf. selbst schon zu Problemen führen könnte, läuft regelmäßig ein Defragmentierungsthread im Kernel, der kleine Speicherbereiche im Hauptspeicher sucht, die in der Anwendung zusammenhängen und diese dann zu größeren Hugepages zusammenfasst.
Dieser Vorgang könnte hier theoretisch für kleinere Aussetzer sorgen und dürfte um so häufiger auftreten, je länger die Box läuft (da die Fragmentierung steigt).
Um diese Funktion abzuschalte, gibt es zwei Möglichkeiten:
a) Im Bootloader die Option transparent_hugepage=never angeben
b) Im laufenden System:
echo never >/sys/kernel/mm/transparent_hugepage/enabled
echo never >/sys/kernel/mm/transparent_hugepage/defrag
Variante b) wirkt sich ggf. aber erst auf neue Prozesse aus... a) ist also vorzuziehen, oder man setzt b) beim Boot über ein Script.
Ich möchte jetzt nicht zu viel Hoffnung erwecken, aber einen Versuch wäre es doch sicher wert
Generell wäre es auch sinnvoll, sich den Kernel mal genauer anzuschauen, ggf. andere Versionen einzusetzen - wobei ich jetzt nicht weiß, ob das im DreamOS so einach möglich ist.
Viel Erfolg weiterhin bei der Fehlersuche