[Pollin] MOTOROLA VIP1710

Ich bin auch immer an Erfahrungsberichten interessiert. Allerdings ist mir mittlerweile klar, dass ich das Kommunikationsschema ändern muss: Bei den UDP-Sockets, die ich derzeit nutze, um die MPEG-Pakete an den Vendor-Softwarestack zu übergeben, habe ich keinen Anhaltspunkt dafür, wann der Puffer in besagtem Softwarestack voll ist und damit ab welchem Zeitpunkt der Puffer schlicht überläuft. Da muss ich wohl auf etwas Stream-basiertes umstellen (TCP oder Unix Domain Stream Sockets, die kann die VIP1710 auch, aber beides nur im Client-Betrieb). Bei der Wiedergabe von Aufnahme spuckt VDR damit den Datenstrom der Aufnahme ohne Unterbrechung direkt aus, da streckt die Streamwiedergabe irgendwann bloß die Hände nach oben und nimmt nicht wirklich mehr was an.

Derzeit frickele ich eine client-Bibliothek für den IPC-Mechanismus des Vendorstacks zusammen. Damit lässt sich theoretisch zum einen die Steuerarbeit übernehmen, die "toish" macht, zum anderen lässt sich damit wesentlich kleinteiliger (soll heißen: PID-Auswahl, Stop, möglicherweise Ffwd/Rew, Lautstärke etc.) die Streamwiedergabe steuern. Ist aber viel trial&error. Aber sieht doch sehr machbar aus.

Das beides verbandelt könnte doch noch ein ganz akzeptables Ergebnis bringen...

Zitat

Original von Hawhill
Derzeit frickele ich eine client-Bibliothek für den IPC-Mechanismus des Vendorstacks zusammen. Damit lässt sich theoretisch zum einen die Steuerarbeit übernehmen, die "toish" macht, zum anderen lässt sich damit wesentlich kleinteiliger (soll heißen: PID-Auswahl, Stop, möglicherweise Ffwd/Rew, Lautstärke etc.) die Streamwiedergabe steuern.

Hätte man dazu nicht auch die libtois.so benutzen können? Zumindest für die Steuerung.

Ansonsten wäre die client-Lib ein echter Meilenstein

Zitat

Original von Hawhill
Ich bin auch immer an Erfahrungsberichten interessiert.

Wäre ja auch gern dabei, aber bei mir liegen die Dinger noch rum ... auch weil ja vorher darum gebeten wurde, die Füße noch etwas still zu halten.

Eine Sache, die ich noch nicht komplett geblickt habe:
Einmal war die Rede davon, dass es 1:0 für die Kreatel-Box stehen würde und dann war hier vor kurzem wieder die Rede von der Box mit dem Flash. Auf welche der drei Boxtypen beziehen sich Deine - mehr als bemerkenswerten - Fortschritte? Wenn ich irgendwas überlesen haben sollte, ziehe ich hier gleich mal vorsichtshalber den Kopf ein...

Ehrlich gesagt trenne ich im Kopf bisher nicht nach Mit-Flash und Ohne-Flash bzw. Kreatel oder Motorola. Allerdings setzt die Lösung, wie ich sie derzeit benutze, darauf, dass Flash da ist - einfach um ein paar Autostart-Sachen zu machen. Ich kann auch nicht ohne Flash testen, da meine beiden Boxen welchen haben. Softwaremäßig müsste alles auch ohne Flash laufen, dazu müsste aber - ähnlich dem "motorola.sh"-Skript, das andere für ihre Lösung gestrickt haben - am besten noch ein Skript her, dass die Sachen in ein Live-System pumpt. Oder vielleicht auch ein entsprechendes per NFS ausgeliefertes root-FS oder so, aber wie gesagt fehlt mir da die Möglichkeit, mal näher nachzuforschen.

Also wer wirklich nicht selber unbedingt viel basteln will, braucht die jetzige Lösung nicht ausprobieren (es sei denn, sie/er will einfach nur TV damit gucken). Ist eher für Bastel-Interessierte. Mit Aufnahmen sollte das auch irgendwann funktionieren, aber dann sag' ich natürlich (oder gern auch wer anderes, der's zum Laufen bekommt) noch mal bescheid.

Kurz zur Sache, weshalb ich nicht die mitgelieferte libtoi.so benutze: Ich hab' den Quellcode und damit leider auch die Header nicht. Und es ist ne C++-Bibliothek, deshalb war mir das Header-Raten zu komplex. Gemessen daran, wie einfach die IPC-Messages aufgebaut sind, ist es einfacher, das zu reimplementieren. Außerdem könnte noch eine Art Zugriffskontrolle in der libtoi.so versteckt sein. Will ich mich nicht mit herumschlagen.

Hawhill

Meinen grössten Respekt für die Arbeit, die Du geleistet hast. Das Bild von der kleinen VIP1710 ist an meinem alten Röhrenfernseher um Längen besser als das der SMT (i810 auch directfb).

Ich hatte versucht, das alte softdevice Plugin zu nutzen. Dachte mit directfb bräuchte man sonst keinerlei Treiber, sourcen oder ähnliches. Leider konnte directfb nicht genügend Speicher freimachen und ist umgehend abgeschmiert. MPlayer mit directfb hatte ich auch mal übersetzt, leider ein völlig verschobenes, s/w Bild mit einer Auslastung von 100%.

Mir ist wirklich schleierhaft wie Du die Thematik mit directfb gelöst hast, es funktioniert einfach nur gut. vdr liegt bei 10% Auslastung - die XBOX360 remote funktioniert bestens am lirc.

Werd mal versuchen mit vdr-1.7.15 zu übersetzen....

Gruss

Stefan

stevie: fein
Nee, also via softdevice wird das (so einfach) nichts. DirectFB nutze ich nur für das OSD, da die Set-Top-Box das per Hardware über das Videobild mischen kann. Es gibt aber nicht etwa ein MPEG-Decoder-Interface in DirectFB, das direkt mit der Box umgehen könnte. D.h. die Videostream-Wiedergabe läuft über den Software-Stack, der mit der Box kommt (insbes. Prozess "streamer"). Und genau an dieser Schnittstelle muss ich noch feilen, damit das mit Aufnahmen klappt.
Für VDR 1.7.x war ich zu faul, da schon wieder neuere DVB-Header nötig wären, als ich gerade da hatte. Eigentlich sollte es aber nicht problematisch sein, da einfach ein paar aktuelle für zu nehmen -- schließlich wird damit ja eh keine Hardware bzw. kein (DVB-)Kerneltreiber angesprochen. Um VDR 1.7.x würde ich mich sonst frühestens kümmern, wenn das Plugin etwas runder läuft.

@lola

Zitat

magst Du vielleicht einen kleinen "Mutti-Zettel" schreiben, für diejenigen welche sich noch garnicht mit dem Thema befasst haben, aber vielleicht Interesse hätten/bekommen würden.

Na ja, würde wirklich gern mehr beitragen (zu vdr insgesamt), aber seitdem ich neben meinem 50std Job noch Familie und Haus habe, ist das kostbarste und limitierteste Zeit. Das Thema ist wirklich hochinteressant, vor allem, da es dank Hans-Werners bereitgestellter Pakete einfach ist zu testen und selbst einiges zu kompilieren.

Hawhill
da sieht man deutlich den Unterschied zwischen einem Profi und einem ambitionierten Amateur (trotz etlichen Jahren Linux im privaten Bereich).
Wenn ich Dich richtig verstehe, teilt das plugin OSD und MPEG stream - reicht den MPEG stream an "streamer" und legt das OSD per DirectFB über darüber. Ist es richtig, dass "toish" die Schnittstelle zu streamer und/oder halserver darstellt ?
Meine channels.conf enthielt ursprünglich noch die HD channels von ARD/ZDF. Konnten natürlich nicht dargestellt werden, aber auch keine anderen Kanäle danach mehr. Nur interessehalber, hatte irgendwo gelesen, die Box könnte 720p, ist da was dran ?
vdr-1.7.15 ist logischer nicht notwendig, sollte aber wie Du sagst auch kein Problem sein und macht erst Sinn, wenn Aufnahmen abspielbar sind.

Hoffentlich finde ich am WE ein bischen Zeit zum spielen...

Gruss
Stefan

stevie101: Genau so wie du's beschreibst. Perspektivisch wohl ohne "toish", da ich das problemlos selbst implementieren kann (der IPC-Aufruf zum Starten einer Streamwiedergabe ist sehr simpel gestrickt). Zu teilen gibt's eigentlich auch nicht viel, da VDR OSD und Videodaten ohnehin gesondert verwaltet.

Tja, hier und da tauchen bei der Software der Box zwar die magischen vier Buchstaben "HDTV" auf, allerdings glaube ich kaum, dass hier Hoffnung besteht. Wäre das überhaupt via Scart-RGB/FBAS/S-Video zu übertragen? Die Hardware-Plattform unterstützt zwar das Anbinden eines DVI/HDMI-Transceivers, aber ein solcher ist meines Wissens nicht auf dem Board.

Ansonsten für diejenigen, die sich auch für die IPC-Strukturen der Box interessieren: Ich hab' mal ein Tool gebastelt, das via LD_PRELOAD die entsprechenden Aufrufe abfängt und mitloggt. Dazu ein entsprechendes Dump-Programm. Zu finden im "sockdump"-Archiv auf http://hilses.de/vip1710/. Im Ergebnis sieht man damit, was die Programme so für Daten austauschen und wie sie bestimmte Softwarefunktionen - wie zB. das Starten der Streamwiedergabe - ansprechen. Daneben bastele ich gerade an einem Lua-basierten (da ich mit Lua schneller prototypen kann) Tool bzw. einer Lua-Bibliothek, die diese IPC-Funktionen nachbastelt. Das veröffentliche ich wohl auch noch im Laufe des Abends. Mit den Erkenntnissen aus dieser Bastelei werd' ich mich dann demnächst mal noch mal an das VDR-Plugin setzen.

Zitat

Original von Hawhill
Ansonsten für diejenigen, die sich auch für die IPC-Strukturen der Box interessieren: Ich hab' mal ein Tool gebastelt, das via LD_PRELOAD die entsprechenden Aufrufe abfängt und mitloggt.

Wirst Du diese Strukturen auch dokumentieren? Zumindest die wichtigsten.

Hi, ja, das mache ich ganz bestimmt. Ich werde in wenigen Tagen meinen Resturlaub aus 2009 zu verbrauchen haben und bei diesem miesen Wetter bietet sich es geradezu an, da mit der 5-Euro-Kiste rumzuspielen

Ich baue derzeit aus meinen Erkenntnissen Prototypes für die IPC-Messages die verschickt werden. Ich baue quasi die libtoi.so einmal nach. Ist natürlich an vielen Stellen auch etwas Raten dabei. Das ist schon ziemlich strukturiert und ich werde es wohl recht einfach in rein textuelle Beschreibungen umbauen können. Wie oben schon versprochen gibt es daneben auch bald diesen Code.

So weit ich das jetzt schon absehen kann, lässt sich damit insbesondere die Streamwiedergabe (aufbauend auf dem Vendor-Softwarestack) recht gut steuern (Start, Stop, Forward/Rewind, Springen an bestimmte Stelle). Ist aber noch nicht ganz in trockenen Tüchern. Außerdem läßt sich anhand der Struktur auch gut nachvollziehen, welcher Prozess welche Aufgaben hat.

Hawhill

übergibt's Du irgendwelche options beim Kompilieren von vdr und den plugins ?
Bei mir ist es march=4kc und -03.
Ich hab das Problem, dass mein selbstkompilierter vdr einfach nicht sauber den stream darstellt. Das passiert bei vdr-1.6.0 und auch vdr-1.7.15, Artefakte bis zum schwarzen Bild. Egal ob gestripped oder nicht.
Leider gibt es kein Log vom vdr auf der Box, daher kann ich nur raten.
Die Version von Dir funktioniert einwandfrei.

Gruss
Stefan

Ergänzung zu meinem Problem mit dem streamdev-client:

Sep 16 14:34:29 192 local6.err vdr: [403] LIRC remote control thread started (pid=403, tid=403)
Sep 16 14:34:29 192 local6.err vdr: [138] streamdev-client: socketpair(SOCK_SEQPACKET) failed: Socket type not supported, try ing SOCK_DGRAM Sep 16 14:34:29 192 local6.err vdr: [404] TS buffer on device 1 thread started (pid=404, tid=404) Sep 16 14:34:29 192 local6.err vdr: [405] streamdev-client: sections assembler thread started (pid=405, tid=405) Sep 16 14:34:29 192 local6.err vdr: [406] TS buffer on device 10 thread started (pid=406, tid=406) Sep 16 14:34:29 192 local6.err vdr: [407] receiver on device 10 thread started (pid=407, tid=407) Sep 16 14:34:29 192 local6.err vdr: [138] OSD size changed to 720x576 @ 1 Sep 16 14:34:31 192 local6.err vdr: [402] streamdev-client: socketpair(SOCK_SEQPACKET) failed: Socket type not supported, try ing SOCK_DGRAM Sep 16 14:34:31 192 local6.err vdr: [402] streamdev-client: socketpair(SOCK_SEQPACKET) failed: Socket type not supported, try ing SOCK_DGRAM Sep 16 14:34:31 192 local6.err vdr: [402] streamdev-client: socketpair(SOCK_SEQPACKET) failed: Socket type not supported, try ing SOCK_DGRAM Sep 16 14:34:32 192 local6.err vdr: [402] streamdev-client: socketpair(SOCK_SEQPACKET) failed: Socket type not supported, try ing SOCK_DGRAM Sep 16 14:34:32 192 local6.err vdr: [402] streamdev-client: socketpair(SOCK_SEQPACKET) failed: Socket type not supported, try ing SOCK_DGRAM Sep 16 14:34:33 192 local6.err vdr: [402] streamdev-client: socketpair(SOCK_SEQPACKET) failed: Socket type not supported, try ing SOCK_DGRAM Sep 16 14:34:33 192 local6.err vdr: [402] streamdev-client: socketpair(SOCK_SEQPACKET) failed: Socket type not supported, try ing SOCK_DGRAM Sep 16 14:34:33 192 local6.err vdr: [402] streamdev-client: socketpair(SOCK_SEQPACKET) failed: Socket type not supported, try ing SOCK_DGRAM Sep 16 14:34:34 192 local6.err vdr: [402] streamdev-client: socketpair(SOCK_SEQPACKET) failed: Socket type not supported, try ing SOCK_DGRAM Sep 16 14:34:34 192 local6.err vdr: [402] streamdev-client: socketpair(SOCK_SEQPACKET) failed: Socket type not supported, try ing SOCK_DGRAM Sep 16 14:34:34 192 local6.err vdr: [402] streamdev-client: socketpair(SOCK_SEQPACKET) failed: Socket type not supported, try ing SOCK_DGRAM Sep 16 14:34:35 192 local6.err vdr: [402] streamdev-client: socketpair(SOCK_SEQPACKET) failed: Socket type not supported, try ing SOCK_DGRAM Sep 16 14:34:35 192 local6.err vdr: [402] streamdev-client: socketpair(SOCK_SEQPACKET) failed: Socket type not supported, try ing SOCK_DGRAM Sep 16 14:34:35 192 local6.err vdr: [402] streamdev-client: socketpair(SOCK_SEQPACKET) failed: Socket type not supported, try ing SOCK_DGRAM Sep 16 14:34:36 192 local6.err vdr: [402] streamdev-client: socketpair(SOCK_SEQPACKET) failed: Socket type not supported, try

ich kompilier' normalerweise nie was mit "-O3". Zuviele Knieschüsse, jedenfalls mit älteren GCCs. Statt "-march=4kc" nehme ich normalerweise "-march=mips32r2 -msoft-float". Beim VDR allerdings hab' ich das glaube ich beim "-O2" ohne weitere Angaben belassen, so wie geliefert.

Die "SOCK_SEQPACKET"-Sachen hab' ich bisher nie gesehen.

Allerdings: Artefakte? Das hört sich nach unvollständig ankommendem Stream an. Entweder schon vom Server her, oder aber aber dann auf der Box. Hast du dem "streamer"-Prozess via /etc/streamer_conf.xml etwas mehr Puffer gegeben? Bei mir müssen es mindestens so 500ms sein. Und das muss in der Datei stehen _bevor_ der Streamer-Prozess gestartet wird... Eine WLAN-Strecke zwischen Box und VDR-Server ist auch immer problematisch, glaube ich.

Naja, am Wochenende werd' ich wohl die Plugin-Umstellung auf Unix-Domain-Stream-Sockets machen (statt derzeit die UDP-Geschichte, bei der mich diese Symptome ehrlich gesagt nicht sehr wundern). Meine IPC-Anstrengungen sind jetzt schon so weit fortgeschritten, dass ich mit eigener Software den "tv"-Prozess replizieren kann und dadurch kein X und keinen Browser mehr brauche und Streamwiedergabe, -stopp initiieren und Lautstärke ändern kann.

Zitat

Original von Hawhill
Meine IPC-Anstrengungen sind jetzt schon so weit fortgeschritten, dass ich mit eigener Software den "tv"-Prozess replizieren kann und dadurch kein X und keinen Browser mehr brauche und Streamwiedergabe, -stopp initiieren und Lautstärke ändern kann.

Na, das hört sich doch schon fast nach einer VDR-Firmware für die Box an!?

Zitat

Original von lola

naja, momentan sind es noch 1198 Stück - wir werden sehen

Gruß Fr@nk

Hab grad nochmal geprüft, noch 1196 Stück da. Also nur 2 Stück in der zwischenzeit verkauft.

Fernbedienungen noch 817 Stück und Netzteile hat Pollin noch 1191 Stück.

Mein Warenkorb derzeit: 13.522,77 €, inkl Verpackungspauschale von 113,97 €

Zitat

Allerdings: Artefakte? Das hört sich nach unvollständig ankommendem Stream an. Entweder schon vom Server her, oder aber aber dann auf der Box. Hast du dem "streamer"-Prozess via /etc/streamer_conf.xml etwas mehr Puffer gegeben? Bei mir müssen es mindestens so 500ms sein. Und das muss in der Datei stehen _bevor_ der Streamer-Prozess gestartet wird... Eine WLAN-Strecke zwischen Box und VDR-Server ist auch immer problematisch, glaube ich.

Den streamer puffer hab ich auch mal auf 800 erhöht - keine Besserung. Geht alles über LAN.
Diese Meldung im log ist auch mit Deinen kompilierten Paketen vorhanden, das kann es also nicht sein. Interessant ist nur, dass es mit denen von Dir bis auf ARD channels (da bleibt manchmal das Bild stehen) gut funzt, mit selbstkompilierten ist es nicht verwendbar.

Zitat

Naja, am Wochenende werd' ich wohl die Plugin-Umstellung auf Unix-Domain-Stream-Sockets machen (statt derzeit die UDP-Geschichte, bei der mich diese Symptome ehrlich gesagt nicht sehr wundern). Meine IPC-Anstrengungen sind jetzt schon so weit fortgeschritten, dass ich mit eigener Software den "tv"-Prozess replizieren kann und dadurch kein X und keinen Browser mehr brauche und Streamwiedergabe, -stopp initiieren und Lautstärke ändern kann.

Na da freu ich mich, das ganze nach unserem Urlaub ausprobieren zu dürfen.

Übrigens, da ich mediatomb auf der Box laufen hab, ist ca. 7Mbit/s Datendurchsatz bei einer externen USB Platte das Maximum oder geht bei euch mehr ?

Gruss

Stefan

Zitat

Original von Marcus 2208
Na, das hört sich doch schon fast nach einer VDR-Firmware für die Box an!?

Dumm ist nur, dass ohne Hardware-Mod nur signierte Kernel gebootet werden können, also erst mal nix VDR-Firmware.

Der Bootloader der vip enthält GPL Code von etherboot. Das open7x0-Team hat bei Motorola schon angefragt, wegen dem fehlenden Bootloader Sourcecode:

https://opensource.motorola.co…general_comments.topc2071

Mit dem Sourcecode besteht evtl. die Möglichkeit die Signatur zu umgehen.

Moin,

wie sieht es eigentlich mit den Boot- und Umschaltzeiten bei der VIP aus?

Meine Holde beschwert sich ueber die "lange" Startzeit bei einem (allerdings auch aelteren) PC-basierten VDR, so dass ich nach Alternativen als Streaming-Client suche.

Oder generell - wie schaut's, wenn der Streamhost weg ist und der Client weiterlaeuft? Reconnected er automatisch?

Gruss

/elle