Posts by Samotian

Die Einträge in der sources.conf habe ich gerade eben vorgenommen - das ist die kurzfristig am schnellsten umzusetzende Lösung. Nach einem VDR-Neustart habe ich wild herumgezappt und subjektiv ist es etwas besser, aber noch nicht perfekt. Ich bleibe dran - schon aus Eigeninteresse.

Gut, das schaue ich mir mal an. Da es in den Ubuntu-Paketquellen nicht vorhanden zu sein scheint (und ich am Sonntagabend ohnehin nicht am Fernsehempfang rumfummeln darf), wird die Rückmeldung etwas dauern. Vielen Dank soweit.

Der DVB-T2-Tuner kann auch DVB-C, aber da die channels.conf mit Hilfe des Wirbelscan-Plugins erstellt wurde, würden mich DVB-C-Kanäle sehr wundern.

Die sources.conf ist die unveränderte Datei aus der Ubuntu-Standardinstallation. Bei DVB-S(2) ist für mich (zumindest derzeit) nur S19.2E Astra 1KR/1L/1M/2C interessant.

Moin!

ich habe eine OctopusNet mit je einem Twintuner für DVB-S(2) und DVB-T2. Mein VDR, der per Satip-Plugin auf die OctopusNet zugreift, läuft auf einem Odroid-N2 mit Ubuntu 22.04 (headless). Als Client dient Kodi auf verschiedenen Plattformen (per VNSI-Plugin), insbesondere eine Vero4K, ein Raspi3 (beide auf mit OSMC als OS) und ein Android-Tablet. Meistens ist nur ein Client aktiv, gelegentlich zwei.

Ich habe immer wieder Umschaltprobleme beim Wechsel zwischen DVB-S(2)-Sendern und solchen, die über DVB-T2 reinkommen - der Kodi-PVR-Client meldet dann "Channel: No data". Wenn man dann die Wiedergabe stoppt und anschließend wieder den gleichen Kanal wählt, wird er wiedergegeben. Es passiert aber nicht immer, ein genaues Muster habe ich noch nicht erkannt. Das Problem ist von laufenden/geplanten Aufnahmen unabhängig. Im Webinterface der OctopusNet finde ich nichts Auffälliges.

In /etc/vdr/conf.d/satip steht:

[satip]
-s 192.168.2.27|DVBS2-2,DVBT2-2|OctopusNet

Falls weitere Konfigurationsdetails benötigt werden, liefere ich diese gerne nach. Hat jemand eine gute Idee dazu?

So, offensichtlich musste ich eine Weile rumfummeln, aber jetzt läuft's. Hintergrund des ganzen Anliegens war, dass ich meinem Bruder ein RPi2-basiertes Kodi-Mediencenter mit VDR und diversen IPTV-Streams fertig gemacht habe. Er hatte daraufhin die Anmerkung, dass Frau und Töchter von zwei getrennten Senderlisten in "TV" und "Video" verwirrt wären und ob man das nicht vereinheitlichen könnte. Da war dann mein Ehrgeiz gepackt...
Mit den angefügten Dateien laufen diverse frei zugängliche IPTV-Sender (insbesondere öffentlich rechtliche bis 720p) zusammen mit DVB-T auf einem VDR, der per VNSI als Backend für Kodi läuft, so dass alle Sender in Kodi unter TV erscheinen. Beim Audio bin ich nicht ums Transkodieren nach MPEG-Audio herumgekommen, aber das ist vergleichsweise unaufwendig.

Um das nachzubauen, sind folgende Dateien nötig:
*angepasste channels.conf (unter Debian Wheezy: /var/lib/vdr/channels.conf - Inhalt an bestehende channels.conf anhängen)
*angepasstes vlc2iptv-Script (unter Debian Wheezy: /usr/share/vdr/plugins/iptv/vlc2iptv)
*conf-Dateien für die Sender (unter Debian Wheezy: /etc/vdr/plugins/iptv/vlcinput/*.conf)
*Optional: Konfigurationsdatei plugin.iptv.conf (unter Debian Wheezy: /etc/vdr/plugins/plugin.iptv.conf) - damit wird die Anzahl der IPTV-Devices auf 2 gesetzt, was dem Umschalten zu Gute kommen sollte.

Vorsicht: Das Script heißt laut channels.conf "vlc2iptv", zum Posten musste ich aber die Endung ".sh" anhängen, das bitte rückgängig machen. Die channels.conf ist m.E. noch nicht optimal in Hinblick auf die Nummerierung der Sender, der "A"-Eintrag wird vom vlc2iptv-Script auch nicht genutzt.

Ich habe bewusst auf obskure Server verzichtet und leider funktioniert die hier vorgestellte Lösung mit IP-Spoofing nicht mehr (neulich ging's noch - )
Vielleicht wäre ja ein Sammelthread für solche Stream-Adressen sinnvoll - ich werde jedenfalls posten, wenn ich auf weitere Sender stoße. Irgendwo hier im Forum schwirrt eine Liste bayrischer Regionalsender rum - vielleicht könnte ja mal jemand, bei dem das regionale Interesse stärker ausgeprägt ist als bei mir, die entsprechenden channels.conf-Einträge und conf-Dateien durchsehen und posten.

[EDIT] An einer Lösung für's EPG bastle ich noch.

Cool. Damit wird das auch für ARM-Boards interessant, die ja des öfteren MPEG2 in Hardware dekodieren, aber eben nicht enkodieren.
Danke für die schnelle Antwort!

Ich probiere gerade das IPTV-Plugin in Verbindung mit den Streams aus der ZDF Mediathek. Der übliche Weg ist es ja wohl, diese Streams mit vlc2iptv zu transkodieren. Da es sich um H264 Video handelt, stellt sich mir die Frage, ob das eigentliche Transkodieren nach MPEG2 überhaupt noch nötig ist oder ob Remuxen und ggf. Skalieren ausreichend wären. Schließlich ist der ganze HD-Kram ja auch H264. Gibt's da schon Erfahrungen?

Ich schon wieder mit einem weiteren Link für Interessierte:
http://focus.ti.com/general/docs/g…contentId=49963
Texas Instruments behauptet dort:

Quote

This site aims to help open source developers find the resources needed to use TI’s platforms. TI supports open source initiatives to drive innovation and enable our customers to create market-leading devices.

Wie gesagt, ich bin komplett untauglich, um den VDR und den DSP des Beagleboards programmiertechnisch zusammenzubringen. Ich könnte allenfalls anstatt von MPlayer eine gst-launch-Pipeline erstellen, die die Videoausgabe mittels DSP bewerkstelligen könnte. Das werde ich auch in Angriff nehmen, sobald ich die derzeitige Lösung auf einem Stand habe, den ich dann einfach in die virtuelle Schublade legen kann, um ihn im Falle des Scheiterns beim Plan B mit gst-launch gleich wieder reaktivieren zu können. Wenn ich jetzt bei einem nur beinahe befriedigenden Stand aufhöre, wird hinterher die Fehlersuche nur um so nerviger - alles hübsch der Reihe nach.

Gruß,

Thomas

So, nach ein paar weiteren Experimentierstunden habe ich nun ein Setup, das einem normalen VDR vom Look & Feel schon relativ nahe kommt. Die Bedienung ist zwar etwas lahm, aber da werde ich noch feintunen.
Frontend ist nach wie vor MPlayer und zur Anzeige des OSD verwende ich tightvncviewer im Vollbildmodus. Da ich nun zwei Fenster habe, die zu bedienen sind, verarbeitet ich sämtliche Fernbedienungssignale per ~/.lircrc mit irexec.
Grobe Vorgehensweise:
VDR und irexec werden per Script gestartet. Wird auf der Fernbedienung die Powertaste gedrückt, startet Mplayer als Frontend im Vollbildmodus und zeigt das TV-Signal - der nächste Druck auf Power schließt dann das Frontend wieder. Beim Druck auf "Menü" startet tightvncviewer und zeigt das OSD. irexec leitet die meisten FB-Signale einfach an den VDR weiter, so dass die OSD-Bedienung absolut herkömmlich ist. Nur das Schließen des OSDs hinterlässt ein leeres, schwarzes Vollbildfenster, das dann mit einer Extra-Taste geschlossen wird (bei den üblichen Tasten wurde es mir zu unübersichtlich, da je nach Kontext unterschiedliche Tasten(folgen) zum Schließen des OSDs führen können).
Mit transset ließe sich wohl auch eine Transparenz dieses Fensters erreichen, doch das liegt weder als Paket für Angström noch als Source in OpenEmbedded vor; nativ ließ es sich wegen einiger fehlender dev-Pakete nicht kompilieren und beim manuellen Auflösen der Abhängigkeiten in der OpenEmbedded-Cross-Compiler-Umgebung bin ich bislang leider schmählich gescheitert...
MPlayer wird, wie bei der Geexbox, über einen Fifo gesteuert. Auch wenn die ganze MPlayer-Geschichte eher eine Notlösung ist, so hat sie doch den Vorteil, dass man mit sehr geringem Aufwand so ziemlich alles an Inhalten, die MPlayer darstellen kann, auf den Bildschirm bekommt. Ob man die Ansteuerung nun über die commands.conf, die reccmds.conf oder aber ein nach wie vor verfügbares MPlayer-Menü realisiert, hängt vom eigenen Geschmack und sicher auch von der konkreten Aufgabe ab.
Die Now&Next-Anzeige beim Umschalten sowie sonstige OSD-Messages fehlen mir noch, was ich aber a) halbwegs verschmerzbar finde und b) ggf. mit SVDRP-Abfragen und dem MPlayer-OSD nachbauen kann (zumindest Now& Next sollte nicht so schwer sein).

Ich werde noch ein paar Ungereimtheiten beseitigen und dann, sofern hier irgendjemand Interesse daran hat, die relevanten Scripte posten.

Soweit erstmal,

Thomas

So auf die Schnelle und aus dem Kopf:
Nein, Open Source sind die Treiber leider nicht. Allerdings kooperiert Texas Instruments als relevanter Hersteller bislang wohl recht gut mit der Community, aber um eine Registrierung für den Download des SDKs kommt man (soweit ich weiß) nicht herum. Hier solltest Du mehr herausfinden können.
In den Angström-Feeds für das Beagleboard gibt (gab?) es allerdings ein Paket mit den fertigen Modulen und Codecs für GStreamer, die man auch ohne SDK (und Registrierung) nutzen kann. (siehe http://groups.google.com/group/beagleboard/browse_thread/thread/0a88dccbb7acc06c#)
Da meine "Programmier"-Kenntnisse leider bei Scripten aufhören, habe ich alleine keine Chance, dem VDR selbst die Bildausgabe (per Softdevice oder wie auch immer) beizubringen. Daher bastle ich derzeit an Lösungen, die zwar weniger elegant, aber für mich umsetzbar sind.
Was schon recht ordentlich geht:
*VLC als Frontend für einen VDR mit ffnetdev-Plugin. Damit kommt man auch an das OSD. Allerdings gibt es für den Beagleboard-VLC keine optimierte Videoausgabe und Xv ist in diesem Szenario tendenziell zu lahm.
*Mplayer als Frontend für einen VDR mit ffnetdev (Streamdev-Server geht auch). Der Beagleboard-Mplayer ist hinsichtlich der NEON-Erweiterungen für ARM und bei der Videoausgabe für das Beagleboard angepasst worden und ist VLC in der Performance auf dieser Plattform klar überlegen. Für diese Lösung kupfere ich ganz massiv von der Geexbox ab. Das hat den Vorteil, dass ich relativ schnell zu Ergebnissen komme - man kann mal eben nach Feierabend ein Menü ergänzen. Das sind dann aber natürlich MPlayer-Menüs. Um den VDR zu bedienen (und nicht nur fern zu sehen) bedarf es daher weiterer Scripte (machbar, aber leider eine Fleißarbeit). Alternativ dazu kann man das VDR-OSD in diesem Szenario in einem zweiten Fenster mit tightvncviewer ankucken (und bedienen), aber ein Extra-Fenster für das OSD ist natürlich unelegant. Auch diese Lösung verzichtet auf den DSP.

Um den DSP zu nutzen, bleibt bei meinem Kompetenzgrad also vorerst nur die dritte Option: Streamausgabe vom VDR (s.o.) und dann per gst-launch und dem entsprechenden src-Plugin für GStreamer eine Pipeline bauen. Eventuell könnte GStreamer nicht nur auf den Videostream, sondern auch auf das OSD zugreifen, aber wie ich das in eine Pipeline kriegen soll, ist mir derzeit noch schleierhaft. Diese Lösung habe ich bislang nur in Ansätzen getestet, allerdings steht das recht weit oben auf der Liste. Wenn ich mehr weiß, melde ich mich wieder.

Gruß,

Thomas

Moin!

Bisher war ich hier nur lesend dabei, weil mein "Haupt-VDR" mit seiner speziellen Hardware eher hier behandelt wird. Nun habe ich mir aber auch ein Beagleboard zugelegt und auch darauf einen VDR aufgesetzt (Basis: Angström). Ich denke, das könnte auch für andere Leute interessant sein. Meine Vorgehensweise habe ich hier etwas genauer beschrieben.

Leider klappt noch nicht alles. Ich nutze einen USB-DVB-T-Stick (also eine Budget-Lösung), was angesichts der Hardware des Beagleboards eigentlich kein Problem ist - nur: Der VDR weiß natürlich nichts von dieser Hardware. Dummerweise ist es mir noch nicht gelungen, das Softdevice-Plugin auf dem Beagleboard zu kompilieren. So experimentiere ich derzeit mit dem Streamdev-Server-Plugin bzw. dem FFNetDev-Plugin, um dann lokal mit MPlayer oder VLC auf diese Streams zuzugreifen, wobei MPlayer wegen spezieller Anpassungen an die Hardware des Beagleboards performanter ist. Noch besser wäre es vermutlich, den Stream mit GStreamer abzugreifen, weil sich die Entwicklung rund um den Beagleboard-DSP auf GStreamer konzentriert - man muss das Rad ja nicht neu erfinden.
Alle diese Lösungen haben einen Schönheitsfehler: Man hat keinen (direkten) Zugriff auf das OSD und auch um eine Fernbedienung zu nutzen, muss man zumindest Verrenkungen anstellen.

Falls jemand Interesse an einem Gedanken- und Erfahrungsaustausch zum VDR auf dem Beagleboard oder anderen OMAP-Plattformen hat - nur zu, ich bin ganz Ohr.

Gruß und schönen Sonntag noch,

Thomas