Momentan können zwei Sendungen nur dann parallel aufgenommen werden, wenn sie *nicht* auf einem Transponder liegen.

Das wird aber hoffentlich bald besser.

Im Flash sind - vom Flashhersteller - defekte Blöcke als "defekt" markiert. Das ist bei Flashroms in der Größe/Bauart so üblich (die Flashes sind daher auch immer nen bisschen größer als der "Nominalwert").

Scheinbar ist in deinem Flash ein Sektor defekt, aber nicht als solcher markiert.

Ich schick dir per PM gleich mal was zu was du ausprobieren kannst,

Wenn dir das alles zu blöd ist, kannst du die Box auch als defekt zurückschicken, dann kümmern wir uns drum. Ist definitiv was wofür du nichts kannst und was eigentlich nicht hätte passieren sollen.

Das Dreamup ist aktuell?

Gabs das Problem schon immer?

Es scheint so, als ob ein Flash-Sektor falsch markiert wäre.

ja, oder man bringt vorgestern eine HDTV Box, die kein HDTV kann.

Nun, die Frage ist ob einige hundert tausend bis millionen vorhandene Set-Top-Boxen den minimalen Vorteil der Bandbreite wieder aufwiegen. (Bisher nutzen 90% der Transponder nichtmal statistisches Multiplexing, womit man enorm Bandbreite sparen könnte - und da wären "nur" neue Encoder nötig).

Sicherlich, wenn man neue STBs verkaufen will schon, aber bei Providern, die Boxen an Kunden vermieten?

Daneben steht Amerika und Halb-Europa (welches nur aus Testsendern besteht), welches HDTV-MPEG2 macht. Und ein einziger Provider mit MPEG4 (ProSieben, Sat1 zähle ich da einfach mal dazu. Das ist doch nicht mehr als ein Werbegag)

Ahja? Dann erzähl mir mal wo man STV0399s a.) überhaupt kriegt, und b.) die auch länger als ein paar Monate funktionieren (alternative Lösungen, sofern erhältlich und nicht nur angekündigt, nehm ich auch gerne!), erzähl mir mal wo man stand-alone MPEG4 Decoder bekommt, die nicht nur mit einer Gurken-CPU funktionieren,

erzähle mir weiterhin, wie die Rechtslage von HDMI, insbesondere HDCP und OpenSource aussieht,

erzähle mir, wie man legal DVDs (egal ob HD oder nicht) mit OpenSource-Software anzeigen kann,

erzähle mir, ob MPEG4 sich auch ausserhalb Deutschland durchsetzen wird.

Aber ich vergaß,
du bist ja allwissend.

(Weiterhin hat der freundliche Saturn-Mitarbeiter nur den Kopf geschüttelt, als ich die Humax Box kaufen wollte, die da ausgestellt war. Aber das ist wohl nur ein temporäres Problem.)

nein, und bei der schlechten verfügbarkeit von mpeg4 dekodierlösungen, bei der prinzipiellen unsicherheit über HD-content auf DVD/whatever wäre das wohl auch nicht angebracht.

"Kaffe kochen" kann die 7025 ja ausserdem schon (fast)...

Cool Hätten wir das auch geklärt.

Also, der STV hat eine Signalbandbreite von 10MHz. Damit ist gerade noch Progressive möglich (also 480p / 576p), mehr nicht.

Greift man das Signal davor ab, wäre theoretisch mehr drin, bis 1080i über YUV.

VGA ist schon eher ein Problem, weil sich Hsync und Vsync leider nicht ordentlich abgreifen lassen. Doof, aber wahr.

Es ist momentan nur PAL und NTSC möglich, NTSC auch erst seit kurzem. Die anderen YUV-Modes kann ich leider nicht ausprobieren, da ich kein YUV-Gerät hab, was das kann.

Nutzen tut das momentan aber eh nichts: Wenn man progressive ausgeben will, braucht man ein vernünftiges Deinterlacing. Das ist ein Haufen Arbeit, und ist so ziemlich null dokumentiert. Es gibt nichtmal Sample-Code dazu.

Selbst wenn man also momentan auf eine höhere Auflösung schalten würde (was, wie gesagt, momentan nicht geht), kommt nur die Hälfte der vertikalen Auflösung bei raus.

casi: Mir wäre nicht bewusst, dass du mehr von der DM8000 wüsstest, als der durchschnittliche Forenleser.

Warum verkneifst du dir deine pseudo-technischen Kommentare nicht einfach, wenn du keine Ahnung hast?

(Wir werden wohl kaum einen DVD Brenner einbauen wenn man nicht in der Lage ist, damit DVDs zu brennen, die man hinterher auch anschauen kann.)

Was macht eigentlich deine nicht-Linux box?

Dass der Xilleon ein wenig wärmer als der Pallas wird, hat sicherlich niemand bestritten, und ist glaube ich auch nie das Diskussionsthema oder gar ein Problem gewesen.

Dass das Netzteil relativ heiss wird, darüber gibt es einen langen Thread. Das müssen wir hier nicht wieder "aufkochen". Die Temperaturen sind ausserdem im erlaubten Bereich, und der Stromverbrauch ist nicht höher als bei der 7020 (es sei denn, man misst falsch).

Natürlich werden wir uns darum kümmern, das Netzteil in Zukunft kälter zu bekommen, sofern das möglich ist. Fakt ist aber dass das Netzteil aktuell kein kritisches Problem darstellt. Es könnte optimaler sein, sicher. Und wenn nach einem halben Jahr tatsächlich die Netzteile anfangen auszufallen, haben wir als Firma damit ein sehr viel größeres Problem als der einzelne User. Wir sind also schon daran interessiert (auch wenn das anscheinend allgemein bezweifelt wird), Hardware zu verkaufen die so lange wie möglich hält.

Operator:
Getrennt rausführen ist wiederrum nicht so einfach, aufgrund der notwendigen Termination (die Signale wären dann am Ende entweder doppelt terminiert, oder im nicht-YUV-Falle garnicht. Beides wäre schlecht.)

Integrale: Hast du mal einen Link zu dem Adapter? Ich hab den da nicht gefunden. Wenn dieser Adapter mit einer nicht-umgebauten DM7025 problemlos funktioniert, wäre das ein triftiger Grund, das Feature "freizuschalten" (wie gesagt, per telnet kann das jeder jetzt schon ausprobieren).

Ich denke wer mit einer nicht-umgebauten 7000er (oder noch besser 7020er, denn da ist die Beschaltung wirklich identisch) keine Probleme hat, bei dem wird auch eine 7025 keine Probleme machen.

Der Framebuffer auf dem Xilleon kann leider kein 8bit auf dem Framebuffer. Find ich auch schade.

Erm, yes.

1.) i've already wrote the reason in the other thread why we don't produce an .nfi file (jffs2 garbage collection would be required). If you have a good plan, i'm of course willing to implement that.

2.) this should work with recent secondstage loaders. Just put the kernel cmdline after the filename, seperated with a space.

3.) do you know some simple USB code, which can speak OHCI and usb-storage? I only found some ports of the linux usb stack...

We'll commit soon again, sorry for the delay. We have to sort out some things, and we didn't wanted to make things more complicated than they needed to.

NEIN, die Hardware kann es nicht.

Bzw., sie kann es wie die 7000er/7020er, nämlich nicht ordentlich. Genauer gesagt müssen wieder die drei Kondensatoren getauscht werden, was dann abseits der Spezifikation des Scartswitch-ICs ist. Um die RGB-Pegel "nicht zu gefährden", wurde beschlossen, die Beschaltung wie im Referenzdatenblatt zu lassen. (Ob das Sinnvoll war oder nicht ist eine andere Frage, die mit einem einfachen "das ist aber doof" leider nicht geklärt werden kann. Wer Lust hat, die einzelnen Pegel und Beschaltungen einmal durchzusimulieren, kann uns gerne Beweisen, dass eine Benutzung der "YUV-geeigneten"-Kondensatoren bei RGB keinen Nachteil bringt. Die Erkenntnis, dass das "bei meinem TV aber problemlos geht", hilft hier nicht wirklich weiter.)

Daher meine Frage, wer gesagt hat, YUV würde gehen. Es stimmt so definitiv nicht, und die Aussage, dass es funktioniert, bringt uns dann wieder in arge Bedrängnis! Es ist mit Absicht kein Feature, was auf dem Karton steht.

(Ob es einen Hack gibt/geben wird, mit dem YUV dann doch geht, ist völlig nebensächlich, wenn es um "offiziell unterstützte Features" geht.)

Um dem ganzen dann doch nochmal einen technischen Abschluss zu geben:

a.) Ja, der Xilleon kann YUV ausgeben. das passende "echo yuv > /proc/stb/avs/0/colorformat" ist hier schon gefallen.

b.) Die AC-Kopplungskondensatoren machen das YUV-Signal kaputt (kann mir nebenbei jemand erklären, wie AC-Kopplung bei YUV überhaupt funktionieren soll? Wie lässt sich eine komplett rotes Bild von einem komplett blauen Bild unterscheiden, wenn der DC-Anteil der Farbinformationen in beiden Fällen 0 ist?)

c.) Ich gehe davon aus das wenn man das Signal entweder vor den passenden Kondensatoren abgreift, oder sie - ähnlich wie bei den anderen Boxen - umrüstet, ein ordentliches Bild bei rauskommt. Anhand der Pins am STV6412 sollten die sich schnell identifizieren lassen, sind dort an Pin 10, 12, 14 direkt in Reihe.

Wenn man das Signal vorher abgreift, stört vermutlich die doppelte Terminierung...

d.) Dabei geht die Garantie verloren. Zumindest wenn man so lötet, dass man es nachher sieht

e.) Wer YUV dringend benötigt, muss vom Kauf der Box - mit bisheriger Hardware - leider Abstand nehmen, es sei denn, er will löten.

f.) Ja, eigentlich sollte man dem Support vertrauen können. Warum hier die Kommunikation schiefgegangen ist, weiss ich auch nicht.

Wow, great.

You all now officially found the reason why we never made a backup tool, and/or let the 2ndstage loader produce .nfi files with that "backup" option. It just doesn't work without optimizing the jffs2 filesystem afterwards, to keep a number of blocks left in the case of bad blocks. If the jffs2 isn't filled up, you can just skip blocks, but if it is, then you need to do a garbage collection. And that's stuff you really don't want to do inside a second stage loader, because it's basically what mkfs.jffs2 does.

Anyway,

if you screwed up your badblock information (anything more than ~5 bad blocks is definitely not normal, though i don't know the exact numbers guaranteed by samsung etc.), you've lost some information which can't be retrieved. The badblock information is stored at production, and there is no test to reveal if a specific block is bad or not.

One method is of course to erase (and rewrite) a block and check if the erase didn't fail. If it failed, its a bad block for sure (and you just did an illegal operation, as the specification say that you should NEVER attempt to erase a bad block!). If it succeeded, well, then it's undefined. It could be a bad block, but it's probably not.

The next version of the secondstage loader will contain a mode to recover your bad block list. I always wished we could avoid this (as it's out of specs to even touch bad sectors), but now it seems required. Should be in the next version, until that, you have to live with your ~600kb less flash.

The reason for the re-layout was to give more space for the kernel, as the mips kernel doesn't have an integrated gunzip, and the jffs2 doesn't give such a good compression ratio because of the relative small blocksize. Plus some more space for bootlogos was quite nice, and some flashes had a bad block in the secondstage area, which got quite tight with some new features.

Next, the secondstage loader has hardcoded partition sizes (my stupid "marker" thing never really worked out...). So it has to match.

Also in enigma2 seh ich da keine Auswahlmöglichkeit.

in video/videomode_choices gibts auch jede menge HDTV auflösungen, funktionieren tun die deswegen auch nicht.

in /media/ gibts auch einen mmc-slot, existieren tut der deswegen auch nicht.

you can try http://tmb.elitedvb.net/dm7025_20060206.nfi, but that's just an more-or-less inofficial image i've built.

No, they just don't sell to people using open/free software. If it would be just about paying some money, we would support everything available, but the usual compliance rules require completely closed systems. No Network access to HDD, no own programs.

Ich behaupte ganz unverbindlich, dass das nicht mehr allzulange dauert (vielleicht 1-2Monate).

Ob das stimmt? Das werden wir in 1-2 Monaten sehen

Huch? Wer von Dream hat gesagt, dass die 7025 YUV unterstützt?

Das ist - zumindest momentan - nicht richtig.