Also, e1 ist meines Wissens in C++ geschrieben - und bei e2 ist der Core in C++ geschrieben und die GUI in Python. Die beiden Teile werden dann mit Swig zusammengestöpselt.
Insofern wurde die "Komplexität" mit zwei Tunern wohl zumindest zum Teil in der selben Programmiersprache geschrieben, wie bei e1 - insofern zieht das Argument mit den "zwei Welten" nicht so wirklich...

Und der Hinweis mit der Alternative erübrigt sich ja auch - sprich ist kurz und gut am Thema vorbei.

Aber mal ganz im Ernst: Wer von denen, bei denen die Box "fehlerfrei" läuft, hat denn eine Uptime jenseits der 60 Tage? Fahrt ihr die Box häufiger in den DeepStandby? So lang man die Box jeden Abend brav in den DeepStandby schaltet, läuft die Box hier halbwegs durch - aber wenn man die mal so 20 bis 30 Tage nicht in den DeepStandby schickt, kann ich blind wetten, dass e2 sich irgendwann weghängt, bzw. so arschlangsam ist (ich Rede hier von: Druck auf die Menü-Taste <=> 140 Sekunden <=> Hauptmenü erscheint Stück für Stück), dass ich es kille (und dabei wird logischerweise kein Crashlog erzeugt, also auch nix, was ich einsenden könnte)

Na ja, die Prioritäten bei dmm sind schon etwas - sagen wir mal - "neukundenorientiert".

Ich persönlich fände es auch sehr schön, wenn endlich mal ein stabiles e2-Image rauskäme, wo auf meiner Box die Grundfunktionen laufen - und das ohne einen load von 8(!) bei nur drei laufenden FreeTV-Aufnahmen (und ohne Webbrowser oder sonstigem Schnickschnack)...

Gibt es eigentlich ne Möglichkeit, sich in einen laufenden Python-Prozess einzuklinken um mal zu schauen, wo der die ganze Prozessorzeit verbrät?

Um es zu ergänzen: Steht ein Player einmal auf der Sperrliste, verweigern alle Geärte das Zusammenspiel, d.h. kein HD-DVD Laufwerk, was einmal den Sperrcode gesehen hat, wird mit diesem Software-Player noch zusammenarbeiten, d.h. der Software-Player kann dann auch keine älteren HD_DVDs mehr abspielen.

Das ist das der Hauptkritikpunkt an HD_DVD: Wenn der eigene Player auf der Revokation-List steht, ist es nur noch ein Haufen Elektronik-Schrott.

Um das zu vermeiden sind alle HD_DVD-Geräte updatebar...

debug: Dieser "Programmteil" befindet sich auch in den Laufwerken selber und braucht daher gar nicht in Linux aufzutauchen...

Ohne da der offiziellen Antwort vorgreifen zu wollen: Die Chancen, das irgendein CA-Anbieter eine offizielle Lizenz für eine OpenSource-Box vergibt sind seeeehr gering...

Zumal der Anbieter selber ja gar nicht wünscht, dass es auf "normalen" Receivern läuft - sonst gäbe es ja ein CI-Modul...

Hm, schade, dann werde ich mal abwarten.

Ach ja: Und bei mir ist die Uhrzeit der Box noch nie falsch gewesen - insofern sehe ich für mich keinen Grund, NTP oder sowas zu implementieren...

Das Problem ist ja nicht die falsche Receiver-Zeit, sondern dass die Angaben vom EPG schlicht in der falschen Zeitzone gesendet werden. Imho gab es für sowas ne Blacklist in enigma1 - und daher die Frage, ob es sowas auch in e2 gibt.

Ich weiß, es liegt an den Leuten, die es nicht schaffen, DVB-konforme Ausstrahlungen hinzukriegen...

Auf Comedy Central ist jedenfalls der EPG verschoben, d.h. eine Stunde zu früh. Insofern die Frage: Gibt es in e2 eine Liste, wo man für Transponder eine EPG-Zeitkorrektur einstellen kann? Wenn ja, wo?

Zitat

Original von TheTob
Der Stream der DM500 ist wegen hardware spezifikationen recht ruckelig. bitcontrol bietet aber ein plugin welches das ausgleicht. Ist dem so? Oder ist die 500er ungeeignet?

Die dm500 ist eher ungeeignet - bzw. es ist wohl zufallsabhängig.

Zitat

Wieviel Traffic erzeugt ein Multicast stream?

Grundsätzlich erzeugt ein Multicast-Stream eben genau so viel Traffic wie ein Unicast-Stream. Der Multicast-Stream muss aber anders geroutet werden, d.h. sämtliche aktive LAN-Komponenten (Router, Switches) müssen explitit Multicast unterstützen. Im Home-Bereich ist das häufig nicht der Fall.
Sprich: Der (für die Box relevante) Traffic von der Box zum ersten Switch / Router ist praktisch der selbe wie bei einem Unicast-Stream. Hinter dem ersten Switch wird der Traffic dann natürlich deutlich höher, weil ja jeder Client den Stream empfangen muss.
Grundsätzlich ist Multicast aber eine relativ komplex auszusetzende Sache die sehr selten Verwendung findet - ich weiß nicht einmal, ob die Boxen das sauber unterstützen.

Imho müssten eigentlich zwei MPEG2-Decoder aus dem selben MPEG2-Stream auch die selbe Ausgabe erzeugen. (Wohingegen zwei MPEG2-Encoder aus einem Stream mit nahezu absoluter Wahrscheinlichkeit unterschiedliche MPEG2-Stream erzeugen)
Diese "Blockartefakte" deuten darauf hin, dass für die aktuelle Bildsequenz schlicht beim Enkodieren zu wenig Speicherplatz im Stream reserviert wurde.

Sehr schön sieht man das an Low-Cost-Sendern wie diversen XXX-Sendern.

Insofern: Gerade die ARD hat mal wieder an den Transpondern rumgefummelt und die Belegung geändert - dadurch könnte es sein, dass jetzt weniger Platz im Stream übrig ist und deshalb das Bild generell etwas schlechter ist. Ebenso ist es so, wie jenscz gesagt hat: Zu unterschiedlichen Zeiten kann der Platz im Stream anders aufgeteilt sein.
Dadurch kommt der Effekt, dass du meinst, das Bild hätte jetzt mehr Blockartefakte als früher.

Das Bildempfinden ist aber auch sehr subjektiv.
Nach dem Dekodieren passiert ja noch eine Menge mit der Bildinformation: Die wird ggf. noch durch einige Filter gejagt und dann in RGB verpackt - und im TV wird die aus dem RGB wieder ausgepackt, dann durch Filter gejagt (und je "moderner" der Fernseher ist (100Hz, Plasma, LCD) desto mehr Filter gibt es) und irgendwann mal dargestellt.

Das Bild zweier Receiver kann man nur im "Gesamtpaket" beurteilen: Es ist einfach so, dass das "subjektive Bild" in der einen Kombination besser ist als mit einem anderen Receiver. Das kann bei einem anderen Betrachter, einem anderen TV oder einem anderen Kabel sich aber auch schon wieder ändern.

Ach ja: Das gilt natürlich nur, wenn die BER in beiden Receivern 0 ist. Sobald die BER nicht Null ist treten ja Fehler im Stream auf - und dann ist es logisch, dass sich das Bild verschlechtert, weil es zu Dekodierungsfehlern kommen kann.

Es geht nicht mit SSH, weil der SSH-Server auf der DreamBox die dafür notwendigen Funktionen nicht vollständig implementiert.

Da beim Display jeder Punkt aber nur "an" oder "aus" sein kann sind halt die einzigen Möglichkeiten die Helligkeit und der Kontrast.

Kurzum: Das Display der 7xxx-er Reiher ist minderwertig - und keine Einstellung kann daran etwas ändern.

Man kann einzig die Schriftart und -grösse variieren. Aber das Grundproblem bleibt bestehen.

Most times this is caused by a misaligned LNB.

No / No / No

If you can't flash your DreamBox with DreamUp you should send it back to your dealer. But you shoudl really give DreamUp a try.

P.S. And of course you should use original Software from Dream Multimedia if you want help from your dealer.

Die Daten könnte man nur mit einem Spezialprogramm retten. (Wobei ich kein solches Spezialprogramm kenne) Solche Programme haben in der Regel nur Datenrettungsfirmen - und die lassen sich den Service relativ viel kosten.

Nimm Axin oder Kathrein Dosen mit einer geringen Enddämpfung. (Bei vernünftigen Shops z.B: reichelt steht die Dämpfung jeweils mit dabei)

Und halt schauen, ob es eine Durchgangsdose oder Enddose sein muss.

Offensichtlich nicht.

Wenn wir hier von einem normalen PC reden würden, würde ich dir sogar mal zustimmen. Das Problem wird auch weniger bei der Platte sondern eher im I/O System liegen.

Zitat

Original von dcdead
Bei vernünftigen Dateisystemen, wie dem bei der Dreambox genutzte ext3, spielt Fragmentierung keine Rolle.

LOL *der* ist gut. Fast so gut wie "NTFS fragmentiert nicht" Da bei ext3 das Journal sogar nur in einer normale Datei geschrieben wird hat das ja nun gar nix mit der Fragmentation zu tun.

Sobald man zwei Aufnahmen gleichzeitig macht, wird das Filesystem fragmentieren. Je mehr Aufnahmen gleichzeitig und je weniger freier Speicherplatz, desto heftiger wird dieser Effekt. (Aus diesem Grund gibt es ja auch Defragmentierungsprogramme für ext2/ext3)

Die Fragmentation kann man einzig dadurch minimieren, dass der Allokationsalgorithmus des Filesystem an den Verwendungszweck angepasst wird. Bei XFS z.B. habe ich deutlich weniger Fragmentation in einem solchen Szenario (viele Prozesse schrieben zeitgleich jeweils eine große Datei) feststellen können als mit ext3.

Der Unterschied zwischen Timeshift und normalen Abspielen ist ja letztlich, dass gezwungenermaßen jeweils auf die selbe Datei schreiben und lesend zugegriffen wird. Dadurch ergibt sich eine ganz andere Lastverteilung als beim Abspielen oder bei einer Aufnahme in jeweils eine eigene Datei.