yavdr ansible

holymoly · 25. November 2018

Zitat von seahawk1986

Falls da jemand Patches erarbeiten will, baue ich die gerne ein.

Vielleicht findet sich ja jemand, der da weiterhelfen kann.

udo1toni · 26. November 2018

Hi, leider ist meine GraKa GT630 gestern gestorben.

Die in der Kiste liegende GT730 (Asus, 1GB) macht mit yavdr 0.62 arge Probleme,

HD-Programme funktionieren mit xineliboutput, aber SD läuft mit ca. 12 Bildern pro Sekunde. Mit softhddevice funktioniert es eigentlich gar nicht (HD-Programme laufen mit Zeitlupe, nachdem der Puffer voll ist, bricht das Bild kurz zusammen)

Also habe ich jetzt bionic mit yavdr ansible an den Start gebracht, und nach einigem Gezicke läuft es erstaunlich gut.

Punkt eins ist, dass ich nicht herausfinden konnte, wie ich die Auflösung von UHD auf Full HD ändern kann (also außer, die Xorg.conf händisch anzupassen). Fehlt da noch was, oder hatte ich nur Tomaten auf den Augen?

Punkt zwei ist, dass das System natürlich von jetzt auf gleich laufen muss, und da fehlen ein paar Annehmlichkeiten, insbesondere yavdr-hostwakeup.

Vermutlich fehlt mir nur der Punkt, wo ich das (ohne die Webgui, die gibt's ja noch nicht) konfigurieren kann. Allerdings ist der Menüpunkt auch noch nicht Menü...

holymoly · 26. November 2018

Hallo seahawk1986,

wäre es vielleicht möglich, auch noch das noepg-plugin für yavdr ansible, bereitzustellen?

mfg

seahawk1986 · 26. November 2018

Zitat von udo1toni

Punkt eins ist, dass ich nicht herausfinden konnte, wie ich die Auflösung von UHD auf Full HD ändern kann (also außer, die Xorg.conf händisch anzupassen).

Bislang kann man sonst nur dem Playbook mitgeben, welche Auflösung bevorzugt werden soll - dazu legt man eine host_vars/localhost.yml im yavdr-ansible Verzeichnis an und setzt die bevorzugten Auflösungen, also z.B. Full-HD an erster Stelle:

Code: host_vars/localhost.yml

preferred_resolutions:
  - 1920x1080
  - 3840x2160
  - 7680x4320
  - 1280x720
  - 720x576

Mit sudo ansible-playbook yavdr07.yml -b -i 'localhost_inventory' --connection=local --tags="yavdr-xorg" kann man dann die Bildschirmkonfiguration neu schreiben lassen.

Zitat von udo1toni

Fehlt da noch was, oder hatte ich nur Tomaten auf den Augen?

Nein, da fehlt noch so einiges...

Zitat von udo1toni

Punkt zwei ist, dass das System natürlich von jetzt auf gleich laufen muss, und da fehlen ein paar Annehmlichkeiten, insbesondere yavdr-hostwakeup.

Vermutlich fehlt mir nur der Punkt, wo ich das (ohne die Webgui, die gibt's ja noch nicht) konfigurieren kann. Allerdings ist der Menüpunkt auch noch nicht Menü...

Die menuorg-Integration fehlt noch und das menuorg-Plugin wird nicht vorinstalliert.

yavdr-hostwakeup habe ich hochgeladen, das lässt sich als Paket hostwakeup installieren und der Systemd-Service (wird automatisch gestartet) heißt hostwakeup.service.

Statt da jedes Mal die menuorg.xml neu zu schreiben, würde ich die Host-Liste fürs OSD dynamisch abfragen:

Python: /usr/local/bin/wol_osd_menu

#!/usr/bin/env python3
import socket
import sys

import pydbus2vdr
import pydbus
from gi.repository import GLib

QUESTION="Select WOL target"

def main():
    bus = pydbus.SystemBus()
    hostwakeup = bus.get('de.yavdr.hostwakeup', '/Hosts')
    hostname = socket.gethostname() 
    hosts = [host for host in hostwakeup.List() if hostname != host]
    vdr = pydbus2vdr.DBus2VDR(bus, watchdog=True)
    def on_response(*args, **kwargs):
        # example args:
        # (':1.29', '/Remote', 'de.tvdr.vdr.remote', 'AskUserSelect', ('Select WOL target', 1))
        question, answer = args[4]
        if question != QUESTION:  # it's a signal for another AskUserSelect call...
            return
        nonlocal hosts
        if answer < 0 or answer >= len(hosts):
            sys.exit("no entry selected")
        nonlocal hostwakeup
        host = hosts[answer]
        hostwakeup.Wakeup(host)
        print(f"sent Magick Packet to: {host}", file=sys.stderr)
        sys.exit()

    vdr.Signals.subscribeAskUserSelect(on_response)

    def ask_user(hosts):
        nonlocal vdr
        vdr.Remote.AskUser(QUESTION, hosts)
        return False

    GLib.idle_add(ask_user, hosts)

    loop = GLib.MainLoop()
    try:
        loop.run()
    except KeyboardInterrupt:
        loop.quit()
    except Exception as e:
        loop.quit()
        raise SystemExit(e)


if __name__ == '__main__':
    main()

Alles anzeigen

Man kann dann in den Dateien, aus denen die commands.conf beim Start des VDR zusammengebaut wird (z.B. in der /usr/share/vdr/command-hooks/commands.custom.conf) so einen Eintrag anlegen (für menuorg sollte der selbe Befehl funktionieren, nur die Syntax für die Einträge ist etwas anders):

Code

Wake on Lan                     : echo /usr/local/bin/wol_osd_menu | at now

udo1toni · 26. November 2018

Zitat von seahawk1986

yavdr-hostwakeup habe ich hochgeladen, das lässt sich als Paket hostwakeup installieren und der Systemd-Service (wird automatisch gestartet) heißt hostwakeup.service.

Ah. Sehe ich das richtig, dass diese Liste dann automatisch erzeugt wird, sobald dieser Dienst auf allen Geräten läuft? Sehr Cool. Allerdings habe ich meinen vdr-server momentan noch auf yavdr0.6 laufen. Kann ich einen Eintrag für den hostwakeup auch manuell anlegen?

seahawk1986 · 26. November 2018

yaVDR 0.6 kam bereits mit yavdr-hostwakeup als Abhängigkeit von yavdr-essential (aber wir haben es nicht genutzt), die sollten sich also gegenseitig sehen können.

udo1toni · 27. November 2018

So, hab gerade ein bisschen rumprobiert und ich habe zwar noch keinen Menüpunkt, aber schon mal hostwakeup zum Laufen gebracht.

Auf dem Ansible System reicht das Installieren des Pakets plus Start des Dienstes.

Auf dem alten System ist der Dienst zwar vorhanden, aber nicht korrekt konfiguriert, so dass er nicht startet.

Da ich mich nie mit upstart beschäftigt habe und es ja auch nur einmalig starten muss (... der Cache bleibt erhalten, wenn weitere Rechner dazu kommen, werden die vermutlich eh mit Ansible laufen), habe ich es einfach schmutzig per Hand gestartet.

Dabei beschwerte sich hostwakeup darüber, kein eth0 zu finden. ip a ergibt auch, dass mein Interface p2p1 heißt, also einmalig sudo hostwakeup -i p2p1 eingeben, schon rattert die Liste runter.

Interessanterweise wird auch ein yavdr0.6 Client gelistet, der auf dem Ansible System nicht von selbst auftauchte.

Der Aufruf oben hat aber gleich die vollständige Liste an alle Clients geschickt, so dass nun auf dem Ansible System auch alle vdr-Clients mit ihren von mir vergebenen Namen auftauchen, extrem cool!

Das nur mal so als Zwischenstand...

seahawk1986 · 27. November 2018

Zitat von udo1toni

Da ich mich nie mit upstart beschäftigt habe und es ja auch nur einmalig starten muss (... der Cache bleibt erhalten, wenn weitere Rechner dazu kommen, werden die vermutlich eh mit Ansible laufen), habe ich es einfach schmutzig per Hand gestartet.

Da gibt es sogar schon eine über DBus erreichbare Methode, um einen neuen Host und seine Mac-Addresse hinzuzufügen: https://github.com/yavdr/yavdr…ython3/hostwakeup.py#L267 - da müsste ich mal hostwakeupctl überarbeiten, damit man bei Bedarf Hosts hinzufügen kann, auf denen yavdr-hostwakeup nicht läuft.

Zu Fuß ginge das momentan so:

Code

dbus-send --system --type=method_call --dest='de.yavdr.hostwakeup' --print-reply \
  '/Hosts' 'de.yavdr.hostwakeup.Add' string:HOSTNAME string:"DE:AD:BE:EF:FE:ED"

Ich habe gerade noch auf einem frischen Testsystem gemerkt, dass die Systemd-Unit aktuell noch das falsche Kill-Signal sendet, wodurch die Liste der Hosts beim Beenden nicht gespeichert wird. Im [Service] Abschnitt der /lib/systemd/system/hostwakeup.service fehlt noch ein

KillSignal=SIGINT

Ich lasse gleich noch ein aktualisiertes Paket bauen, das das nachrüstet.

udo1toni · 27. November 2018

seahawk1986 Wie immer ist Deine Lösung super!

Die dynamische Variante ist natürlich viel schicker als eine fest eingestellte Liste, auch wenn die Liste trotzdem ziemlich statisch sein dürfte

Paulaner · 27. November 2018

ALSA für VDR-Audio einsetzen:

Nach dem ich bereits hier im Thread im Beitrad #329 und dann auch im Beitrag #339 meine Probleme mit Pulseaudio beschrieben habe, hatte ich gestern vergeblich versucht ALSA für den VDR einzusetzen, aber ich bekomme es einfach nicht hin!

Warum kein Pulseaudio:

Was mir bei Pulseaudio immer fehlte war die Wiedergabe der Highres-Audioformate Dolby TruHD und DTS-HD Master.

Alles andere, Stereo, Dolby und DTS hingegen funktionieren einwandfrei!

Wie ich nun inzwischen herausgefunden habe, siehe z. B. hier kann Pulseaudio die Highres-Audioformate nicht wiedergeben und somit ist für mich damit Pulseaudio keine Option mehr. Und deswegen möchte ich nun auch in yavdr-ansible wieder das Audio über ALSA laufen lassen.

Nach der Deinstallation von Pulseaudio, siehe hier im Beitrag #339 gibt es nun aber das Problem, dass ich im VDR keinen Ton mehr habe. Wenn ich KODI hingegen starte, dann funktioniert Audio perfekt, inklusive aller Highres-Audioformate.

Ich habe gestern den ganzen Abend vergeblich versucht mittels ALSA dem VDR einen Ton zu entlocken, was mir leider nicht gelungen ist.

Code: aplay -l

aplay -l
**** Liste der Hardware-Geräte (PLAYBACK) ****
Karte 0: NVidia [HDA NVidia], Gerät 3: HDMI 0 [HDMI 0]
  Sub-Geräte: 0/1
  Sub-Gerät #0: subdevice #0
Karte 0: NVidia [HDA NVidia], Gerät 7: HDMI 1 [HDMI 1]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0

Hier noch die entsprechenden Konfigurationsdateien:

Code: /etc/asound.conf

pcm.!default {
    type hw
    card NVidia
    device 7
}

ctl.!default {
    type hw
    card NVidia
}

Code: softhdcuvid.conf

[softhdcuvid]
-D
#-f
-a hw:NVidia,7
-p hw:NVidia,7

Eigentlich sollte/müsste es nun funktionieren und der VDR sollte einen Ton von sich geben, tut er aber nicht.

Deswegen muss ich Euch hier nochmals nerven und hoffe Ihr könnt mir helfen, wie ich das zum Laufen bekomme!

Gibt es da noch irgendwo ein Script oder einen Service, der mir hier in die quere kommt?

Paul

davie2000 · 27. November 2018

Bin da zwar kein Profi, aber ich glaube, mich zu erinnern, dass man bei ALSA mittels "alsamixer" überprüfen sollte, ob alle Kanäle auch wirklich "unmuted" (also eingeschaltet) sind. Viel Glück!

Paulaner · 27. November 2018

Den Alsamixer hatte ich bereits überprüft und beide Digital-Ausgänge sind "unmuted".

Daran sollte es also nicht liegen!

Das komische ist ja, dass es mit yavdr-0.6 (liegt auf dev/sdc1) das ganze wunderbar mit ALSA funktioniert, nur eben nicht mit yavdr-ansible (liegt auf dev/sdc2).

Deswegen vermute ich ja, dass es irgendwo noch ein Script, eine Konfiguration o.ä. gibt, was hier für mich Probleme bereitet.

mini73 · 27. November 2018

Lautstärke ist im alsamixer auch hochgedreht?

Lars

Paulaner · 27. November 2018

Zitat von mini73

Lautstärke ist im alsamixer auch hochgedreht?

???

Da nur das HDMI-Kabel verbunden ist gibt es keine analogen Ausgänge, sondern nur 2 digitale Ausgänge: S/PDIF und S/PDIF 1

Bei denen kann man nur MM für "muted" oder 00 für "unmuted" einstellen, da gibt es nichts zum "hochdrehen" und beide Ausgänge sind auf 00 gesetzt.

Paulaner · 27. November 2018

Jetzt läuft es!

Oh Mann, da bin ich jetzt nur durch Zufall drauf gekommen.

Beide VDRs: yavdr-0.6 und yavdr-ansible laufen ja auf demselben PC nur auf 2 unterschiedlichen Partitionen und nutzen also dieselbe Hardware. Somit habe ich bei beiden immer, wo es sinnvoll ist, die gleichen Konfigurationen eingestellt, vor allem weil es ja beim "alten" yavdr-0.6 sofort auf Anhieb funktionierte.

Ein aplay -L vom yavdr-0.6 liefert diese Ausgabe:

Code

aplay -L
null
    Discard all samples (playback) or generate zero samples (capture)
pulse
    PulseAudio Sound Server
hdmi:CARD=NVidia,DEV=0
    HDA NVidia, HDMI 0
    HDMI Audio Output
hdmi:CARD=NVidia,DEV=1
    HDA NVidia, HDMI 1
    HDMI Audio Output
dmix:CARD=NVidia,DEV=3
    HDA NVidia, HDMI 0
    Direct sample mixing device
dmix:CARD=NVidia,DEV=7
    HDA NVidia, HDMI 1
    Direct sample mixing device
dsnoop:CARD=NVidia,DEV=3
    HDA NVidia, HDMI 0
    Direct sample snooping device
dsnoop:CARD=NVidia,DEV=7
    HDA NVidia, HDMI 1
    Direct sample snooping device
hw:CARD=NVidia,DEV=3
    HDA NVidia, HDMI 0
    Direct hardware device without any conversions
hw:CARD=NVidia,DEV=7
    HDA NVidia, HDMI 1
    Direct hardware device without any conversions
plughw:CARD=NVidia,DEV=3
    HDA NVidia, HDMI 0
    Hardware device with all software conversions
plughw:CARD=NVidia,DEV=7
    HDA NVidia, HDMI 1
    Hardware device with all software conversions

Alles anzeigen

Dazu habe ich dann in der softhddevice.conf folgende Parameter eingestellt:

Code

[softhddevice]
-D
-a hw:NVidia,7
-p hw:NVidia,7

Da das aplay -L bei yavdr-ansible genau die gleiche identische Ausgabe wie beim "alten" yavdr-0.6 lieferte, habe ich hier also auch bei softhdcuvid.conf die gleichen Parameter genommen. Und damit gab es eben keinen Ton bei yavdr-ansible!

Jetzt hatte ich dann nochmals das aplay -l bei beiden VDRs ausgeführt und genau verglichen und da ist mir dann der Unterschied aufgefallen:

Code

                yavdr-0.6

aplay -l
**** Liste der Hardware-Geräte (PLAYBACK) ****
Karte 0: NVidia [HDA NVidia], Gerät 3: HDMI 0 [HDMI 0]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0
Karte 0: NVidia [HDA NVidia], Gerät 7: HDMI 1 [HDMI 1]
  Sub-Geräte: 0/1
  Sub-Gerät #0: subdevice #0



                yavdr-ansible

aplay -l
**** Liste der Hardware-Geräte (PLAYBACK) ****
Karte 0: NVidia [HDA NVidia], Gerät 3: HDMI 0 [HDMI 0]
  Sub-Geräte: 0/1
  Sub-Gerät #0: subdevice #0
Karte 0: NVidia [HDA NVidia], Gerät 7: HDMI 1 [HDMI 1]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0

Alles anzeigen

Bei den "Sub-Geräte:" ist die Reihenfolge anders!

Und so habe ich jetzt einfach mal an Stelle vom Device 7 das Device 3 genommen und schon war der Ton da :

Code

[softhdcuvid]
-D
-a hw:NVidia,3
-p hw:NVidia,3

Warum jetzt die Device zwischen den beiden VDRs unterschiedlich zugewiesen werden, weiß ich nicht, aber nun läuft es wenigstens!

Paul

mini73 · 28. November 2018

Ist vermutlich eine Treiber-Geschichte.

Lars.

Paulaner · 28. November 2018

Zitat von mini73

Ist vermutlich eine Treiber-Geschichte.

Yepp, vermute ich auch!

Man sollte eben auch immer das Kleingedruckte lesen, dann erspart man sich 'ne Menge Arbeit!

Paul

haraldov · 1. Dezember 2018

Zitat

The playbook does not yet handle the automatic display configuration for Intel IGPs, so you need to configure Xorg yourself if you want to use a mode with 50Hz refresh rate.

Tried to use fnu 's approch to make a xorg.conf, but did not work for me. I think it was something wrong with the xorg.conf file I made.

But I found another way which works to give a 50 HZ refresh rate.

I followed this wiki to make a xorg.conf https://wiki.archlinux.org/ind…ng_undetected_resolutions.

First we run cvt to get the Modeline for the resolution we want:

Code

hts@vdrsrv02:~$ cvt 1920 1080 50
# 1920x1080 49.93 Hz (CVT 2.07M9) hsync: 55.62 kHz; pclk: 141.50 MHz
Modeline "1920x1080_50.00"  141.50  1920 2032 2232 2544  1080 1083 1088 1114 -hsync +vsync

Once a suitable resolution is found using cvt, the mode can be permanently added by creating an entry in /etc/X11/xorg.conf.d/

Code

/etc/X11/xorg.conf.d/10-monitor.conf
-----------------------------------------------------------------------------------------------
Section "Monitor"
    Identifier "HDMI1"
    Modeline "1920x1080_50.00"  141.50  1920 2032 2232 2544  1080 1083 1088 1114 -hsync +vsync
    Option "PreferredMode" "1920x1080_50.00"
EndSection

Section "Screen"
    Identifier "Screen0"
    Monitor "HDMI1"
    DefaultDepth 24
    SubSection "Display"
        Modes "1920x1080_50.00"
    EndSubSection
EndSection

Section "Device"
    Identifier "Device0"
    Driver "intel"
EndSection

Alles anzeigen

When the X server is restarted, you should be able to set the new resolution.

AndreasR81 · 3. Dezember 2018

ich habe das gleiche Problem, nur wenn ich das so einstelle bootet der Rechner zur Shell und das in 50p?!

soundscrazy · 24. Dezember 2018

Bei mir steht eine Kompletterneuerung an (ich bin noch auf einer gut funktionierenden yaVDR 0.5) Umgebung unterwegs und habe mir deshalb yavdr ansible angesehen - einfach, weil es ein tolles Konzept ist und auch schon sehr, sehr gut funktioniert - einfach Spitze.

Was habe ich bisher versucht: Server auf Basis J3160 Basis, Digital-Devices Cine S2 6.5 + DuoFlex + Single CI + Mascom alphacrypt classic + ORF Karte) - diverse Serverdienste laufen permanent - VDR Service + Treiber für DD-Karten (Stromverbrauch) werden per WoL Paket gestartet - funktioniert.

Test-Client auf Basis Asus AT5IONT-I (Nvidia ION -legacy!) - Einrichtung hat perfekt funktioniert (inkl. Nachinstallation IRMPLircd, weil das zuerst verwendete Kabel offensichtlich nur ein Ladekabel war).

Jetzt zu meinen Fragen:

Am Server installiert: Plugin SVDRPOSD

Was ich jetzt so nicht verstehe (sorry, wenn ich da was überlesen habe): das Gegenstück remoteOSD gibt es nicht im Repository ? - und zu meinem Pech auch kein EPGSync ? Wenn ich das richtig verstehe, kann ich ja nicht den EPG des Servers (ohne Internetabrufe, also nur die VDR Stream EPGDaten) in den EPGD verpflanzen und mit EPG2VDR distributieren ?.
Ich habe auch das OSD2Web als temporären Ersatz für das RemoteOSD versucht - aber das entspricht nicht meinem Ansatz.

Kann mir wer den Schubs in die richtige Richtung verpassen ?

Schöne Feiertage

yavdr ansible

Jetzt mitmachen!

Teilen