Vorab: Willkommen im Club — das yaVDR-Team bloggt nun auch ;)
Langsam nimmt mein VDR-Server-und-Client-Projekt Formen an. Ich hänge zwar noch immer an der Fernbedienungsfrage (lirc_ttusbir wie auch der Treiber für das normale serielle Homebrew-IR-Interface hängen sich auf der Zielhardware (ASUS V-M3N8200 Mainboard, AMD Athlon(tm) 7750 Dual-Core Processor) weg), aber das außen vor, funktionieren timergesteuert Aufnahmen, das Abspielen von Alt-VDR-Aufnahmen (der Wohnzimmer-VDR ist noch ein antikes 1.4.7-Schätzchen) via NFS-Mounts (aufgrund von Rechteproblemen, UID vdr-alt != vdr-neu, leider nur blankes Abspielen, kein »Waschen, Schneiden, Legen«), lokales Schneiden von Aufnahmen¹ … kurz eigentlich erst einmal alles, was VDR können sollte.
Heute habe ich dann mal angefangen, weitere, liebgewonnene Add-ons und Plugins zu suchen und zu installieren — und bin sehr angetan von vdr-plugin-fritzbox, vdr-plugin-timeline, vdr-plugin-remoteosd sowie vdr-plugin-remotetimers. Denn, anders als bei xineliboutput, wo nur ein einem Tag kompilierte Versionen zueinander kompatibel sind (jedenfalls kann ich mit aktuellen vdr-sxfe weder meinen 1.4.7er noch den 1.6.0er an einem entfernten Ort bedienen, selbst aus anderen Quellen stammende 1.7er vdr-Installationen sind eher problembeladen denn nicht :(), steuert remoteosd 0.1.0 von meinem yaVDR aus meinen 1.4.7er mit svdrpext 0.0.1 — so soll das sein!
Das ist insofern relevant, als daß ich im Endausbau einen bis mehrere VDR-Server für programmierte Aufnahmen haben möchte, die von einer zentralen Instanz – dem (ya)VDR im Wohnzimmer – programmiert werden können sollen. Super wäre ein Frontend, welches diese mehreren VDR logisch zusammenfaßt und die Aufnahmen entsprechend verteilt; aber im ersten Schritt reichte es, wenn ich, das ist noch der Knackpunkt, mehrere VDR von einem zentralen VDR fernkonfigurieren könnte. Denn, soweit ich bislang gesehen habe, gibt es keinen vorgesehenen Weg, eine 1:n-Beziehung zu unterstützen (1 Frontend-VDR und n Backends), über 1:1 kam man bislang leider nicht hinaus².
Ein anderes Thema, an dem ich derzeit hänge: die Einbindung der T-Entertain-IPTV-Kanäle (des öffentlich-rechtlichen Fernsehens, der Rest ist ja »grundverschlüsselt«). Mit der Kanalliste, die ich im Netz gefunden habe, blitzte anfänglich mal was auf, mittlerweile kommt aber »Kanal nicht verfügbar« und die Kanäle werden als verschlüsselt angezeigt :( Tipps werden gerne angenommen:
54:Das Erste IPTV;IPTV:1:IPTV|S1P1|UDP|239.35.129.11|10000:P:0:256=27:257=deu;258=AC3:259:4AE2:28106:0:0:0 5478:Eins HD;IPTV:10:IPTV|S1P1|UDP|239.35.10.1|10000:P:0:256=27:257=deu;258=AC3:259:4AE2:11100:0:0:0
Schlußendlich suche ich dann noch nach einer »vernünftigen« EPG-Variante für die Sender von BBC und ITV (Astra 28,2° Ost), sodaß automatische Aufnahmen »immer« funktionieren und nicht nur, wenn grade ein EPG-Update lief (BBC, ITV und andere senden nur die EPG-Info »jetzt« und »nächstes Programm«, anders als die meisten deutschsprachigen Sender zumindest auf Astra, die das Programm für 3 bis 5 Tage im voraus übermitteln). Auf dem alten VDR hatte ich da mal einen XML2irgendwas-Mechanismus funktional am Start, aber der tut leider auch nimmer …
So, dann werde ich mich mal schlauzumachen versuchen, wie man die yaVDR-Sourcen als Basis für eigene Erweiterungen nimmt, z. B. um nicht »mitgelieferte« Plugins zu kompilieren … Als Brute-Force-Ansatz könnte man ja remoteosd einfach als remoteosd1, remoteosd2, remoteosd3 durchkompilieren und einbinden, mit anderen Pfaden für die Konfiguration, versteht sich.
___
² Für den Einsatzfall »empfangsteilloser Client im Wohnzimmer steuert Server mit mehreren Karten im Keller« ist das sicher ausreichend, aber eben nicht ganz konsequent auf weitere Nutzungsszenarien ausgerichtet. Ich habe z. B. einen Rechner mit VDR gut 10 km entfernt von meinem Wohnort stehen; bei lokalen Wetterphänomen, die nicht auch das Internet karpott machen, könnte ich notfalls von dort streamen, sicherlich aber »wichtige« Aufnahmen dort parallel durchführen.
Hallo Kai,
bei einigen der geschilderten “Probleme”/Herausforderungen kann Dir geholfen werden:
1) NFS-Probleme aufgrund verschiedener UIDs.
Hier gibt es von unserem Team ein experimentelles Skript “change-vdr-uid”, mit welchem man die UIDs auf Zweit- und Dritt-VDRs anpassen kann. Das Skript soll genau das Problem lösen, jedoch ist es in der breiten Öffentlichkeit noch nicht getestet worden. Das Skript ist Bestandteil von yaVDR 0.1.x, Du kannst es aber auch allein runterladen und auf anderen VDRs verwenden. Aber Vorsicht! :)
http://svn.origo.ethz.ch/wsvn/yavdr/trunk/utils/change-vdr-uid
Frühestens mit dem kommenden yaVDR 0.2 (basierend auf Lucid) wird es auch eine autofs-Einbindung geben, mit der man dem VDR mehrere Video-Verzeichnisse (video.01, video.02, etc.) vorhalten kann, von denen einige im Netzwerk liegen können (NFS oder Samba). Das ist aber in der Entwicklung und braucht noch ein paar Tage.
2) EPG für freesat (BBC, ITV, Channel4/5)
Großes Problem, einfache Lösung:
sudo apt-get install vdr-plugin-eepg
Dauert ein paar Minuten, bis alles da ist. Aber dann macht freesat endlich richtig Spaß.
3) Selberbauen von Plugins
Debiankonform Sourcepakete bauen mit dpkg-buildpackage ist möglich, wobei das Paket vdr-dev mit den Includes installiert sein muss. Sourcepakete zu allen von uns angebotenen Plugins liegen in unseren Launchpad-Repositories zum Runterladen und Anschauen.
Noch etwas:
Live-TV via XBMC: Das Thema ist stark in Bewegung. Gab es bis vor wenigen Tagen nur vdr-plugin-streamdev-server + XBMC-PVR-Klient für streamdev, hat der dahintersteckende Entwickler alwinus (aka pingpong) nun eine neue, performantere Streaminglösung vdr-plugin-vnsiserver rausgebracht, die die Umschaltzeiten deutlich verbessert. Dafür braucht man aber brandaktuelle XBMC-Builds aus meinem PPA.
Vielleicht wäre das, wenn es stabil ist, ein Youtube-Video wert. Mal sehen, welcher Blog schneller ist. ;-)
Vielen Dank für Deine Videos!
Viele Grüße
hepi
P.S.: Nur zur Info. Trackbacks scheinen in unserem Blog leider noch nicht richtig zu funktionieren.
Das Rechteproblem bekomme ich ggf. schon in den Griff, SMB oder SSHFS würden es notfalls lösen; zum Anschauen reicht’s ja derzeit und für die Zukunft werde ich feste UIDs für den VDR-User vergeben, egal, welche Distribution zum Einsatz kommt => Thema durch ;)
“apt-get install vdr-plugin-eepg” habe ich jetzt gemacht, mal gucken, wie das am Nachmittag aussieht; danke für den Tip!
Zum Pakete selber bauen: ah, Ihr setzt wieder auf »vdr-dev«? Bei meiner »mach’s Dir selbst«-Odyssee hatte ich den Eindruck gewonnen, vdr-dev sei tot? Egal; das steht für gegen Ende der Woche auf dem Programm — vielleicht fällt bei Euch im Blog ja bis dahin ein Beitrag dazu an? ;)
Klingt spannend, wobei ich XBMC als VDR-Frontend eigentlich weniger sehe — der Kern von VDR ist, für mich ;), die geniale Aufnahmelogik (untersützt durch div. AddOns/Plugins, die das Durchsuchen des EPGs und die Steuerung der Aufnahme umsetzen), das Scheiden der Aufnahmen und deren Wiedergabe. XBMC bringt da zwar zwei Kubikmeter Eye-Candy, aber – aus meiner Sicht – keine funktionale Erweiterung …
Aber ich mache davon gerne ein Video, wenn’s stabil(er) läuft – auch mit der aktuellen Kopplung gibt’s ja ggf. Probleme. Aber für DVB gibt es imho keine bessere Software als VDR — und was Eye-Candy bei der Medienwiedergabe angeht, ist XBMC mindestens ganz vorne dabei. Insofern ist yaVDR imho schon das Mittel der Wahl ;)
Oh, bitte, gerne; vielen Dank für die Zusammenstellung einer HD-tauglichen Distribution für VDR – wie man hier lesen konnte, suche ich diesen Heiligen Gral schon länger ;)
Yepp, Euer Typo3 scheint weder Track- noch Pingbacks zu unterstützen (habe ich ja beides meinem SPHPBLOG mühsam beigebracht automatisch zu erkennen). Bißchen doof für ‘n Blog, aber auch nicht wirklich wichtig ;)
Hallo Kai,
vdr-dev ist nur ein Paket mit Headerfiles, welche ein VDR-Entwickler zum Plugin-Kompilieren braucht. Du meinst wahrscheinlich vdrdevel als Prefix für eine parallel installierbare Development-Version von VDR? Also, bei uns gibt’s kein vdrdevel-Prefix, aber auch keinen stable-Version VDR 1.6. Wir bezeichnen in yaVDR die aktuelle VDR-Entwicklerversion 1.7.x als “vdr”.
Auch wenn sich alle Komfort-Features des VDR nicht in XBMC finden, ich finde es aus zwei Gründen sehr wichtig, dass es diese Entwicklung gibt:
1) Eine softwaremäßige Abstraktion zwischen VDR-Backend und VDR-OSD als Nutzerschnittstelle würde sonst nie stattfinden. Man kann spätestens seit dem XBMC-Frontend den VDR ohne die Bindung an das klassische OSD “denken”.
2) “Politisch”: Für XBMC wird es mehrere PVR-Clients geben, und es wäre ein Jammer, wenn der VDR da nicht ganz vorne mitmischen würde, denn er braucht sich ja nicht zu verstecken. Glücklicherweise haben wir mit alwinus einen Entwickler jemanden, der ein großer VDR-Fan ist (nehme ich zumindest an).
Gruß
Henning
Argl, ja, stimmt ;) Ich meinte diese Unterschiedung (c\’t-VDR/etobi) seinerzeit zwischen stabilem VDR und vdrdevel.
Ansonsten stimme ich Dir zu; VDR ist historisch bedingt noch eng mit den Full-Featured-DVB-Karten (d. h. Karten mit eigenem MPEG-Dekoder und daran angeschlossener (PAL-) TV-Ausgabeeinheit) verzahnt, was Anfangs richtig und wichtig war, um eine qualitativ hochwertige TV-Ausgabe zu bekommen. Seit sicher 5+ Jahren aber geht diese Entwicklung zurück zugunsten (deutlich billigerer) reiner DVB-Empfangskarten und MPEG-Dekodierung in Soft- oder GPU-Hardware.
Heute ist mit CPU/GPU und nur dem DVB-Stream viel mehr zu machen als seinerzeit mit den begrenzten Möglichkeiten der Full-Featured-Karten, die zudem kaum noch gebaut werden. (Wobei ich es erstaunlich fand, wie jemand die begrenzte OSD-Funktion für ein PIP-Plugin zu verwenden wußte – in Graustuden zwar nur, aber nichts desto trotz beachtlich.)
Bei 1.7 scheint mir der Knoten endlich duchschlagen worden zu sein und der Weg der getrennten Betrachtung Input-Devices (DVB-X-Karten, DVB-IP-Datenstrom, Plugins) und Output-Device und einem vollfarbigen und vollformatigen OSD begonnen.
Aus meiner Sicht ist VDR *das* Backend für digitales Fernsehen; und dank der frühzeitigen Bereitstellung von Schnittstellen (SVDRP) sowie spannenden Plugins (streamdev-server, xineliboutput) sowie externen wie internen »EPG-Frontends« (vdradmin (extern), live-Plugin (intern)); vielleicht, weil ich seit rd. 10 Jahren digital fernschaue und daher gar keinen »Analog-Bedarf« mehr habe, viele andere Projekte aber eben aus der Analog-TV-Welt kamen\ … Daß XBMC sich in Richtung »PVR« öffnet (XBMC war initial ja »nur« ein dateibasierter Medienabspieler) und VDR andererseits mit weiteren Funktionen als Backend besser nutzbar wird (streamdev-Server kann nun scheinbar VDR-Aufnahmen rausgeben?), ist imho nur zu begrüßen.