Meine inoffizielle Meinung als Entwickler:

Hey, meint ihr, WIR (bzw. unser Verkauf) würden nicht gerne schon seit Jahren einen exakten Termin kennen, zu dem wir die 8k verkaufen können? Meint ihr nicht, wir hätten die gerne schon seit 2 Jahren auf dem Markt, als es noch keine andere HD-Box gab?

Während der 8k-Entwicklung ist uns klargeworden, dass man, selbst wenn man sich noch so sicher fühlt, niemals vor Überraschungen geschützt ist - diese Überraschungen waren letztendlich der Grund, warum wir immer wieder dies und jenes umschmeissen mussten, weil wir es dringend verbessern wollten. Ein bekanntgegebener Termin hätte doch überhaupt keine Aussagekraft, das sollten alle beteiligten (also auch die Kunden) in den letzten Jahren (muss man mittlerweilse ja schon sagen) erkannt haben.

In sofern gibt es kein WANN, sondern nur ein WARUM. Und das hat nichts mit mangelnden MPEG4-Lizenzen (oder was so durch andere Foren geisterte) zu tun, sondern schlichtweg damit, dass die 8k ein (hardwaretechnisch) furchtbar komplexes Gerät ist. Und bei Hardware kann man nicht mal eben ein neues Image installieren - die muss so, wie sie verkauft wird, auch funktionieren.

Der Vorteil liegt aber auch auf der Hand: Wäre die 8k vor zwei Jahren rausgekommen, wäre sie damals technisch aktuell gewesen. Kommt sie jetzt, wird sie heute aktuell sein. Wir haben z.b. SATA-2, eine schnellere CPU, SATA fürs optische Laufwerk, schnelleren (und mehr) RAM, mehr Flash usw.

Oh, and could you please a.) document your exact diseqc setup (maybe some ascii art diagram?) and b.) post your /etc/enigma2/settings here? (or send me an email to tmbinc@elitedvb.net)

in 99% of all cases, "SID not found in PAT" is a *disqec* problem. It happens when you tune to a transponder, the diseqc position is not switched properly, and the zigzag will tune to a wrong transponder with otherwise identical parameters - just on the wrong satellite/band. The error is caused by the transponder not containing the service which should be tuned (because it's the wrong transponder).

You are right, the SDT update will corrupt the channellist in this problem. But let's try to fix the root problem: the non-working diseqc.

please try various tone_amplitude settings. Do they help?

Vielen Dank fuer eure Arbeit!

Ich hab die Werte von dandjo (21c,d29,2f,26f) mal in den treiber uebernommen und einen neuen gebaut (datum: 20080526, ipkg gibts erst nachher).

adenin:

Müsstest du nicht auf CVBS triggern, aber dann z.b. noch 'R' anzeigen?

CVBS wird sich nicht ändern, wenn man zwischen RGB und CVBS wechselt. Das interessante ist doch der unterschied zwischen den Informationen im CVBS und denen vom RGB (dessen sync ja weiter CVBS ist)..

Rafiki:

Das ist doch nicht das Problem. Wir haben einen DVB-{S,C,T}-Modulator, aber man kann die MPEG-Daten ja nun auch einfacher anzeigen.

Die aktuellen Werte sind, messtechnisch, doch okay. Trotzdem ist das Bild nicht mittig.

Wir haben das DM7025-Videosignal auch mal nachmessen lassen. Ausser einem damals kaputten Farbträger (das haben wir gefixt) kamen da keine Anomalien raus.

Natürlich messen wir nach, was aus dem Video-Port kommt.

dandjo: Vergiss am besten mal alles, was früher war. Der aktuelle Wert sollte dafür sorgen, dass das MPEG-Bild an Zeile 23 beginnt. Darüber besteht doch einigkeit, dass dies so korrekt ist, oder? Der Overscan wird ja mitgesendet, die Zeilen also 1:1 ausgegeben werden.

Ich verschieb das Bild gerne, wohin immer ihr wollt. Aber ich möchte zumindest eine messtechnische Erklärung hören, warum es aktuell falsch ist.

Die ursprünglichen ATI-Werte sind

+ .h_start = 538,
+ .h_end = 3371,
+ .v_start = 39,
+ .v_end = 615,

gewesen.

Der DM800-DVB-S2 Tuner hat ein paar Power-Management-Funktionen, die so erst unterstützt werden müssen.

Zu kaufen gibts die Tuner nicht einzeln. Bitte wartet mit entsprechenden Umbauversuchen auch ab, bis der unterstützt wird. Vorher hats eh kein Sinn, und ausserdem verbraucht der Tuner an einigen Spannungen wesentlich mehr Strom (z.b. im LDPC-Mode), so dass man erst die kompatibilität mit der dm7025 sicherstellen muss.

Gut, bin ich nicht der einzige, der verwirrt ist

Interessant ist folgendes: Aus den Tabellen, die ich für den Videomode-Setup verwendet habe (die übrigens so direkt von Ati stammten), war zunächst (für v_start) 45 (=0x2D, was hier ja im Forum als "mittig" angesehen wird) eingetragen. Allerdings sollte ein 1:1-Scaling der Zeilen beibehalten werden, daraufhin hab ich das auf 21 (=0x15) angepasst, was natürlich viel zu hoch war. Vermutlich bin ich drauf reingefallen, dass sich das nicht direkt auf die Zeilennummer bezieht.

Dann hab ich irgendwann, und da bin ich mir sehr sicher, Zeile 1 des MPEG-Bildes auf Zeile 23 des CVBS-Bildes verschoben, was ja *die* Referenz sein sollte (nicht umsonst enthält diese ja oft die WSS-Halbzeile). Daher kommt die aktuelle 39 (=0x27). Das alles war aber bereits vor dem Erscheinungstermin der 7025, es gab also niemals Images mit anderen Werten.

Dem gegenüber steht natürlich die unumstoßliche Aussage, dass das Bild einfach nicht mittig ist. Es aber, laut Scope, sein sollte. (Die eine RGB<->CVBS-Zeile sei mal egal).

dandjo: die horizontalen Werte sind, da bin ich mir sehr sicher, nicht im Bezug auf Bildpunkte zu sehen. Der Videogenerator im Xilleon läuft mit einer hohen Frequenz, grob ca. 53MHz (das ist nochmal abhängig vom Videomode). h_total sind 3404, in diesen sind dann die 702 PAL-Spalten zu positionieren. Aktuell hätten wir dann 53.2us active video, für 720 pixel allerdings. Für 702 Pixel wären das 51.93us. Standard wären, je nach Norm (das ist nirgends exakt geregelt), 52us (z.b. 702/13.5MHz, wenn wir im digitalen bleiben). In sofern ist das Bild eher minimal (~0.1%, d.h. unter einem echten Pixel) zu klein. Für echte 52.0us wären also (3404 / 64us*52us *720/702)=2836.6 "Xilleon-Pixel" korrekt, also z.b. 538..3374 oder 536..3372. Sieht das wer?

Also, das Problem ist, dass intern erstmal YUV erzeugt wird, und dass dann im Ausgabepfad einmal nach CVBS und einmal nach RGB gewandelt wird - *nach* allem Scaling etc.

Dabei hat CVBS eine Latenzzeit durch den Kammfilter, scheinbar von zwei Zeilen. Ich werd nochmal einmal schauen, ob es möglich ist, RGB entsprechend zu verzögern, Solange nehmt bitte erstmal CVBS als referenz.

Könnt ihr euch auf pal_*_{start,end}-Werte einigen? Die vertikale Einheit sind einfach Zeilen, die Horizontale waren irgendwie 4*Farbträgerfrequenz. Ich kann das gerne in die Treiber entsprechend einbauen. Ich bräuchte nur Werte, die erwiesenermaßen korrekter als die aktuellen sind.

Ab einer gewissen Ablage brauchst du aber Zigzag, die Bandbreite zwischen Tuner und Demod ist ja auch nur endlich. Und das können durchaus einige MHz sein. Da leidet irgendwann die Qualität dann schon, wenn "hinten" was fehlt. Du sagst ja selbst, dass der PLL-Chip die vorselektierung machen sollte. Die CX-Firmware, in Verbindung mit einem CX-Tuner, kann halt den Tuner "passend" mitziehen. Wenn man z.b. den Derotator entsprechend mitzieht, macht das ja nicht so viel. Ihr habt bestimmt auch nicht so billige LNBs wie die meisten User

Wie dem auch sei - wir behalten natürlich den Markt im Auge. Sobald sich herausstellt, dass ein anderes Frontend signifikant besser ist, werden wir natürlich unsere Überlegung überdenken.

pepo83: Die "Schlechtwetterreseve" hat, wie Olove schon richtig gesagt hat, damit nichts zu tun. Die Empfangsleistung des BSBE2 ist ähnlich gut wie ein BSBE1, und - im subjektiven Vergleich - anderen Boxen.

Bogoll: Es geht um ziemliche Feinheiten beim verwendet Chip auf dem Tuner. Ich denke, mit dem BSBE2 haben wir eine recht gute Wahl getroffen. adenin sieht das anders, das ist sein gutes Recht, aber ich stehe durchaus zu unserer Wahl. Das heisst nicht, dass es in Zukunft vielleicht nicht irgendwann nochmal andere Tuner geben wird, aber momentan haben wir uns, aus wie ich finde guten Gründen, für den BSBE2 entschieden.

Kein Tuner ist das gelbe vom Ei, egal was dir erzählt wird. Bei vernünftiger Ansteuerung ist der Unterschied aber wesentlich geringer, als einem oft suggeriert wird. Beispielsweise verbrauchen DVB-S2-Tuner, durch die LDPC-Dekodierung, wesentlich mehr Strom als ein DVB-S-Tuner. In ein paar Jahren mag das nicht mehr weiter auffallen, aber zwischen der Einführung von DVB-S1 und -S2 liegen mal >10 Jahre, die an Erfahrung erstmal aufgeholt werden müssen.

adenin:
Nun, abgesehen davon, dass der STB0899 bereits abgekündigt ist, sehe ich Demods mit integriertem Controller sehr positiv. Das ist ja bei vielen anderen Demods (TDA10046 z.b.) nicht anders. Unsere Erfahrungen mit dem (vergleichsweise simplen) STV0299 zeigen, dass man eigentlich nur mit den vom Hersteller vorgegebenen Tuning-Algorithmen eine Chance hat, die angebene Performance auch zu erreichen. Gerade der STV0299-Code damals war aber so schlecht geschrieben, dass er unter Linux nicht mal eben so nutzbar wäre. Es hat ewig gedauert, bis der Kernel-Treiber da qualitätsmässig herankam. Ausserdem kann ein integrierter Mikrocontroller in Echtzeit nachregeln, das Zigzag z.b. ist wesentlich präziser als man es von aussen jemals tun könnte.

Ausserdem hat man etwas in der Hand, wenn etwas nicht funktioniert. ST den Kernel-Demod-Treiber zu zeigen, bringt überhaupt nichts. Man wird sofort auf deren Referenz-Software (die damals noch für DOS war) verwiesen. Benutzt man eine Firmware, lässt sich ein Fehlverhalten ja relativ leicht dokumentieren. Der Support bei Alps bzw. Conexant ist auch sehr gut, im Gegensatz zu dem, was wir mit ST erlebt haben.

Die Lock-Zeiten des CX sind eigentlich prima. Auf normalen Sendern (DVB-S,27500,3/4) ist lock schon nach <75ms da, mit auto-FEC und auto-inversion. Ist dein Tuner da viel schneller? Für Low-SR kann ich das gerne nochmal einzelnd ausmessen, um einen vernünftigen Vergleich zu haben, sollten wir uns aber auf feste Parameter einigen.

Der Tuner benötigt ca. 1dB mehr an SNR als ein BSBE1 mit STV0288. Das finde ich durchaus vertretbar, wobei sich das evtl. sogar noch verbessert hat, ich müsste die Messung nochmal mit einem finalen Tuner wiederholen.

*Können* tut der Demod ja auch niedrigere Symbolraten. Die Frage ist, ob er die Kanäle ordentlich trennen kann. Und da möchte ich bezweifeln, dass andere Direct-Conversion-Tuner da wesentlich besser sind. Ich hab leider keine Schüssel auf Hellas2 gerichtet. Vielleicht könnte man mal einen Test auf Türksat durchführen? Dort hat man ja auch genug Symbolraten zur Auswahl Wichtig wäre jedenfalls, im gleichen Spektrum zu testen - ein einzelner Low-SR-Sender ist kein Problem, aber mehrere, in wenigen MHz Abstand, sehr wohl.

Ja, hat es, eine relativ massive sogar.

Es gibt weiterhin die Begrenzung der minimalen Symbolrate auf 4000kSymb/s (die ist aber durch den Conexant-Demod so gegeben), wobei einige Sender darunter auch funktionieren. Irgendwo unter ~3300 ist aber wirklich Schluss.

Let's say, it's a release candidate. If there are no major bugs, it will become a release without further changes.

It was automatically forwarded into the online update, I'm sorry for that. But it seems to work reasonable well, so that's fine.

The missing media player is a bug. In the meantime, it can be installed with the plugin list.

Passiert das auch bei NTSC?

Was für ein Samsung LCD?

Das Problem ist, das aktuell Screens nur bei der erstellung die Skindaten verwenden um dan die eWidgets zu konfigurieren.

Bei einem Skinwechsel wären also zuerst mal nur neue Fenster betroffen. Abhilft schafft evtl. der "skin reload" patch, den ich für skin-scaling (auflösungswechsel on the fly, macht z.b. im picture viewer oder im testbildviewer sinn) eh brauche.

Allerdings ist das noch ein wenig komplizierter, denn ein neuer skin kann ja andere renderer und dummy widgets haben als der alte. Diese müsste man also auch korrekt neu erstellen.

Spätestens die Infobar kann man auch nicht einfach schliessen und neu öffnen (als user).

Hi,

Es gibt ein neues Release-Image für die DM7025, allerdings bisher noch in der Beta-Phase:

http://dreamboxupdate.com/open…ages/release_20080501.nfi

Es entspricht damit dem Stand, der auch für die DM800 verwendet wird. Aktuell gibt es noch kein Changelog, da muss sich nochmal jemand die Mühe machen, allen CVS-Änderungen zu folgen.

Ok, ich hab dann das Blau hoffentlich auch noch gefixt. (gleiche url)

Schaut aber mal bitte, ob es sonst keine Farbverfälschungen gibt.

Danke, ich schau's mir an!

Rodajo: That's great to hear! Yes, we fixed the zigzag code a bit.

Ich hab mal einen neuen Treiber gebaut, in dem die Farben (hoffentlich) passend begrenzt werden, so dass dieser Bug nicht mehr auftrutt. Vielen Dank für das Test-Video!

Ich bin der Meinung, dass der Bug auftritt, wenn der RGB-Farbraum verlassen wird. Der YCbCr-Farbraum deckt sich ja nicht 100%ig mit dem RGB.

Wie dem auch sei, wer mag, kann ja mal den heutigen Treiber ausprobieren:

ipkg install http://dreamboxupdate.com/opendreambox/1.5/dm7025/experimental/dreambox-dvb-modules_2.6.12.6-20080430-gcc4.1-r0_dm7025.ipk

Ouch, seems like the stupid providers didn't even read the DVB specs.

We will work on a workaround.