[VDR4ARCH] kann man damit einen headless VDR einrichten ?

  • Hallo zusammen,


    Ich plane gerade den Umstieg von einem Ubuntu basierten System auf ArchLinux. Jetzt habe ich im Archiv den längeren Thread mit der Ankündigung von vdr4arch durchgelesen.


    Dabei bleibt für mich noch ein offener Punkt:


    Bei meinem jetzigen System benutze ich das xineliboutput plugin und auf dem anderen Rechner dann vdr-sxfe als Client. Laut dem Issue-Tracker auf github ist der Autor von vdr4arch nicht an xineliboutput interessiert und er bevorzugt softhddevice.
    Die Frage ist jetzt, kann ich mit dem softhddevice auch so eine Client/Server Lösung haben wie mit xineliboutput / vdr-sxfe ?
    Oder gibt's ne andere Alternative ?


    Danke und Gruß,
    Markus

  • Copperhead bietet doch das xineliboutput-Plugin an, ich sehe da überhaupt kein Problem das zu benutzen. Die Version von vdr-sxfe am Client muss natürlich zum Stand des Plugins am Server passen.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Das geht grundsätzlich schon.


    Was ich allerdings mal machen müsste ist, dass ich vdr-xineliboutput und vdr-sxfe, vdr-fbfe in einzelne Pakete packe.
    Deswegen steht auch im Wiki, dass das momentan noch nicht vorgesehen ist. Ich schaue mir das heute Mittag mal an und trenne die Pakete.


    Spätestens dann sehe ich kein Problem mehr soetwas aufzusetzen. Ich melde mich dann nochmal.

  • Ach so ... das xineliboutput Paket enthält das sxfe ?
    An die Möglichkeit hatte ich nicht gedacht.


    Bei pacman -Sl vdr4arch kam halt kein sxfe, daher war ich etwas verwirrt ...
    Man muss dazu noch sagen, dass ich bisher das Arch nur auf dem Client installiert habe, und das auch vorerst nur dual-boot mäßig (also Teilzeit) nutze. Auf dem VDR ist noch kein Arch drauf. Daher habe ich noch keines der Pakete installiert. Planungs-Phase halt ... ;)


    Wenn Du die Pakete aufteilst (und dafür schon mal vielen Dank!), wäre es hilfreich, wenn das standalone sxfe keine Abhängigkeiten zu den anderen VDR-Paketen hat. Ich will ja auf dem Client keinen vollständigen VDR installieren.


    Bei der Gelegenheit noch ne andere Frage:
    Mein Tuner ist von digital devices. Bei pacman -Sl vdr4arch wird dafür ein Treiber aufgelistet. Ist das dann ein DKMS Paket ?


    Danke und Gruß,
    Markus

  • Wenn Du die Pakete aufteilst (und dafür schon mal vielen Dank!), wäre es hilfreich, wenn das standalone sxfe keine Abhängigkeiten zu den anderen VDR-Paketen hat. Ich will ja auf dem Client keinen vollständigen VDR installieren.


    Ja. Das war der Gedanke dahinter.

    Mein Tuner ist von digital devices. Bei pacman -Sl vdr4arch wird dafür ein Treiber aufgelistet. Ist das dann ein DKMS Paket ?


    Nein. Das ist durchkompiliert. Ich bin kein Freund von DKMS.
    Ich finde auf einem VDR sollte keine komplette Buildumgebung installiert sein, nur weil man einen Treiber nutzen möchte, der nicht im Kernel integriert ist.


  • Nein. Das ist durchkompiliert. Ich bin kein Freund von DKMS.
    Ich finde auf einem VDR sollte keine komplette Buildumgebung installiert sein, nur weil man einen Treiber nutzen möchte, der nicht im Kernel integriert ist.


    Ist mir auch recht :)


    Muss ich dann bei Kernel-Updates was beachten ?

  • Schau sonst in die Debian-Pakete.
    https://launchpad.net/~yavdr/+…06/+listing-archive-extra
    Einfach mit less eine deb-Datei öffnen, bei mir wird dann das Directory-Listing angezeigt.


    Lars.

  • So, ich hab gleich mal das Frontend ausprobiert und es läuft prima zusammen mit dem Ubuntu-basierten VDR.
    Zumindest wenn man es ohne -width und -height Parameter aufruft. Mit diesen Parametern (stimmen mit der Größe auf dem VDR überein) stürzt es sofort ab.


    Jetzt kann ich natürlich nicht sagen, ob es an der Version oder dem Zusammenspiel mit der Version auf dem VDR oder an Deinem Paket liegt (wobei ich letzteres für unwahrscheinlich halte). Ich würde vorschlagen, da erst mal keine Zeit rein zu stecken. Zumal ich es auch ohne die Parameter starten und dann größer ziehen kann.


    Bis ich den VDR umstelle dauert noch ein bisschen, ich gebe dann Rückmeldung.
    Für den Moment ist mir mit dem funktionierenden Client auf Arch schon sehr weit geholfen: Wieder eine Anwendung weniger, für die ich noch Ubuntu booten muss. Bleibt nur noch eine einzige, die ich wirklich nur ganz selten brauche.


    Vielen Dank nochmal dafür.


    EDIT:
    Doch noch ne Kleinigkeit:
    Vorhin hatte ich vdr-sxfe direkt aus der shell gestartet, daher ist es mir nicht gleich aufgefallen:
    Das Icon, das in der .desktop Datei eingetragen ist, fehlt.
    /usr/share/icons/xineliboutput-sxfe.svg


    Eilt aber nicht, ich hab's mir erst mal vom VDR geklaut :)


    Danke und Gruß,
    Markus

  • So, ich bin jetzt endlich dazu gekommen, auch den VDR-Server auf Arch-Basis zu installieren. Grundsätzlich läuft es, nur ein paar kleine Schwierigkeiten habe ich noch:


    1)
    Nach dem Booten habe ich grundsätzlich erst mal kein Signal. Ich muss den vdr.service ein mal stoppen und wieder starten, dann ist es da.
    Könnte das vielleicht mit meinem Tuner von Digital Devices (DVB-C) zu tun haben ? Wartet der vdr.service nicht auf das Tuner-Device ?


    In meinem Fall wäre es sowieso vorteilhaft, wenn ich den Start des vdr.service nach dem Booten noch so 2-3 Minuten rauszögern könnte. Das Mainboard hat ein bisschen Probleme mit der Uhrzeit, d.h. es wäre gut wenn der vdr.service erst startet, wenn der ntpd.service die Zeit mal aktualisiert hat.
    Die Zeit nach dem Tuner zu stellen ist auch keine Lösung, das hab ich früher mal probiert. Denn immer wenn es mal eine Störung beim Empfang gibt, wird die Uhrzeit auf "irgendwas beliebiges" gestellt, was den vdr.service dann dazu veranlasst, alle EPG-Daten und Timer zu verwerfen.


    2)
    Mit dem vdr-sxfe komme ich vom Client aus nicht auf den Arch-basierten VDR. Ich kriege immer "Can't connect to tcp://vdr:37890" (mein VDR-Rechner heisst "vdr"). Gestarted von der Kommandozeilt mit

    Code
    vdr-sxfe xvdr://vdr:37890


    Lokal vom VDR-Rechner aus klappt es, und vom Client-Rechner aus auf den Ubuntu-VDR hat es ja auch geklappt. D.h. die einzelnen Komponenten sind jeweils funktionstauglich, nur wollen sie nicht zusammen arbeiten.
    Die Dateien /var/lib/vdr/plugins/plugin.xineliboutput.conf und /var/lib/vdr/plugins/xineliboutput/allowed_hosts.conf habe ich (wie fast alle .conf Dateien in /var/lib/vdr/) von der Ubuntu-Version übernommen. Dabei habe ich alles, was bei ubuntu in /etc/vdr stand und von /var/lib/vdr nur dorthin gesymlinked war auch gleich nach /var/lib/vdr rübergenommen.
    Aber irgend eine Kleinigkeit muss ich wohl vergessen oder verwürfelt haben.


    Kommt Dir auf Anhieb ein Verdacht, was das typischerweise sein könnte ?




    Danke und Gruß,
    Markus

  • Die Dateien /var/lib/vdr/plugins/plugin.xineliboutput.conf [...] habe ich [...] von der Ubuntu-Version übernommen.

    Was dir nichts bringt, weil vdr4arch die Plugin-Konfiguration nicht aus dieser Datei liest (siehe VDR4Arch - Neue Konfiguration für den VDR und die Plugins). Mit welchen Parametern startest du das Plugin?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Nach dem Booten habe ich grundsätzlich erst mal kein Signal. Ich muss den vdr.service ein mal stoppen und wieder starten, dann ist es da.
    Könnte das vielleicht mit meinem Tuner von Digital Devices (DVB-C) zu tun haben ? Wartet der vdr.service nicht auf das Tuner-Device ?

    Dazu kann ich so nichts sagen. Ich brauche die Ausgabe von "ls /dev/dvb/*" und den Inhalt von "/etc/systemd/system/vdr.service.d/wait-for-devices.conf" Eine Log auf Loglevel 3 vom VDR schadet auch nicht.

    In meinem Fall wäre es sowieso vorteilhaft, wenn ich den Start des vdr.service nach dem Booten noch so 2-3 Minuten rauszögern könnte. Das Mainboard hat ein bisschen Probleme mit der Uhrzeit, d.h. es wäre gut wenn der vdr.service erst startet, wenn der ntpd.service die Zeit mal aktualisiert hat.

    Du solltest vielleicht besser ntpdate nutzen. Wenn die Zeit beim Start nicht passt klingt das aber eher so, als würdest du eine neue Mainboardbatterie benötigen. Services auf unbestimmte Zeit verzögern kann systemd nicht. Du könntest allerdings einen systemd.timer anlegen, der vdr.service eine bestimmte Zeit nach dem Booten erst startet. Ob das sinnvoll ist, musst du selbst wissen.

    Mit dem vdr-sxfe komme ich vom Client aus nicht auf den Arch-basierten VDR. Ich kriege immer "Can't connect to tcp://vdr:37890" (mein VDR-Rechner heisst "vdr")

    Hast du den Server mal angepingt? Wähle mal einen höheren Port. Ich bin mich nicht sicher, inwieweit Ports für root reserviert sind. Ich nutze für sowas immer Port 65000

    Dabei habe ich alles, was bei ubuntu in /etc/vdr stand und von /var/lib/vdr nur dorthin gesymlinked war auch gleich nach /var/lib/vdr rübergenommen.

    Dazu hat sich seahawk ja schon geäußert...

  • Hallöchen,


    Danke für die schnelle Antwort. Bei mir wird's mit dem Ausprobieren nicht so schnell gehen ;)
    Die Konfig Dateien in /etc/vdr/conf.d habe ich schon gesehen, aber ich war nicht sicher, ob die ausreichen. Dann werd ich da noch mal genauer reinschauen.


    Mein VDR-Rechner ist ne Dualboot-Kiste, und momentan habe ich wieder Ubuntu gebootet. Da da noch weitere Dienste drauf laufen (mit z.T. schlecht unterbrechbaren, lang laufenden Jobs), muss ich wieder auf einen passenden Moment warten und dann auch gerade zuhause sein ... gut möglich, dass es wieder erst an einem Sonntagnachmittag klappt.


    Auf ubuntu gab es ja noch das runvdr skript. Da war es natürlich ganz einfch, ein sleep 5m einzubauen. Ich hab nur bei einem anderen Dienst schon gemerkt, dass systemd solche Spielchen nicht mag. :-/


    Meine Mainboard-Batterie ist übrigens fast neu (an die dachte ich auch als erstes). Und ntpdate setzt die Zeit ja nur einmalig. Ich habe aber auch mal ermittelt, dass die Uhr auf dem Mainboard deutlich nach geht, so ca. 17 Sekunden pro Tag. Daher brauche ich etwas, das die Uhr immer wieder korrigiert. Die Kiste läuft nämlich 24/7 durch. Ich könnte natürlich mal ausprobieren, ob ich ntpdate und ntpd nehmen kann.


    Noch eine kleine Erfolgsmeldung:
    Ich habe es auch geschafft, den vdradmin-am vom ubuntu-System rüberzuziehen. Momentan gefällt mir der noch besser als das live-Plugin.


    Danke und Gruß,
    Markus

  • Ich hab nur bei einem anderen Dienst schon gemerkt, dass systemd solche Spielchen nicht mag. :-/

    Man muss es nur richtig machen - man kann auch mit Systemd unsinniges Verhalten abbilden ;)

    Ich habe aber auch mal ermittelt, dass die Uhr auf dem Mainboard deutlich nach geht, so ca. 17 Sekunden pro Tag. Daher brauche ich etwas, das die Uhr immer wieder korrigiert. Die Kiste läuft nämlich 24/7 durch. Ich könnte natürlich mal ausprobieren, ob ich ntpdate und ntpd nehmen kann.

    Wenn der Rechner sowieso durchläuft genügt doch ein kontinuierlicher Abgleich über ntpd.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Wenn der Rechner sowieso durchläuft genügt doch ein kontinuierlicher Abgleich über ntpd.


    Eigentlich schon, aber ich hätte halt gerne sichergestellt, dass der vdr prozess beim Start eine korrekt gestellte Uhr vorfindet. Ich hab nämlich auch schon die Erfahrung gemacht, dass der vdr durcheinander kommt, wenn die Uhrzeit um mehr als nur wenige Sekunden geändert wird. Daher die Idee, den Start zu verzögern.


    Man muss es nur richtig machen - man kann auch mit Systemd unsinniges Verhalten abbilden


    Kannst Du mir nen Tipp geben, wie ich mit dem systemd einen Dienst verzögert starte ?


    So unsinnig ist das Verzögern von Diensten übrigens gar nicht. Wenn man nach systemd delay (oder ähnlichem) sucht, findet man einige Anfragen dazu. Dabei geht es dann auch um Dinge wie "Dienst erst starten, wenn das System (nahezu) idle ist".



    Noch eine allgemeine Anmerkung zur nachgehenden Uhr ... Dieses Mainboard ist da sicherlich ein besonders krasser Fall, aber ich bin seit meinem ersten PC daran gewöhnt (und das ist schon ne ganze Weile her), dass immer der PC die mit Abstand ungenaueste Uhr im Haushalt ist. Sogar der billigste Radiowecker läuft genauer. Vor DSL und den Internet-Flatrates habe ich mir mit einem DCF-Empfänger am Druckerport beholfen.


    Gruß,
    Markus

  • Du brauchst nicht ntpdate und ntpd zu kombinieren weil ntpd beim Aufstart zu allererst die Systemuhr nachzieht und erst danach auf ein kontinuierliches Nachführen umwechselt.


    Wenn die Kiste eh durchläuft dann würde ich für die kaputte Hardware-Uhr nicht viel Zeit verschwenden. Einfach ntpd laufen lassen oder dem VDR erlauben die Systemzeit zu stellen. Unter Linux ist die Hardware-Uhr ohnehin nur ein Backup. Die Zeit, die du siehst, kommt von der Software-Uhr die der Kernel unabhängig von der RTC betreibt.

  • So unsinnig ist das Verzögern von Diensten übrigens gar nicht. Wenn man nach systemd delay (oder ähnlichem) sucht, findet man einige Anfragen dazu.

    Ich bin der Meinung dass das keinen wirklichen Vorteil bringt, man kann doch einfach sinnvolle Abhängigkeiten zwischen den Diensten schaffen, die benötigten Delays können sich auch mit jeder Änderung an der Systemkonfiguration ändern.

    Kannst Du mir nen Tipp geben, wie ich mit dem systemd einen Dienst verzögert starte ?

    Siehe http://www.freedesktop.org/sof…md/man/systemd.timer.html

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Nach dem Booten habe ich grundsätzlich erst mal kein Signal. Ich muss den vdr.service ein mal stoppen und wieder starten, dann ist es da.


    OK, jetzt tut's. Ich hatte noch vergesen zu erwähnen, dass ich den VDR unter meinem login-user laufen lasse. Das ist mir auch recht wichtig, wegen der Berechtigungen der aufgenommenen Dateien. Mein VDR soll ja am Ende headless sein, und ich will die Aufnahmen dann über NFS mit VLC anschauen oder mit ProjectX / Cuttermaran weiterverarbeiten. Außerdem lasse ich da auch noch Skripte drüberlaufen, die das Zeugs umbenennen und aus dem Aufnahme-Verzeichnis raus verschieben. Das geht alles am einfachsten, wenn alle Dateien mir "gehören".


    Jetzt hab ich den User in die Gruppen "video" und "audio" aufgenommen, daran lag's...


    Allerdings wäre ich neugierig zu erfahren, warum die Gruppen-Zugehörigkeit nur beim automatischen Start nach dem Booten eine Rolle zu spielen scheint, aber es auch ohne geht wenn ich den VDR mit systemctl noch mal manuell stoppe und starte.


    Hast du den Server mal angepingt? Wähle mal einen höheren Port. Ich bin mich nicht sicher, inwieweit Ports für root reserviert sind. Ich nutze für sowas immer Port 65000


    Beim --remote= parameter in /etc/vdr/conf.d/50-xineliboutput.conf hatte ich die IP nicht mit eingetragen ... jetzt tut's.


    Aber auch hier noch zwei Fragen:


    1.
    Habe ich das in dem Kommentar falsch verstanden ? Da steht "--remote=<ip>:<port> (default is all interfaces)" daher dachte ich, ich kann den ip-Teil weglassen.


    2.
    In meiner Zeile steht jetzt also folgendes drin:

    Code
    --remote=192.168.1.6:37890


    Und die IP bleibet wohl auch recht lange die selbe, weil der Rechner ja durchläuft und daher sein DHCP-Lease vermutlich jedes mal neu zugeteilt kriegt.
    Was aber, wenn sich die IP doch mal ändert ? Weil ohne das 192.168.1.6: geht's ja nicht.
    Kann man das auch anders ausdrücken ?


    Danke und Gruß,
    Markus

  • Habe ich das in dem Kommentar falsch verstanden ? Da steht "--remote=<ip>:<port> (default is all interfaces)" daher dachte ich, ich kann den ip-Teil weglassen.

    Ich denke mit Interface ist hier eth0 bzw. enp2s0 oder wie die LAN-Karte eben heißt gemeint. Interface ist also eher das Device.

    Weil ohne das 192.168.1.6: geht's ja nicht.
    Kann man das auch anders ausdrücken ?

    Ich bin mir nicht sicher, aber das könnte das gleiche Problem sein, wie beim live Plugin
    Dort hilft 0.0.0.0 als IP.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!