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.

Zitat von gutemine

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.

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

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)

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

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

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

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