Beiträge von seahawk1986

    Ist das wirklich so?


    Ok, dann habe ich habe ich das durcheinander gebracht. Den Patch von Udo Richter habe ich für VDR-Versionen > 2.2.0 aber nicht mehr gesehen - gibt es da etwas in der Richtung oder bleibt einem dann nur das spätere Remuxen mit naludump, mkvtoolnix usw.?

    Das hängt davon ab, wie gut das bei den genutzten Sendern funktioniert. Ich habe die letzten Jahre mir Vor- und Nachlaufzeit gearbeitet, die einzigen Sender, die häufig unerwartet Sendungen nach hinten verschieben (oder ganz streichen) sind ARD und ZDF, wenn es mal wieder Anlass für einen Brennpunkt oder ähnliches gibt...

    Oder ändert das Live-Plugin noch irgendwas an den default Einstellungen wenn ich Aufnahmen darüber plane?


    Ich merke gerade auch Änderungen in der setup.conf (mit gestopptem VDR) an

    MarginStart = 7

    MarginStop = 15

    was glaube ich die Zeit vor und nach der Aufnahme ist um sie zu verlängern wird im Live Plugin komplett ignoriert beim Timer anlegen.

    Der VDR addier die Vor- und Nachlaufzeit automatisch auf die Timer auf (https://projects.vdr-developer…vdr.git/tree/timers.c#n59), wenn VPS nicht aktiviert ist (UseVps = 0), ansonsten versucht er eine zeitgenaue Aufnahme über den Sendungsstatus (was oft nicht besonders gut klappt, wenn die Sender keine brauchbaren Statuswechsel senden).

    Deine /etc/vdr/setup.conf ist aber schon ein Link auf die eigentlich vom VDR genutzte Datei /var/lib/vdr/setup.conf, oder?

    Code
    1. ls -l /etc/vdr/setup.conf
    2. lrwxrwxrwx 1 root root 23 Nov 15 18:56 /etc/vdr/setup.conf -> /var/lib/vdr/setup.conf

    Du kannst du Einstellungen auch über dbus2vdr bei laufendem VDR setzen:

    Kann man die gesetzten Einstellungen des VDR über Telnet irgendwie abfragen ?

    Nicht über Telnet, aber zum Beispiel über das dbus2vdr-Plugin:

    vdr-dbus-send /Setup setup.Get string:MaxVideoFileSize


    Mit den Vorgabeinstellungen sieht die Antwort so aus:

    Code
    1. $ vdr-dbus-send /Setup setup.Get string:MaxVideoFileSize
    2. method return time=1547050922.602827 sender=:1.26 -> destination=:1.41 serial=609 reply_serial=2
    3. variant int32 2000
    4. int32 900
    5. string "getting MaxVideoFileSize"

    Das ist normal - das Standard-Aufnahmeverzeichnis bekommt der VDR beim Kompilieren aus der Make.config und die haben wir für das VDR-Paket in yaVDR so angepasst, dass VIDEODIR = /srv/vdr/video gesetzt wird, daher setzen wir das nicht noch mal extra in der beigelegten Konfigurationsdatei.

    Das Aufnahmeverzeichnis kann man dem VDR mit dem Argument -v (bzw. --video) mitgeben, also z.B.:

    Code: /etc/vdr/conf.d/02-vdr-video.conf
    1. [vdr]
    2. -v /srv/vdr/video.00

    Da bei yaVDR sich ein Haufen Skripte, Konfigurationsdatien und Pakete auf den Pfad /srv/vdr/video beziehen, ist es IMHO meistens sinnvoller das Verzeichnis per mount-bind an der richtigen Stelle einzuhängen oder zumindest einen Symlink anzulegen, der von /srv/vdr/video auf das neue Aufnahmeverzeichnis zeigt.

    Ich hatte zwei Displays eingerichtet, den TV(dafür gibt es keine EDID, ist das OK?)

    Solange der immer als angeschlossen erkannt wird, sollte das keine Probleme machen. Die EDID wird bei yaVDR hinterlegt, damit der X-Server auch dann "normal" Starten kann, wenn das Auslesen der EDID vom Monitor nicht klappt, z.B. weil jemand den Stecker gezogen hat.


    Das Tauschen der Displays geht sicherlich auch eleganter. Ist dafür schon etwas vorgesehen?

    Ja, man kann das Display über das yavdr-frontend Skript umschalten, ein Skript (ausführbar machen!), das zwischen den beiden möglichen Einstellungen hin- und herschaltet, könnte das z.B. so aussehen:

    Shell-Script: /var/lib/vdr/bin/switch_displays
    1. #!/bin/bash
    2. source <(systemctl --user show-environment)
    3. [[ "$DISPLAY" =~ \.1$ ]] && DISPLAY="${DISPLAY%.1}.0" || DISPLAY="${DISPLAY%.0}.1"
    4. frontend-dbus-send stop
    5. systemctl --user stop osd2web
    6. frontend-dbus-send setDisplay "$DISPLAY"
    7. systemctl --user start osd2web
    8. frontend-dbus-send start

    Das Skript muss vom User vdr mit Zugriff die Systemd-User Session ausgeführt werden, also könnte man es z.B. in die menuorg.xml (wenn man man das menuorg-Plugin nutzt), die /etc/vdr/command-hooks/commands.custom.conf (dann landet es in der commands.conf und damit in den "Befehlen" des VDR) oder für irexec in die /var/lib/vdr/.lircrc eintragen.


    Wenn du es zum Testen aus der Shell aufrufen willst, ginge das so: sudo -u vdr DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/666/bus /var/lib/vdr/bin/switch_displays


    Damit das auch für KODI funktioniert, braucht man noch ein Skript /usr/bin/set-kodi-display , das die Bildschirm-Einstellungen in der Konfigurationsdatei anpasst.

    Für KODI 17 braucht es diese Variante: https://raw.githubusercontent.…/usr/bin/set-kodi-display

    Und für KODI 18 muss das so aussehen (falls das nicht klappt, weil die wieder am Aufbau der Konfigurationsdatei gebastelt haben, bitte Bescheid sagen): https://raw.githubusercontent.…r/bin/set-kodi-display-v2

    Sollte ich, auch wenn ich nur die Wiedergabe testen will, zur Installation besser zum Beispiel einen Sundtek USB Stick "durchreichen", um ein Empfangsgerät zu haben?

    Softhddevice funktioniert ohne VDPAU- oder VAAPI-fähige GPU nicht - wenn yavdr-ansible bei der Installation eine VirtualBox-Umgebung erkennt, nutzt es xineliboutput als Ausgabeplugin, dessen OSD-Darstellung (und die Videowiedergabe) funktioniert auch, wenn der VDR keine Kanalliste und keine Tuner hat. Mit VirtualBox 6.0.0 skaliert allerdings das OSD nicht richtig, mit VirtualBox 5.22.x klappt das ganze besser.


    Die Sundtek-Unterstützung bei yavdr-ansible ist noch nicht ganz fertig, grundsätzlich hast du aktuell folgende Möglichkeiten, nachdem du den Sundtek-Treiber (Paket dvb-driver-sundtek) installiert hast:

    • vdr-plugin-dynamite und vdr-plugin-sundtek installieren, dann werden Sundtek-Sticks zur Laufzeit eingebunden.
    • den mediasrv erst starten, wenn alle Sticks da sind, also eine /etc/systemd/systemd/sundtek.service mit diesem Inhalt anlegen:
    Code: /etc/systemd/systemd/sundtek.service
    1. [Unit]
    2. Description=Sundtek mediasrv
    3. After=network-online.target
    4. Before=vdr.service
    5. [Service]
    6. Type=forking
    7. ExecStart=/opt/bin/mediasrv -d --pluginpath=/opt/bin --wait-for-devices
    8. ExecStop=/opt/bin/mediaclient --shutdown
    9. [Install]
    10. WantedBy=multi-user.target

    Was noch nicht geht ist das Mounten von über avahi angekündigten Sundtek-Sticks im Netzwerk.

    Die VLC-Version in Ubuntu 14.04 (auf dem yaVDR 0.6 aufsetzt) ist steinalt - ich würde einfach KODI nehmen (Videos -> Dateien), das ist aus genau dem Grund dabei, damit man einen Player für diverse Medienformate hat, mit denen der VDR selbst nichts anfangen kann (die VDR-Plugins für die Medienwiedergabe sind ja leider auch größtenteils seit vielen Jahren ungepflegt).

    Ein ION1-System sollte 8-Bit HEVC Material mit 720p noch packen, wenn mehrere Kerne zum Dekodieren genutzt werden können (das hatte ich mal unter KODI 17 mit einem der Blender Open Movies ausprobiert), für 1080p ist das System auf jeden Fall zu schwach.

    Der VDR 2.2.0 unterstützt soweit ich das in Erinnerung habe noch keine Wiedergabe von HEVC-Material, das kam erst mit einer späteren Version: https://projects.vdr-developer…dr.git/tree/HISTORY#n8918


    Mit den Systemen aus deiner Signatur hast du außerdem keine Möglichkeit h265 hardwarebeschleunigt zu dekodieren.


    Das Paket vdr-plugin-softhddevice-hevc gibt es in ppa:yavdr/experimental-vdr, das auch einen VDR 2.4.0 mitbringt und mit yavdr-ansible nutzbar ist.

    Ich nehme an ansible git ipdate machen und Xorg role neu ausführen ?

    Ja, wenn du keine Konflikte eingebaut hast mit einem git pull auf den aktuellen Stand gehen und dann kannst du mit sudo -H ansible-playbook yavdr07.yml -b -i 'localhost_inventory' --connection=local --tags="yavdr-xorg" die Rolle yavdr-xorg gezielt laufen lassen.