You will not save power if your workset is fixed. If we make the GUI slower, this won't save anything, since the GUI would run a longer time at 100% CPU load than before. The only way to safe power is by limiting what work has to be done, and this is generally a good thing, regardless if we speak about power saving or not.

So, again: Playing with the cpufreq scaling, on our hardware, does exactly the same thing as inserting random usleep()s into the code. Exactly.

Right. So have any of you actually *measured* the power?

Here are the results: (Power measured at 12.00Vdc, no tuner, no HDD, no TV)

Base: 495mA
100% CPU Load: 522 mA

CPU set to lowest value: (37.5MHz):

Base: 494mA
100% CPU Load: 498 mA

The workload at 100%@37.5Mhz is about 1/8th of the workload of 100%@300Mhz.

If we interpolate the power used for 12.5% at 300MHZ:

495 + (522-495)/8 = 498.75 mA

Which is exactly the same power required as when the cpu is set to 37.5Mhz. Or we can extrapolate the power for 800% cpu load at 37.5 MHz:

494 + (498 - 494) * 8 = 526mA.

(Note that I couldn't measure with sub-mA accuracy, so there will be some rounding errors.)

Bottom line: The idle loop does exactly the same power saving as a hardcoded scaling value. Nothing to gain, here, the box will automatically save power even when not using the cpufreq interface.

AC3+ ist leider wirklich eine Spezialität von diesen Sendern, und daher zunächst einmal von uns nicht vorgesehen gewesen. Da allerdings nun der Bedarf da ist, werden wir uns um eine Lösung kümmern.

Wir sind uns des Problems bewusst. Allerdings dauert es leider immer ewig, diese Lizenzgeschichten zu klären, so dass wir leider noch keine Aussage darüber treffen können, wie eine Lösung aussieht wird.

Ja, das geht irgendwie über zig ecken, und scheinbar geht die Hälfte dabei verloren.

Also, der Entwickler darf sich gerne mal per Mail bei mir melden (felix.domke@multimedia-labs.de).

Yes, it's part of all recent experimental builds for dm800, and will be used for all new release candidates (and releases) too.

The reason why we are not supporting 8PSK is simply that available hardware so far was either limited to 8PSK *or* DVB-S2. We'll see if that changes in the future. Of course we are interested in supporting the NA market, but the european market remains our priority for now, simply because we know the requirements of this market. That doesn't mean that we don't want to support the NA market, it just means that we have to carefully look at those markets to see what kind of requirements they have, and if our hardware and software is able to support that.

Regarding the vtuner-interface, this is still in beta-phase, thus we are not officially supporting it. In case anyone has problems with it, feel free to write me a mail, but it's not yet a feature that is mature enough that it will be supported officially.

Also, der ARD/ZDF-Test-Sender ist ja synchron. Ich will einmal kategorisch ausschließen, dass das Delay so groß ist, dass es wieder passt. Dazu passt es auch immer und reproduzierbar viel zu exakt.

Dann gibt es die Premiere-typischen 160ms Tonversatz. Das ist ein bisher ungelöstes Problem, da keiner weiss, woher Original-Premiereboxen wissen, wann sie das Bild entsprechend verzögern müssen. Für Hinweise wäre ich dankbar. Im Etsi en 300468 AC3_Descriptor ist zumindest kein offensichtlicher Eintrag.

Und dann gibt es noch den schlicht "unsynchronen" Fall, bei dem irgendwas kaputt ist - sei es dass der Sender überhaupt kein vernünftiges PTS (oder PCR) sendet (wie es zunächst bei dem HD-Test der Fall war), oder dass unsere Treiber was falsch machen. Dann ist das Delay variabel, deutlich größer als 200ms und ändert sich z.b.,

Den Ton früher kommen lassen geht im Treiber nicht, aber man kann das Bild verzögern, was dann ja den gleichen effekt hat: in /proc/stb/vmpeg/0/pts_offset findet sich der Wert. Wenn ihr dort "3840" (=90000*.160 in hex) reinschreibt, dann kompensiert das das "premiere problem". Haken ist halt, dass dieses Delay nicht immer notwendig ist, sondern nur bei einigen Sendungen.

Was das "Audio Delay" in diesem Media-Info-programm genau ist, weiss ich auch nicht. Ich vermute mal, dass es einfach die Verzögerung im Datenstream ist. Die ist aber völlig egal, die Synchronisierung wird ausschließlich mittels den PTS-Werten gemacht.

Ist nun gefixt.

Aber bitte: Entferne doch einfach die falschen/doppelten Einträge aus der sat.xml. Es kann ja nur einer der beiden Einträge gültig sein. Es gibt leider viel zu viele schlechte satellites.xml, die unnötige Einträge enthalten; oft stehen einfach nur alle Frequenzen in allen Variationen drin. Das führt beim Scan nur zu Problemen, weil Transponder möglicherweise doppelt gescannt werden, und je nachdem wie nah die Parameter wirklich sind möglicherweise auch zweimal gefunden werden. Ausserdem nimmt natürlich die Suchdauer stark zu, insbesondere wenn Transponder nicht tunebar sind.

Versucht bitte, die Sat.xml so schlank wie möglich zu halten. Einträge, die de facto auf Transponder verweisen, die es nicht gibt, oder die schon in der Liste vorhanden sind, sind unnötig und haben keinen positiven Effekt.

It looks like some issues are mixed together here.

As I already said, there is a problem with certain data combinations. This doesn't affect "normal" functionality of the DM7025, and thus, fixing it is not our highest priority, which doesn't mean that we ignore the problem. We simply don't have a fix yet. I'm really sorry for this.

The DM800HD is based on completely different hardware, and does not have this problem. Same for DM7020 and all other dreambox hardware.

Then, some people seem to have problem talking with smartcards on various hardware. I don't know much about smartcards, but if you can pinpoint a problem, please send me a mail with the details, and I'll try to forward it to other developers. Experience shows that most of these problems are related to a misunderstanding of the SCI api. But again, I don't know much about smartcards. In any case, it's not related to the demux bug.

Then some of you described a "freezing" - what do you mean exactly with that?

Achso, zusätlich dazu gibts die "Kapitelmarken". Diese sind einfach nur Markierungen, die man bei der Wiedergabe mit < und > anspringen kann, und beim Brennen auf DVD auch als Kapitelmarke übernommen werden.

Also, es gibt 4 Funktionen:

a.) "Vor dieser Position entfernen" ist, denke ich, eindeutig. Alles was davor ist, wird halt "entfernt" (siehe unten was "entfernt" genau heisst).
b.) "Nach dieser Position entfernen" genauso, nur eben bis zum ende.

c.) "Schnitt hier starten" setzt den Startpunkt für einen Bereich, der entfernt werden soll. Z.b. am Anfang der Werbung.
d.) "Schnitt endet hier" setzt den Endpunkt für einen Bereich, der entfernt werden soll.

c.) und d.) machen nur zusammen Sinn. Also, als Beispiel einen Film mit Werbung:

- Man springt, am besten im Pause-Modus, zum Filmanfang. Am besten benutzt man zuerst die Zahlen 7/9, um die grobe Position zu finden, dann 4/6 um es genauer zu machen, dann 1/3, dann links/rechts. Damit sollte man recht schnell den Anfang sehr genau finden, wesentlich schneller als mit schnellem Vorlauf o.ä.
- Man drückt "OK", wählt "Vor dieser Position entfernen". Damit beginnt der Film nun an dieser Stelle, Werbung usw. vor dem Film fehlt also.

- Man springt, am besten wieder mit Hilfe der Zahlentasten, zum Anfang des ersten Werbeblockes, wählt "Schnitt hier starten". Zunächst passiert nichts, nur dass der Anfang nun markiert ist.
- Man springt zum Ende des Werbeblockes, und wählt "Schnitt endet hier". Nun wird der Werbeblock, was man auch visuell sieht, nicht mehr angezeigt.

- Die letzten zwei Schritte wiederholt man für jeden Werbeblock

- Man springt ans Ende des Filmes, und wählt "Nach dieser Position entfernen"

Herausgeschnitten wird übrigens immer nur virtuell - die Daten selbst bleiben auf der Festplatte erhalten. Sie werden aber bei der Wiedergabe und beim Brennen einer DVD berücksichtigt. Wer auch die Daten selbst loswerden will (was sich allerdings in den seltensten Fällen lohnt), dem sei das "Moviecut"-Plugin nahegelegt.

Ich hoffe, das macht die Sache ein wenig klarer :).

Ah, freut mich dass es nun klappt :).

Das liegt am falschen mount in /etc/fstab, dadurch wird die festplatte nachher an der falschen stelle gesucht. Ich habs mal im OE verändert, muss aber nochmal getestet werden.

Sollte also bald wieder funktionieren

Wir sind uns des Problems bewusst, und arbeiten dran.

eigentlich nicht, aber kann gut sein dass die änderung das gleiche bringt.

Ich mag meine Aussage selbst nicht, aber wir müssten das eh mal auf twisted.web umstellen, und dann erledigt sich das problem hoffentlich.

Mit dem Tunermanagement hat das keinen Deut zu tun, ich denke dass ist eher der uralte twisted.web2-Bug.

Dummerweise find ich den patch nicht mehr, aber es war wohl in twisted/web2/client/http.py, connectionLost.

Ich arbeite mal dran. Sorry dass der Fix irgendwie untergegangen ist.

Wenn jemand den Fix noch findet, bitte mal als Diff hier posten.

Nun, zappen ist erstmal nicht drin. Die Daten werden ja direkt vom Transport-Interface zum Decoder geschoben. Man kommt dem am naechsten, wenn man die Daten durch das PVR-Device schiebt, was natuerlich ein bisschen enigma2-Voodoo vorraussetzt, damit bei den "nicht-nativen"-Frontends dann die entsprechende Quelle gewaehlt wird. Ausserdem geht dann kein Playback mehr, weil der PVR-Channel ja belegt ist.

Aaalso, prinzipiell spricht nichts dagegen (ausser irgendwelche Verschwoerungstheorien abseits der Realitaet ;). Enigma kennt z.b. auch keine Demuxe, die nicht an beliebige Frontends gekoppelt werden koennen. Dazu wird demux0 immer fuer die Videowiedergabe benutzt (weil das bei einigen Hardwareplattformen der einzige Demux ist, der die dazu benoetigten Features mitbringen, wie hardware-PCR-Korrektur usw.) Wie ist denn das bei euch aktuell geloest? Prioritaetenhandling gibts in enigma2 aber.

Also, mit "ein paar Zeilen E2-Code" ist die Sache leider nicht getan, unmoeglich ist sie aber auch nicht.

Sorry, ja, hatte ich ueberlesen.

So, neuer Treiber mit heutigen Datum ist oben. Ich hoffe, nun stimmt alles

okay, getan

Die DACs am Ausgang laufen eben NICHT Pixelsynchron. Das hat man vor ewigkeiten mal abgeschafft, als man DACs bauen wollte, die mehrere Normen können, ohne riesige, umschaltbare analoge Filter dahinter bauen zu müssen (ihr wisst schon, Aliasing und Oversampling usw.).

Der DAC im Xilleon läuft daher immer mit einer (relativ) festen Rate, hat ein definierten digitales Filter (dessen koeffizienten man dann halt umschaltet), so dass das Signal am Ende dem Standard entspricht. Für die feste DAC-Rate gibts dann ein festes anloges Filter, um hier das Aliasing zu vermeiden. Durch die hohe Frequenz nach dem Oversampling kommts hier auch nicht auf Details draufan. Würde der DAC mit 13.5MHz laufen, wäre es schon enorm schwer, aliasing zu verhindern, und trotzdem die volle PAL-Bandbreite zu ermöglichen. Und mal eben ein anderes Format ausgeben wäre dann unmöglich.

Bei PAL gibt es keine scharfen Kanten - das entspräche ja einer unendlichen Bandbreite, und man hätte eher einen Sender als einen PAL-Ausgang gebaut, und würde durch jede EMV-Prüfung fallen.

In sofern wird jede Zeile auf diese ~3500 Pixel "aufgeblasen" (genauer: 12*Fsc, mit Fsc=4.43MHz subcarrier freq., danach wird nochmal hochskaliert um auf die DAC-Ausgabefrequenz zu kommen, die, meine ich, bei ~148.5MS/s liegt), und dann so am DAC ausgegeben. Woher sollte hier ein Qualitätsverlust kommen? Höchstens durch schlechte Oversampling-Filter, aber die sind schon sehr massiv. Ist ja im digitalen nicht weiter teuer. Das Argument "jede Bildbearbeitung verringert die Qualität" ist natürlich grundsätzlich nicht falsch. Aber eine simple Skalierung ist dann doch recht gut durchzuführen, auch in Echtzeit. Die Filter arbeiten mit ausreichender Genauigkeit (was bei 8bit Eingangsdaten ja auch nicht so DIE Kunst ist), und haben meist 10 Taps (der finale Filter, der die letztendlich ausgegebene Bandbreite begrenzt, noch mehr). Wesentlich mehr Qualität dürfte im analogen Kabeln und bei den ADCs verloren gehen, wo jedes Bit richtig Geld kostet.

Wesentlich mehr Qualität geht ausserdem bei jeglicher Framerateanpassung verloren. Aber das ist ja nicht das Thema hier.

Nein, ist nicht bekannt :). Wenn du details weisst, schreib sie am besten hier hin.