Beiträge von atl

    Hallo.


    Ich habe mal die Version 1.4.0 des Plugins gebaut und dann startete der VDR nicht mehr. Im /var/log/syslog fand ich folgenden Fehler, der mich auf die Spur brachte:


    Nach dem ich dann die cecremote.xml wie im Folgenden angepasst hatte, läuft es jetzt:


    Wichtig in der Zeile <onceccommand command="STANDBY" initiator="TV"> ist wohl tatsächlich der rot markierte Bereich. Da ich diesen Teil von hier habe, war das schon mal drin und funktionierte nicht. Ob das dann jetzt tatsächlich an der Version 1.4.0 liegt, dass es funktioniert, oder ich noch einen anderen Fehler hatte, kann ich mittlerweile nicht mehr sagen.

    Hallo.


    Ich versuche schon eine Weile den VDR dazu zu Übereden, beim Drücken der Power/Standby-Taste an der FB des Samsung TV den VDR (Raspberry Pi) herunter zufahren. Leider bekomme ich beim Drücken der Taste im Log nur den Hinweis 'CEC Command 54 : standby', der Fernseher geht in den Standby aber der VDR läuft munter weiter. Per 'svdrpsend HITK power' kann ich den VDR (und Rechner) sauber herunterfahren.
    Wie muss ich das CECremote-Plugin konfigurieren, damit der VDR auch den Rechner herunter fährt?


    Meine /etc/vdr/plugins/cecremote/cecremote.xml:


    Ausgabe von svdrpsend plug cecremote LSTD

    Code
    1. root@VDRpi-dev:~# svdrpsend plug cecremote LSTD
    2. 220 VDRpi-dev SVDRP VideoDiskRecorder 2.2.0; Wed Feb 22 23:25:58 2017; UTF-8
    3. 214-Available CEC Devices:
    4. 214- Device 0 path: Raspberry Pi port: RPI Firmware 0001
    5. 214-
    6. 214-Active Devices:
    7. 214- 0# TV @0000 TV TV Samsung on
    8. 214- 1# Recorder 1 @2200 VDR VDR VDR
    9. 214 5# Audio @2000 RECEIVER RECEIVER Pioneer on
    10. 221 VDRpi-dev closing connection


    Ausgabe von journalctl | grep cecremote:

    Ein Punkt noch den ich aus eigener Erfahrung kenne, Virtualisierung mit Xen, das Laden der FW aus dem Systemspace in der VM war immer eine Herrausforderung. Einfacher sind DVB Karten, die keine FW aus Datei benötigen.

    Bei der Container-Variante ist der Vorteil, dass die Hardware nicht virtualisiert wird. D.h. solche Sachen wie PCI-Passthrough und VT-d spielen hier keine Rolle. In diesem Fall muss man einfach nur die Hardware auf dem Host ans Laufen bekommen und die Zugriffsrechte für den Container auf das Device erlauben.


    Den Hinweis auf den Thread hatte ich gegeben, da die Treiber aktueller und vollständiger waren, als das was beim 2.6er Kernel des Proxmox 3.x dabei war. Evtl. ist es ja hier in diesem Fall auch so, da die 5.5er DD schon etwas betagter ist. Ich weiß nicht genau, was wirklich im aktuellen Proxmox-Kernel ist.


    ByE...

    Hi.


    Genau dein geplantes Szenario habe ich hier am Laufen (siehe Signatur), allerdings mit einer CineS2 (V6). Diese wird zum Glück von Proxmox 4 voll unterstützt. Allerdings hatte ich früher unter Proxmox 3.x das gleiche Problem, dass die Karte nur zum Teil erkannt wurde. Ich habe damals die Treiber aus diesem Thread kompiliert und installiert. Damit ich mir damit den physikalischen Proxmox-Host nicht zu "mülle", habe ich noch eine VM mit Proxmox installiert, in der ich dann alle notwendigen Pakete installiert habe, die man zum Bauen der Treiber benötigte. Nachdem ich die kompilierten Treiber dann auf dem physikalischen Host installiert hatte, lief die Karte und ich konnte sie in den Container durchreichen.

    Betrifft das deine Raspberry Pi? Dann würde ich vermuten, dass die die Systemzeit noch nicht gesetzt hatten, als der VDR gestartet wurde...

    Ja, genau. Es betrifft die Pi's. Das könnte durchaus sein, dass es damit zusammenhängt. Dann weiß ich schon mal, wo ich suchen muss.


    Auf den Testclients wird der VDR mittels systems-Skript gestartet. In welchen Sektor muss dort der Eintrag After=systemd-timesyncd.service eingefügt werden, etwa so?

    Hallo.


    seit einigen Wochen starten meine VDR-Clients immer öfter direkt mit der Meldung, dass der VDR sich "in 5:00 Minuten ausschaltet". So richtig reproduzieren läßt es sich nicht. Die MinUserInactivity habe ich auf 160 gesetzt. Ich vermute, dass es etwas mit Timern zu tun hat. Normalerweise kennt der VDR eine Logik, um zu unterscheiden, ob er wegen eines Timers gestartet ist oder manuell gestartet wurde und fährt bei Nicht-Benutzung wieder runter. Nun ist es so, dass meine Clients ja keine Aufnahmen machen, sondern dies per RemoteTimer-Plugin an den Server delegieren. Damit ist dieses Verhalten bei den Clients unerwünscht.
    Gibt es eine Möglichkeit dieses Verhalten abzuschalten?


    ByE...

    Hi.

    Das restfulapi-Plugin liefert dir unter anderem den aktuell wiedergegebenen Kanal bzw. die laufende Wiedergabe einer Aufnahme - mit einem kleinen Python-Skript kommt man so an den Status Live-TV oder Wiedergabe einer Aufnahme:

    Ich bin endlich dazu gekommen, damit herum zuspielen. Und diese Lösung ist eine klasse Basis für meine Anforderungen. Danke. :)

    Nicht genau das was du willst, aber bei mir hier wird ein VDR-FIleserver (mein ganz normaler Desktop) von den Clients per WoL geweckt, haengt dann im Anmeldeschirm, und fuehrt ein Skript aus, das ihn, wenn kein Client mehr anpingbar ist, auch wieder runterfaehrt. Siehe hier:
    Altes Problem wieder da: Rechner (vdr Fileserver) automatisch wieder runterfahren wenn Clients offline sind

    Diesen Thread kenne ich. So in der Art nutze ich das im Moment. Ich möchte aber den Status der VDR-Clients etwas genauer abfragen, als lediglich ob noch pingbar. Ich hatte nämlich auch schon, dass der VDR-Prozeß gestorben ist und dann der Client (und somit auch der Server) die ganze Nacht durch lief.


    Ich habe im Moment aber noch keine Zeit gehabt, mir das restfulapi-Plugin auf dem Raspi anzuschauen bzw. erst einmal dafür zu bauen. :(


    ByE...

    Was ist denn das Ziel des ganzen? Eine Art Lifeguard-Addon für den Fileserver, damit er nicht abschaltet, wenn jemand gerade eine Aufnahme ansieht?

    Yepp, genau oder pausiert, das hat der Fileserver in der Vergangenheit öfter mal ignoriert und ist heruntergefahren.


    Das restfulapi-Plugin liefert dir unter anderem den aktuell wiedergegebenen Kanal bzw. die laufende Wiedergabe einer Aufnahme

    Ah, danke. Mit diesem Plugin habe ich mich noch nicht so sehr beschäftigt. Dann baue ich das mal für den Raspberry und schaue es mir mal an. :)


    Alternativ könnte man vielleicht auch das live-Plugin auf den Clients installieren und den Inhalt der Wiedergabe-Box parsen.

    Auch eine Variante, aber ich habe im Moment weder das EPGSeach- noch das Live-Plugin auf den Clients, um die Raspberry-Resourcen zu schonen. :)


    ByE...

    Hallo,


    da meine RaspiPI's als VDR-Clients mittlerweile recht gut laufen, werden es immer mehr hier im Haushalt. Wie in der Signatur geschrieben steht, habe ich einen Server, der das TV-Signal per Streamdev-Server-Plugin den Clients zur Verfügung stellt. Die Aufnahmen werden von einem Dateiserver (nicht VDR) per NFS zur Verfügung gestellt und am Client per Avahi-Linker gemountet.


    Jetzt hätte ich gerne die Möglichkeit per Skript abzufragen, was die Clients gerade tun. Ziel ist es zu wissen, ob am Client gerade ein TV-Sender läuft oder eine Aufzeichnung per NFS geschaut wird und welcher Wiedergabe-Status (Wiedergabe, Pause,...) / Wedergabeposition gerade aktuell ist. Hat jemand dazu Ideen / Tipps wie ich das per Shell-Skript abfragen kann? Danke.


    ByE...

    Mittlerweile läuft mein VDR-Server in einem OpenVZ-Container auf dem Proxmox-Server und nutzt einen SAT>IP-Server (Triax TSS 400) mittels SAT>IP-Plugin. Auch diese Lösung hat so ihre Probleme, doch läuft sie besser als die PCI-Passthrough-Geschichte.


    Kurzer Nachtrag: Da die SAT>IP-Lösung nicht zufriedenstellend lief, habe ich mittlerweile eine CineS2 V6 mit zusätzliche Duoflex an meinen VDR im OpenVZ-Container durchgereicht. Seitdem läuft das Ganze problemlos! :D

    Da ich alle diese Scripten stark an meine Umgebung angepaßt habe macht es keinen Sinn, diese hier komplett zu veröffentlichen. Aber ich hoffe, dass das Prinzip klar geworden ist.

    Ja, danke. Das reicht schon. In ähnlicher Weise nutze ich das auch. Interessant finde ich die Idee mit der Queue. Kannst du diese Skripte auch über den VDRadmin-AM ausführen? Da habe ich nämlich noch Probleme mit den Rechten, da VDR und VDRadmin-AM unter unterschiedlichen Benutzern laufen. :S

    Kommentiere doch die letzte Zeile mal aus (mittels '#') und schaue, was dann passiert. Wenn er dann gar nicht mehr runterfährt, scheinen die Zeilen davor das Problem zu sein.
    Dann könntest du davor noch folgende Zeile einbauen:

    Code
    1. svdrpsend hitk power

    Die sagt dem VDR noch auf einem zweiten Weg herunter zu fahren, zum Testen.

    Da gibt es 2 Möglichkeiten:
    1. compat.h entsprechend korrigieren, damit es durchläuft.
    2. Den Treiber, der nicht kompiliert (altera-lpt.o) rauswerfen.


    Beide Optionen waren notwendig, da Option 2 alleine dazu führte, dass nach dem Deaktivieren des einen Treibers der nächste Probleme bereitete. Also habe ich das /usr/src/media_build_experimental/v4l/compat.h wie folgt gepatcht:

    Dann musste noch folgender Eintrag in der .config auf n gesetzt werden:

    Code
    1. CONFIG_MEDIA_TUNER_XC2028=n


    Danach lief auch make und make install durch und ich konnte die Cine S2 V6 an meinen Container-VDR durchreichen. :D


    Besten Dank noch mal!