[Pollin] MOTOROLA VIP1710

So, ich habe jetzt eine neue Version (mittlerweile 0.1.1) fertig. Die erlaubt auch die Wiedergabe von Aufnahmen - allerdings noch kein Vor-/Zurückspulen. Springen geht aber.

Außerdem kann das Plugin nun die Lautstärke setzen, Stummschalten und auch das Wide-Screen-Signal ("16:9-Schaltspannung") am Scartausgang schalten.

Es funktioniert jetzt ganz ohne X und das "tv"-Frontend, so dass noch etwas mehr RAM zur Verfügung steht. Es benutzt die "libvipipcstack", die ich - jetzt doch in C - geschrieben habe und die Kommunikation mit dem IPC-Stack der Box erlaubt. Libvipipcstack ist mitsamt der Dokumentation des IPC-Mechanismus der Box (und einer Grobbeschreibung der Softwarekomponenten auf der Box) hier zu finden: http://hilses.de/vip1710/libvipipcstack/

Nach wie vor baut die Minidistribution - immer noch unter http://hilses.de/vip1710/ zu haben - auf VDR 1.6.0 auf. Ich werde mich demnächst mal an VDR 1.7.x versuchen.

Ich hab' jetzt - wo auch die Aufnahmen funktionieren - mal ein CIFS-Modul und das entsprechende Mount-utility mit aufgenommen, da es ja jetzt interessant wird, das /mnt/video-Verzeichnis vom VDR-Server einzubinden.

Leider ist das alles wohl noch nicht ganz der Weisheit letzter Schluss -- ich bekomme hier und da manchmal Aussetzer. Woran die genau liegen muss ich erst noch untersuchen. Insgesamt gefällt mir der Fortschritt aber so gut, dass ich das schon mal so veröffentliche. Die Version, die ich dann wirklich für benutzbar halte, wird dann irgendwann die 0.2.0, denke ich. Das runvdr.sh-Script ist ein wenig angepasst, so dass VDR jetzt bei einem "restart" auch wirklich neu gestartet wird.

Ich hab' hier bestimmt noch irgendwas vergessen, also fragt ggf. gern nach. Und ich freue mich über jeden, der sich den Source vornimmt, nur so nebenbei....

Zum Thema Start- und Umschaltzeiten: Da ist sicher noch einiges 'rauszuholen (jedenfalls bei der Startzeit, für die Umschaltzeit muss ich sehen, ob ich das überhaupt beeinflussen kann) und bisher kein Blumenpott mit zu gewinnen. Startzeit wohl so ca. 90s und Umschaltzeit würd ich sagen etwa 3-3,5s.

Das Bild hat - so weit ich das beurteilen kann - eine ganz ordentliche Qualität. Das Wide-Screen-Signalling macht da tatsächlich einen gewissen Unterschied.

Edit2: Jetzt Version 0.1.1. Bei mir gibt es noch alle 8-15 Minuten einen 2s-Aussetzer. Der liegt wohl leider aber an der Software der Box, da geht plötzlich ein Prozess flöten. Ich hab' noch nicht wirklich herausgefunden, warum. Ist aber, da der Fall sauber abgefangen wird, jetzt eigentlich ziemlich benutzbar. Das plugrc-Skript ist etwas optimiert, so dass der VDR wirklich startet, sobald es geht. Damit kommen wir, wenn ich richtig gemessen habe, aber trotzdem über knapp 90s.

Nur kurz als Update: Viel stabiler wird's erstmal nicht. Ich weiß immer noch nicht, woran es liegt, dass es die kurzen Aussetzer gibt, aber das Verhalten stabilisiert sich dann, nachdem es 2-3 Aussetzer gegeben hat. Es liegt wohl nicht am Videostream - jedenfalls triggern Wiedergaben das Problem nicht.
Generell ist bei mir der Stream aber schon verdammt stabil.
Bei VDR 1.7.16 bin ich auch schon recht weit, nur geht mir da gerade das geänderte Verhalten beim Schreiben in transfer.c auf den Zeiger. Naja, wird nicht so'n Ding sein und geht für Live-TV schon ganz gut, nur für Wiedergaben muss ich da noch mal ran. Das zeigt übrigens das gleiche Aussetzer-Verhalten.

Ich kann mir vorstellen, dass es an der Zeitsynchronisation/ntpd liegt. Die startet immer mit einer Justier-Phase und das ist hier u.U. problematisch. Wohlgemerkt tauchen die Probleme auch auf, wenn kein ntpd läuft. Ich nehme sogar sicher an, dass der laufen muss - und zwar so früh wie möglich auch so genau wie möglich.

Hawhill
So konnte mittlerweile das neue Konzept ausprobieren.
Es funktioniert nun auch sehr gut mit vdr-1.7.15. Aussetzer kann ich keine feststellen, allerdings leider nach >20min bleibt das Bild stehen. Buffer usage geht plötzlich auf 100% und streamdev meldet lost connection, connection time out. Danach lässt sich nicht mehr umschalten, der vdr muss gekilled werden.
Lass ich auf einem Sender eine Aufnahme laufen, und schaue mir die Aufnahme parallel an, funktioniert es problemlos.
Zwischen der vip1710-Version 0.1.0 und 0.1.1 konnte ich keinen Unterschied feststellen.

Möglicherweise liegt es an streamdev, ich nutze die letzte CVS Version.

Mittlerweile nutze ich die Box :
a) Media server mit minidlna --> funktioniert selbst mit ca. 500 Gb relativ fix
b) MPD um Musik in meinem Hobbyraum zu hören. Da hatte mal jemand von hier mit einem schönen plugin begonnen, das als reiner Abspieler taugt. Sehr viel versprechend leider müsste da noch einiges gemacht werden. Muggle und Music hatte ich versucht, aber irgendwie funktioniert da die Ausgabe nicht (trotz OSS)
c) halt als streaming client für vdr

Ist nicht schlecht für 5,-€.

Habe gerade eine neue Version (0.1.2) veröffentlicht, die VDR 1.7.x-fähig ist und das auch aktiv insofern benutzt, als dass TS-Daten an den VIP-Softwarestack übergeben werden. Damit haben die Abbrüche/Unterbrechungen bei mir ein Ende. Ein paar Traces haben mir gezeigt, dass die Box nur bei TS-Daten eine ordentliche Zeitsynchronisation macht.

In der Minidistribution ist jetzt auch epgsync mit drin.

Dafür habe ich das Audio-Transcoding vorerst rausgeworfen. Wenn das jemand benutzt hat und es in vorigen Versionen wirklich funktioniert hat, könnte ich drüber nachdenken, das wieder einzupflegen.

Diese Version ist bisher das zuverlässigste, was ich da bisher so gebastelt habe.

Leider stimmt derzeit die Zeitzone nicht, fällt mir jetzt erst auf, da ja der EPG jetzt prinzipiell funktioniert.... Quick-Fix wäre, das händisch via plugrc zu setzen. Ich werde da noch mal die Minidistribution updaten, komme aber erst am Wochenende dazu.

Klasse, werd ich sofort testen.
Ja das mit der Zeitzone hab ich bereits probiert. Hab es in der plugrc gemacht (localtime gelöscht, neue mit Berlin verlinkt angelegt), war trotzdem immer auf UTC. Mache ich es händisch über telnet funktioniert es einwandfrei. Irgendwo hatte ich gesehen, dass die Zeitzone über settings.xml eingestellt wird ?

Kurzes Feedback:

Streaming läuft rock-stable. Vielen Dank Hawhill !!!

Wie sit das eigentlich inzwischen mit den Umschaltzeiten? Sind die besser geworden?

Ansonsten: weiter so Hans-Werner

Subjektiv würde ich sagen: Ein bisschen. Viel mehr geht wohl auch erstmal nicht... Jedenfalls habe ich noch keinen Weg gefunden, den Stream-Puffer im Vendor-Software-Stack kürzer zu machen - und ich glaube, das wäre der einzige Punkt, an dem sich da noch was verbessern ließe. Also wird es bei etwa 3-3,5s wohl bleiben.

Hallo,

ich muss zugeben, nicht den ganzen Thread gelesen zu haben, aber bitte nicht schlagen

Ich überlege, ob man mit der VIP nicht ganz einfach mit Squeezeslave oder SlimMp3Slave einen Squeezebox Receiver bauen kann?

Dazu habe ich eigentlich zwei Fragen:
1) Fehlen mir da irgendwelche Funktionalitäten gegenüber einem echten Squeezebox Receiver
2) Wie lange brauche ich, um auf der VIP Software zu installieren und dafür zu kompilieren?

Gruß,
Hendrik

1. weiß ich nicht, welche hat der denn bzw. wo finde ich das schnell aufgelistet? Auf den ersten Blick würde ich sagen: Sollte gehen.
2. hängt etwas von der Vorerfahrung ab, würd' ich sagen. Wenn du nur das Installieren und nicht das Lernen meinst: Ein Download von Motorola (x86-SDK) oder von meiner Page (natives Mipsel-SDK, auch schon mit einiger weiterer Software), entpacken, fertig.

Hallo,

danke für die flotte Antwort.
zu 1) Das weiss ich auch noch nicht so genau. Hatte gehofft, dass hier jemand mitliest, der dieses Gerät hat. M.w. kann der nix anderes als Musik abzuspielen (ähnlich MPD). Nur dass es dazu eben noch andere Hardware gibt (z.B. eine Fernbedienung mit Display, von der man alles steuern kann). Man kann mit der Fernbedienung dann aber alle Clients steuern. Das lässt mich vermuten, dass die Steuerung über den Server läuft.

zu 2) Mir ging's eher um's lernen Unter http://hilses.de/vip1710/ verstehe ich leider nur einen Bruchteil. Was mir fehlt ist ein Überblick darüber, was ich machen muss, um darauf meine Software laufen zu lassen.

Auf der Homepage zeigst du ja Schritt für Schritt, was zu tun ist. Ich verstehe aber nicht, was da wofür gemacht wird. Scheinbar hat man ja, wenn man das ganze ausführt schon Shell Zugriff. Wofür sind also die Schritte gut?
(Ist bestimmt schon irgendwo beschrieben. Ein Link reicht mir!)

Gruß,
Hendrik

Zitat

Original von Hawhill
... Jedenfalls habe ich noch keinen Weg gefunden, den Stream-Puffer im Vendor-Software-Stack kürzer zu machen - und ich glaube, das wäre der einzige Punkt, an dem sich da noch was verbessern ließe. Also wird es bei etwa 3-3,5s wohl bleiben.

Ob das Reduzieren des Buffers zielführend ist bezweifele ich mal. Besser wäre es ein Clear des Buffers oder ein reinit zu machen. Dafür gibts doch bestimmt IPC Commands.

Naja, das mache ich auch, indem ich quasi einmal "Close" und ein neues "Open+Play" mache. Nur fängt das Ding erst dann mit dem Abspielen an, wenn der Buffer einen gewissen Füllstand erreicht hat. Aber ehrlich gesagt habe ich gar keine Lust, da noch weiter dran zu feilen, da es tempo-mäßig für mich völlig reicht....

lola: Kann ich nicht testen, muss mal wer mit entsprechendem Equipment machen. Das Strukturbild ist aber nicht so das gelbe vom Ei, um daraus technische Eigenschaften abzuleiten. Das muss noch mal ein Marketing-Mensch in der Mache gehabt haben. Besser ist das technische Referenzhandbuch, das irgendwo aufgetaucht und im µC-Thread verlinkt ist (wenn auch für eine minimal abweichende Xilleon-Plattform).

henfri: Naja, dafür musst du sie kompilieren. Und das geht mit einer Toolchain bzw. einem Build-Environment. Auf meiner Page steht dazu gar nicht viel (Text), denn letzten Endes unterscheidet sich das nicht davon, was man so braucht um ganz generell auf irgendnem OS seine eigene Software zum Laufen zu bringen... Du kannst halt einfach entweder auf deinem PC die Cross-Toolchain von Motorola installieren oder auf der Box (d.h. auf einem an die Box angeschlossenen externen Medium oder auf einer Netzwerkfreigabe) die von mir zusammenkompilierte native Toolchain. Zum Kompilieren von Software, zu den Build-Systemen (make, autotools) gibt es eigentlich nichts VIP-spezifisches zu sagen, da kann man sich an ganz reguläre, universelle Dokumentation halten.

Zitat

Original von Hawhill
henfri: Naja, dafür musst du sie kompilieren. Und das geht mit einer Toolchain bzw. einem Build-Environment. Auf meiner Page steht dazu gar nicht viel (Text), denn letzten Endes unterscheidet sich das nicht davon, was man so braucht um ganz generell auf irgendnem OS seine eigene Software zum Laufen zu bringen...

Das ist schon klar.

Aber was ich mich Frage ist:
Was muss ich machen, um meine Anwendungen auf der vip laufen lassen zu können.

Ich glaube, es reicht nicht, die (cross-)kompilierten executables auf einen Stick zu packen, und sich via ssh auf die VIP anzumelden.
Ich glaube, es ist vorher nötig, die Kiste erst zu "erobern". Aber was bedeutet erobern? Wenn ich deine Anleitung lese, dann kann ich ja schon via telnet/ssh auf die Box zugreifen. Was geht denn nicht? Wofür sind die Schritte, die du auf deiner Homepage beschreibst?

Sprich: Was detailiert gemacht werden muss, finde ich auf deiner HP, denke ich. Aber das abstraktere fehlt mir.

Wenn ich hier lese, dann gibt's drei verschiedene Hardwareversionen. Welche wird bei Pollin geliefert?

Gruß,
Hendrik

Geht ohne großartige Umschweife. Es gibt tatsächlich ohne weitere Arbeit den Telnet-Zugriff direkt auf 'ne Root-Shell. Out-of-the-box.

Was noch nicht geht ist zB der Zugriff auf USB-Storage. Dafür müssen die usb-storage- und SCSI-Module geladen werden, da findest du auf meiner Seite zB ein Archiv, das die enthält. Ein FAT-Treiber ist dann bereits auf der Box im Kernel drin, falls du JFS benutzen willst würdest du wiederum einen Treiber auf meiner Seite finden (wie auch zB für NFS oder CIFS, falls du nicht mit USB-Storage sondern lieber Netzwerkfreigaben arbeiten willst).

Ansonsten beschreibe ich auf meiner Seite einige verschiedene Details. Etwas mehr Platz nimmt dort der settings2.xml-Exploit ein, aber aus reiner Nutzerperspektive ist nur der Abschnitt mit dessen Einrichtung interessant. Und das ist dann wichtig, wenn man eigene Sachen automatisch beim Booten starten können will. Macht vorerst wohl nur bei Boxen mit Flash Sinn - keine Ahnung, wie das bei Boxen ohne aussieht.

Ansonsten reicht es in der Tat aus, die Sachen einfach auf nem Stick zu haben. Falls du auch dynamische Bibliotheken auf dem Stick hast, musst du u.U. noch den Loader-Pfad entsprechend konfigurieren (siehe "man 8 ld.so" auf nem Linux-System). Um einen Autostart hinzubekommen, könntest du eben auf den settings2.xml-Exploit setzen.

Hi.

Hat das Teil eine Serielle Schnitstelle? Bzw funktioniert der Kartenleser?
Ich wollte einen Seriellen Kartenleser dranhängen.

Gruß,
Lado

Das Ding hat zwar einen eingebauten Kartenleser, aber wie der angesteuert wird, weiß ich nicht genau (bzw. eigentlich doch: Das macht auch der halserver-Daemon, aber der ist ein closed-source-BLOB und ich habe keine Ahnung, was der für Interfaces anbietet).

Die Kiste hat aber einen seriellen Port - auf der Platine und mit TTL-Pegeln. Das heißt also, dass ein RS232-Pegelwandler nötig ist, plus ein ganz klein wenig Lötarbeit.

Ist hier im Forum ja schon beinahe OT - ich schlage daher vor, dazu den Wiki-Artikel auf mikrocontroller.de zu Rate zu ziehen. Dort ist angegeben, wo die Kontakte für die serielle Schnittstelle sind.

Mal ne Frage:
Grundsätzliches Problem ist, das sobald vdr/runvdr.sh gekilled werden, die runvdr.sh den vdr danach nie wieder starten kann (vdr läuft zwar aber keine Ausgabe). Danach muss die Kiste neu gebootet werden.
(halserver ? procman ? etc)
Da ich das Ding auch für Musik verwenden möchte, hab ich nach einer Möglichkeit gesucht, ncmpcpp (client für mpd) am TVout darzustellen. Das ganze läuft jetzt in dfbterm (danke Hawhill !) und lässt sich per irpty mit der remote steuern.
Ich möchte zwischen vdr und diesem dfbterm umschalten. Bekanntermassen kann man dafür das externalplayer plugin nutzen.
Wenn ich nun von vdr auf dfbterm umschalte, ist leider nichts sichtbar, obwohl dfbterm läuft. Das Problem ist ursächlich irgendwo in directfb (Speicher), möglicherweise innerhalb vom vip1710-plugin.
Wenn vdr / runvdr.sh manuell gekilled werden, funktioniert die Ausgabe von dfbterm. Danach komme ich aber leider auch nicht mehr zu vdr zurück.

Habt ihr eine Idee ?

Ich blick da nicht durch, so wie ich verstanden habe, kann man ja den Bootloader signierung umgehen.
Kann man da eigentlich z.B. Debian installieren? bzw. i-eine ARM Linux?