Zitat

Original von Littlesat
Mit diesem Image im flash habe ich probleme mit iptables... sehe hierunten.

ip_tables: Unknown symbol nf_register_sockopt
...

Dann würde ich das Kernelmodul mal gegen den aktuellen CVS Stand neu kompilieren und auch alle Abhängigkeiten mitnehmen. Ohne Netfilter (da sind die angemeckerten Symbole drin) läuft auch iptables nicht, nachdem iptables normalerweise nicht auf der Dream benötigt werden, wird das auch nicht statisch in den Kernel kompiliert.

Puh .. sitze gerade Kopfschüttelnd vor dem Thread und weiss nicht ob ich darauf anworten soll oder ob ich den einfach wegklicken soll ...

Hier wird ständig davon gesprochen das die Box instabil ist und nix funktionieren würde ... also ich hab ja nur eine einzige 7025, aber die verrichtet ihren Dienst tadellos und ich kann mich auch über Abstürze nicht beschweren. Auch funktioniert bei mir alles, ich kann fern schauen, kann aufnehmen und und und ...

Alles was so ein Receiver können muss, kann er auch und es funktioniert. Wenn es mal Probleme gibt mit ein paar komischen MP3s oder mit Ogg Dateien, muss ich sagen: Ich kauf mir dafür im regelfall auch keinen Satreceiver. Das sind coole Dinge, klar. ABer man braucht sie nicht. Es kommt auch stark darauf an wie man an so eine Box ran geht. Sicher ist für die e1 Boxen viel mehr an Plugins und Zusatzspielereien erhältlich, aber e1 ist auch schon etwas länger auf dem Markt. Zu den Anfangszeiten gab es da noch viel weniger als jetzt für e2.
Auch das es eine "Beta" ist die man beim Kunden reifen lässt kann ich so nicht stehen lassen. Enigma2 funktioniert und läuft sauber, es ist ein Satreceiver. Nehmt nicht immer irgendwelche Dinge als Referenz die mal einer für die PPC Boxen programmiert hat und die eigentlich nix mit einem Sat Receiver zu tun haben. Warum hat die Box kein xyz ... die anderen Boxen können das doch auch ist nicht wirklich eine Argumentation.

Hab den Artikel gerade mal gelesen, klint interessant. Hab mich dann auch gleich mal schlau gemacht ... das ganze hat zwei Probleme:
1.) Nur die öffentlich rechtlichen senden die Daten so
2.) Die Daten kommen nicht so sauber wie die Spezifikation gerne hätte

Daher ist der Aufwand zu implementieren sehr gross und das Ergebnis danach so, das es kein Mensch nutzt weil es nicht richtig funktioniert, da sich die Sender nicht sauber an die Spezifikation halten. Auch beim VDR (der das drin hat) werden wohl des öfteren Aufnahmen wenn das aktiviert ist nicht wie gewünscht ausgeführt.

S Steht für Sat also bei der 7020 gibt es nur eine 7020S und das i steht dafür das die INXTC Pornokarte dabei ist ... das ist auch schon alles was dahinter steckt

Hier mal ein Auszug aus der README des vdr-mhp-plugins:

Zitat

At the moment this plugin receives the files of a MHP carousel using DSM-CC protocol and saves them on disc. Future versions will likely contain the functionality to

run the downloaded java applications,
control the applications via remote control,
display their output (via OSD or MPEG-encoded stream)

Ein plugin in das mir die MHP Java Applications runterlädt und wo ablegt is nun nicht gerade das was man auf der Dreambox haben muss. Von MHP Funktionalität ist man da noch (genauso wie OpenMHP) Lichtjahre enfernt.

Zitat

Original von Dreamholger
- Rücklauf, flüssig und in der gleichen Geschwindigleit wie normale Wiedergabe (hallo SadButTrue, es geht, kannst bei mir anschauen!!)

MPEG ist ein Streaming Format und es streamt nunmal vorwärts. Wenn du rückwärts gehen willst, kannst du dir nur iFrames suchen und diese Anzeigen, da im MPEG immer mal wieder ein komplettes Bild kommt und ab da nur noch die Veränderungen und mit den Veränderungen im Vergleich zum Vorgängerbild kann man in Rückwärtsrichtung nichts anfangen. Rückwärts kann man also nur iFrames (also komplettbilder) aus dem Stream raussuchen und verwerten, das KANN so nie flüssig werden. Wenn man MPEG rückwärts flüssig haben will muss mann mit einem grossen Puffer und einem enormen Aufwand arbeiten und quasi 5 Sekunden zurückspringen dann die besagten 5 Sekunden komplett decodieren und als Vollbild ablegen und dann kann man die 5 Sekunden die man unkomprimiert hat rückwärts laufen lassen, whärend dessen muss man aber schon die davor liegenden 5 Sekunden encodieren, sonst wär das Spulen nach 5 Sekunden ja vorbei. Ein normaler MPEG Decoder Chip kann sowas nicht, müsste man also mit der normalen CPU encodieren und rückwärts abspielen, dafür ist die aber zu schwach. Ich kann mir auch nicht vorstellen das der Topfield das hinbekommt, der muss also auch die iFrames benutzen.

Im Webinterface -> Zap -> Stream -> Settings

Brauchst aber VLC 0.8.1 mit den neueren funktioniert das nicht, da die Web-Remotesteuerung im VLC sich geändert hat ...

Tedi
Das hatten wir schon geklärt, war mein Fehler mit dem Skript. Man sollte zwar os.system nicht in einem Plugin verwenden weil es das System stoppen kann, aber in dem Fall läuft das ja im Twisted, was ja schon ein extra Thread ist und daher auch keine "Gefahr" darstellt

Ist also soweit gefahrlos die WebIF Erweiterung .. bei mir haben die Alarmglocken einfach zu früh geläutet

Zitat

Original von zyklop
Boxer

Von wem wird denn das hergestellt ?!
Etwa von Dream ?! (Visoduck ?)

Nö, das hat ja Jürgen schon deutlich gesagt weiter oben.

Zitat

Original von zyklop
PS: Gibt es denn softwaretechnisch schon was, um VOB Files (DVD´s) damit problemlos abzuspielen (oder gar zu brennen !!) in der 7000 ?!

Du kannst im FileModus VOB Files abspielen, solange diese nicht geschützt sind (css), da aber so ziehmlich jede Film-DVD geschützt ist bringt dir das nicht viel. Ausserdem hast du selbst bei ungeschützten VOBs nur einen Ton auf den analogen Boxen wenn das VOB File ne PCM Audio Spur hat (also normal Stereo), wenn das VOB File (wie so oft) nur eine AC3 Tonspur hat, wird diese nur über den optischen Ausgang weitergegeben und du benötigst also eine Dolby Digital Verstärker den du auch digital (optisch) ansteuerst. Die Dream kann und darf (Lizenz-Heck und Meck) kein AC3 Signal umkonvertieren.

Da lag aber einem das Frühstück heute schwer im Magen

Nun ja, was will man dazu noch sagen ...

Die Frage mit dem Screenshot war ja auch noch offen:
Du bekommst ein sauberes Bild 1:1 vom Videodekoder ohne Komprimierung, verzerrung, etc. Die PAL Norm sieht da nunmal 702x576 Pixel vor und genau die bekommst du auch. Das 720x576 kein 4:3 sondern 5:4 sind, ist ein anderes Thema. Deswegen ist das Bild auch etwas mehr verzerrt und bei 16:9 bekommst du das anamorphe Signal, aber eben auch schön nach Norm in 720x576 (was ja 5:4 ist). Ich persönlich nimm das Bild lieber so und lass es von einer Bildbearbeitung auf 4:3 oder 16:9 umrechnen, als wenn ich von der Box schon ein umgerechnetes und somit verlustbehaftetes Bild bekomme.
Da kann man nun mal wirklich keinen Vorwurf machen, das kommt von der PAL Norm und ist keine Eigenerfindung von Dream. Ich bin mir aber sicher das die Leute schreien würden, wenn man hier einen 4:3 Screenshot bekommt der auf 720x540 (4:3) runtergerechnet wäre. Dann würde jeder nach den fehlenden Pixeln fragen, weil PAL ja 720x576 Pixel hat. Wenn du ein anamorphes 16:9 Bild korrekt umrechnen willst, brauchst du übrigens 720x405 Pixel ...

Naja, eigentlich ja "GRAB" wie "grabbing"

//EDIT
@spinatnudel
Hab mir gerade das Python angesehen. Du verwendest "os.system" um das binary aufzurufen. In dem Moment hältst du Enigma2 an, was nicht so gut ist im Hinblick auf gesetzte Timer und so weiter. Da solltest du lieber den eConsoleAppContainer() verwenden. Schau mal ins starterskript vom tuxtxt oder in eins meiner Starterskripte vom Tuxfrodo, Tuxterm oder so. Da hab ich das auch verwendet ...

So, hab wie immer mal wieder keine Lust alles zu wiederholen, daher verweis ich einfach mal auf den Thread für die anderen Boxen:

AiO Screengrabber für PPC Boxen ... Video & Grafik Screenshots

Für die 7025 funktioniert das exakt gleich. Ich habe es sogar soweit getrieben, dass es ein einziger Quelltext ist für alle Boxen. Die Schwierigkeit bei der 7025 lag (im vergleich zu den PowerPC Boxen, da war es ja die korrekte Farbpalette des OSD) beim Videobild. Es gibt auf der 7025 ja keinen V4L Treiber über den man das Videobild grabben könnte, wird es vermutlich auch nie einen geben. Nachdem mir tmbinc mal wieder mit ein paar Informationen ausgeholfen hat, hab ich es geschafft das Videobild direkt aus dem Bufferram des MPEG Dekoders zu holen und zu dekodieren, das es in YUV abgelegt ist, ist keine Überraschung, allerdings wird es da auch noch in komischen Block-rastern abgelegt, so dass man sich das Bild erstmal zusammen-puzzeln muss

Nun ja, lange Rede, kurzer Sinn: Auch auf der 7025 ein einziges Tool, das alles grabbt. Probierts einfach mal aus.

Grüsse
Seddi

So, gleich nochmal ne Version hinterher.

Diese sollte nun auch auf der 500 und 5620 funktionieren, habs allerdings bisher nur auf der 500er getestet. Bei der 500/5620 (Vulcan Chip) ist es noch etwas schwieriger an die richtigen farben des Framebuffers zu kommen, da wundert mich es nicht das der Treiber die nicht hergibt wie er eigentlich sollte. Bei dem Vulcan Chip liegt die Farbpalette im 16 Bit YUV Format vor, sprich wir müssen hier erstmal die Farben wandeln. Aber auch das ist machbar und funktioniert. Dank an tmbinc für die richtigen Tips wo und wie ich die Farbe finden kann

Weiterhin hab ich ein par Command-Switches mit reingebaut, ihr bekommt diese mit

grab -h

angezeigt. So kann man z.B. mit "grab -v" nur das Videobild speichern und mit "grab -o" nur das OSD (Framebuffer). Das kann zwar das WebIf auch, aber eben nicht mit den korrekten Farben, falls ein Plugin (wie Tuxtxt, C64, Flexmenü, etc.) läuft das eigene Farbpaletten definiert. Daher könnte das auch mal ganz nützlich sein.

Ausserdem wird nun auch das Videobild bei einer anamorphen 16:9 Übertragung korrigiert und eine Letterbox draus gemacht.

OK, hier nochmal eine Version zum testen. Inzwischen wird das Videobild (wenn nötig) sauber und bikubisch auf die 720x576 des Framebuffers hochgerechnet. Das resizing benötigt zwar ein bisschen Zeit, dafür ist das Ergebnis aber sauber.

Die DM500/5620 wird (noch) nich unterstützt, da bin ich immer noch auf der Suche nach der korrekten Farbtabelle im Speicher, da FBIOGETCMAP auch bei den Boxen die falsche Tabelle zurückliefert. Auf der 7000/7020 funktioniert das jedoch problemlos.

Zitat

Original von tomdulix
hi,

sehr cool, vor allem wenn man an skins arbeitet und diese im gesamtbild zeigen möchte!

Yep, dafür hab ichs gemacht damit man sich hierfür Windows-Tools mit Werbeeinblendungen in den Bildern sparen kann. a) arbeite ich zu 99% unter Linux und b) mag ichs nicht wenn Screenshots durch Werbezeilen verschandelt werden (sorry jungs, soll eure Leistung nicht schmälern, aber ich seh das nun mal so).

Ausserdem hat es den Vorteil das man endlich auch mal von anderen Anwendungen (Tuxtxt, Tuxwetter, Flexmenü, TuxFrodo, etc. ... ) mal ordentliche Screenies machen kann.

OK, Im not a DMM Dev, but Enigma2 the last days a lot of the config stuff has been changed. This makes it incompatible with some external tools, bit have a lot of advantages and the decision to change it was good.

The problem ist not enigma2, the problem is that dreamboxedit can not deal with the new config so far. You have to wait for a new dbedit version or ask the dreamboxedit proggers to update the software to work with the new config style.

Hi @All,

nachdem mich das screenshot erstellen auf den PPC Boxen schon lange gestört hat, haben wir hier mal ein wenig nachgeholfen.

In meinen Augen gab es bisher 2 Probleme dabei:

1.) Kein Screenshot ausserhalb Enigma
Wenn man über das Web-If einen OSD-Shot macht, hat man die Darstellung von Enigma ganz sauber, wenn man versucht eine andere Anwendung zu "fotografieren" wie z.B. den Videotext, den Tuxfrodo oder was auch immer, hat man verschobene Farben und nichts passt.
Das Problem hier ist der Grafiktreiber der Dream der im 8 Bit Modus die verwendeten Farben nicht wieder her geben kann, was ein bekanntes Problem ist. Deshalb funktionieren ja auch Tools wie fbshot nicht sauber. Dies haben wir nun umgangen indem wir direkt aus dem Haupt-RAM (/dev/mem) die Farbtabelle auslesen und nicht nur den Framebuffer abfragen, wie es jedes andere Screenshot-Tool tut.

2.) Entweder TV Screen oder Grafikscreen
Entweder macht man einen Screenshot des Fernsehbildes oder der Einblendung, sprich der Grafik. Beides auf einmal geht nicht. Auch das haben wir geändert.

Der AiO(AllInOne) Screenshooter erzeugt nun Screenshots von dem was ihr auf dem Fernseher seht, egal was ihr gerade macht. Egal ob der 16Bit Modus aktiv ist (PicViewer, Konqueror, etc.) oder der 8 Bit Modus (Enigma, Tuxtxt, Tuxfrodo usw.) ihr bekommt immer ein 24 Bit Bitmap mit korrekten Farben. Ausserdem habt ihr jedesmal auch das Fernsehbild dabei, sofern die Grafikanwendung diese nicht überdeckt. Wenn ihr mit dem AiO Screengrabber einen Screenshot macht und ihr habt gerade das Enigma Menü offen, dann seht ihr auf eurem Pic auch das Enigma Menü mit dem darunter liegenden Fernsehbild.

Das ganze ist eine einzelne Binary die irgendwo auf die Box kommt (bei 500-7000 würde sich /var/bin anbieten, bei der 7020 /usr/bin). Die Datei sollte ausführbare Rechte bekommen und schon könnt ihr per Telnet Screenshots erzeugen. Durch den aufruf von

grab

Wird einfach ein screenshot.bmp im /tmp Verzeichnis erzeugt. Alternativ könnt ihr auch:

grab /pfad/dateiname.bmp

verwenden. Somit könnt ihr den Screenshot z.B. direkt auf die Festplatte mit einem bestimmten Namen speichern.

Das Ganze sollte auf allen PPC Boxen funktionieren, da wir aber direkt auf den Hauptspeicher zugreifen und der Grafik Bereich darin immer erst erkannt werden muss und auf jeder Box anders liegt, wäre ich über Feedbacks dankbar, da ich es nicht auf allen Boxen getestet habe (nur 7020,7000). Sollte aber auch auf den "kleinen" Boxen (500,5620) keine Probleme machen.

Viel Spass damit

Seddi

//EDIT
Ok, ich hätte es auf der 500er doch testen sollen Da gibts wohl noch Probleme ...

Zitat

Original von dove_g

Hello, sorry for English language, but you can chek this software out

http://www.multimediaware.com/qv/

It plays divx in DOS on slower Penitum (150, 200MHz), so maybe it's possible on Dreambox with lot of code optimization etc... Maybe even to use MPEG2 cpu somehow :).

Alles anzeigen

Decoding DIVX on a slower "pentium" CPU is not a problem, because a Pentium CPU have an FPU (Floating Point Unit). The CPU inside the Dreambox didnt hav any FPU so it only can deal with integers and have to use a software-fpu for floating numbers, which is way too slow for decoding DIVX or something like that.

Nicht die Anzahl der Tuner ist für das PiP interessant, sondern die Anzahl der MPEG(im Falle der 8000er MPEG4/HVC) Decoder ist interessant. Man braucht pro Bild einen Decoder, der den empfangenen Mpeg2(4, etc.) Stream in ein Bild decodiert. Die 7025 hat 2 davon, also können wir auch 2 Bilder gleichzeitig ausgeben.
Dazu kommt dannn atrülich noch der Speicherbedarf, selbst wenn die DM8000 4 Decoder spendiert bekommt (was ich nicht glaube, da diese ja alle HD tauglich sein müssten und auch Geld kosten), brauch jeder Dekoder einen Grafikspeicher, der bei embedded Geschichten immer all-in-one vom normalen RAM abgezweigt wird und somit würde ein 4 Decoder/4 Bild PiP auch noch mehr RAM wegfressen. Daher würde ich mal, ohne es genau zu wissen, die wahrscheinlichkeit das dies möglich sein wird auf sehr gering einschätzen.
Alternative dazu wäre ein Softwaredecoding wie es das PiP Plugin für die alten Boxen macht und das kleine Bild in den Framebuffer schreibt. Dafür brauch man dann keinen zusätzlichen Hartdwaredecoder, aber das Ganze hängt dann natürlich stark von der Rechenleistung dre CPU ab, die ich nicht abschätzen kann, da ich noch keine 8000er in den Händen hab ...