Beiträge von Razorblade

    Es gibt im PPA schon grundsätzlich Pakete für arm64, nur noch kein paketiertes Ausgabeplugin, das man damit nutzen kann.

    Ah, das ist merkwürdig. Ich hatte die Installation zunächst auf einer aarch64 Installation durchgeführt, aber das Ansible Script ist nicht durchgelaufen. Ich hatte dann im Eingangspost hier armhf gesehen und neu installiert und deswegen den genauen Fehler nicht mehr dokumentiert. Aber ich meine, es wurden entweder die PPAs nicht hinzugefügt und/oder zu installierende Pakete/Abhängigkeiten konnten nicht gefunden werden. Eine (ya)vdr-Installation kam jedenfalls nicht zustande.


    Wenn Interesse besteht, kann ich hier nochmal mit einem anderen System oder einer frischen SD-Karte den Fall reproduzieren und berichten wo es hängt.

    Das bringt halt eine Menge zusätzliche Komplexität mit rein - der VDR schreibt ja normalerweise einiges an Dateien (wenn das komplette Dateisystem read-only ist, sind nicht mal Änderungen in den Einstellungen des VDR und seiner Plugins persistent, man kann keine Timer anlegen, die einen Neustart überleben usw. und es gibt Anwender, die da epgd mit epg2vdr und scraper2vdr laufen lassen oder Aufzeichnungen machen wollen - wenn du im Wesentlichen Bedenken wegen der Logs hast, kannst du auch rsyslog runterwerfen und journald auf den RAM beschränken: https://www.freedesktop.org/so…urnald.conf.html#Storage= - ich finde die Möglichkeit Fehler nachvollziehen zu können im Zweifelsfall wichtiger als eingesparte Schreibzyklen, aber das darf jeder für sein eigenes System entscheiden.

    Ja das ist mir alles bewusst. Ich nutze den Pi als reinen Client. Aufnahmen laufen auf einem headless vdr Server (auf dem NAS) von wo ich bei Start auch die epg.data kopiere und Aufnahmen per NFS exportiere. Ich kann nicht einschätzen, ob das eine typische oder untypische Nutzung ist, Standard sollte es jedenfaös nicht sein!


    Neben weniger Beanspruchung der SD-Karte kommt auch noch der Vorteil, bei einem unsauberen Shutdown (z.B. bei Abbruch der Stromversorgung, Überhitzung, Spannungsunterversorgung des Pi) kein kaputtes Dateisystem zu haben. Auf SSDs und HDDs an PCs hatte ich damit nie Probleme, habe mir aber schon bei einigen RPis mit SD-Karte ein nicht oder schwer reparierbares Dateisystem zugezogen wenn plötzlich (meist durch Wackelkontakt an der Stromzufuhr) der Strom weg war.

    Vielen dank für die Option, yaVDR auch einfach auf einem Pi zu installieren!


    Ich würde es auch begrüßen, wenn ihr im Launchpad repo parallel auch aarch64 anbieten könntet. Das KMS-basierte output-Plugin scheint ja Fortschritte zu machen, so dass das durchaus nutzbar werden könnte. Mit einem Rpi4 könnte dann 4k funktionieren.


    Davon abgesehen hätte ich noch einen Vorschlag zum Betrieb auf einem Pi um SD-Wearing zu vermeiden (gerade durch logs): Read-Only Filesystem support.

    Auf einem anderen Pi mit Raspotify benutze ich das schon basierend auf zu https://hallard.me/raspberry-pi-read-only/ und habe basierend darauf auch meinen Ansible-Yavdr auf RO-Betrieb umgestellt.

    Ich nutze auf einem RPi3b Ubuntu 20.04 mit yaVDR (Raspi-Ansible). Im Prinzip funktioniert alles wunderbar, aber beim Beenden von VDR (inkl. Shutdown/Restart) hängt rpihddevice und beendet sich nicht.


    Ich kann das mit manuellem vdr-Aufruf ohne sonstige Plugins reproduzieren: sobald rpihddevice dabei ist, gibt es das Problem. Bei manueller Ausführung bleibt nach einem kill (HUP/TERM) der vdr-Prozess ewig bestehen. Der Service wird dann natürlich nach einem Timeout irgendwann vom systemd hart gekillt, aber das dauert halt immer eeeeeeewig.


    Im Log steht leider gar nichts.

    Nach der letzten Zeile (tuner thread ended) läuft der vdr-Prozess noch, nach einem nochmaligen HUP/TERM ist er ohne weiteren Eintrag im Log weg.


    Bei einem Aufruf mittels strace sehe ich, dass im "toten Zustand" (alles außer rpihhddevice hat sich beendet) anscheinend noch ein usleep oder so läuft, jedenfalls wird mir die Console mit

    Code
    clock_gettime64(CLOCK_REALTIME, {tv_sec=1636028786, tv_nsec=738028582}) = 0
    futex(0xbee1b040, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, {tv_sec=1636028786, tv_nsec=743028000}, FUTEX_BITSET_MATCH_ANY) = -1 ETIMEDOUT (Die Wartezeit für die Verbindung ist abgelaufen)

    zugeballert.


    Ggü. dem vanilla 1.0.5 scheinen ja einige Patches notwendig gewesen zu sein, ich weiß nicht, welche davon im yaVDR binary sind - wollte hier aber grundsätzlich mal fragen, ob das Problem auch bei anderen besteht oder nur bei mir.

    Ich benutze jetzt seit gut 2 Wochen vdr-plugin-softhdcuvid (0.6.1rc1+git20180909-22-cca1022-1yavdr0~bionic) auf meinem Wohnzimmer VDR und es läuft soweit stabil.

    Festgestelltes Problem (neben dem bereits erwähnten 4:3 Issue, scheint ja in einer neueren Version schon erledigt zu sein) nur das die HD Sender der RTL Familie merkwürdig "ruckeln" bzw. "zucken". Tritt sowohl bei Live-TV als auch (neuen/alten) Aufnahmen auf. RTL UHD klappt (hab neulich Formel 1 gesehen) hingegen.


    Ist da was bekannt?

    Welches Frontend-Script ist das? Muss ich ggf nochmal updaten, hatte das Paket schon am Montag installiert.


    Was mir bei "-f" Benutzung aufgefallen ist (das ist aber yavdr spezifisch und hat nichts mit dem Plugin zu tun): Der Fullscreen-Betrieb ist anscheinend etwas anders als der maximized-Window Betrieb: bei mir ist zB auf einmal DPMS und Screen blanking angesprungen, so dass ich nach 10min einen abgeschalteten HDMI Port bzw ein schwarzes Bild hatte.

    Gibt es inzwischen schon irgendein Ausgabeplugin, dass NVDEC/CUVID unterstützt?

    Wenn ich das richtig sehe, wird das ja von der Hardware (ab Pascal) unterstützt, die (proprietären) Linux Treiber von nVidia haben Support und ffmpeg 4.0 auch.


    Fehlt also nur ein Ausgabeplugin, dass auf NVDEC anstatt anstatt VDPAU setzt?

    Ich glaube bei der Installation war der Fernseher nicht an. Hab jetzt mal (wegen nachträglichen Atric-Einbau) das Playbook (ohne den o.g. tag) durchlaufen lassen und nun passt es!


    Das ist auf jeden Fall ein Kandidat für eine eventuelle Doku: Wegen Hardwareerkennung sollte zum Zeitpunkt des Durchlaufs alles angeschlossen und angeschaltet sein ;)

    nochmal zurück zum Ansible-spezifischen:

    die xorg.conf wird ja aus dem template

    yavdr-ansible/roles/yavdr-xorg/templates/xorg.conf.j2

    generiert.

    Bei mir zB in der section screen:

    Option "metamodes" "HDMI-1: 1920x1080_50 +0+0 {ForceCompositionPipeline=On, ForceFullCompositionPipeline=On}"

    bei 1920x1080_50 würde ich 50Hz vermuten, aber tatsächlich benutzt werden 60Hz laut xrandr Ausgabe:

    Code
    HDMI-0 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 708mm x 398mm
    1920x1080     60.00*+  59.94    59.93    50.00    29.97    25.00    23.97    60.05    60.00    50.04

    Ich vermute das damit auch diverse Bildfehler und Logmeldungen wie

    Code
    Feb 19 15:08:22 vdr-oben vdr: video: slow down video, duping frame
    Feb 19 15:08:22 vdr-oben vdr: video: decoder buffer empty, duping frame (55934/40058) 0 v-buf
    Feb 19 15:08:22 vdr-oben vdr: video:  7:41:30.359 +818  292   0/\ms   0+5+4 v-buf
    Feb 19 15:08:22 vdr-oben vdr: video: slow down video, duping frame
    Feb 19 15:08:22 vdr-oben vdr: video: decoder buffer empty, duping frame (55936/40058) 0 v-buf
    Feb 19 15:08:22 vdr-oben vdr: video:  7:41:30.359 +801  276   0/\ms   0+5+4 v-buf
    Feb 19 15:08:22 vdr-oben vdr: video: slow down video, duping frame
    Feb 19 15:08:22 vdr-oben vdr: video:  7:41:30.359 +785  387   0/\ms   2+6+4 v-buf

    im Zusaamenhang stehen. Oder hat dafür noch jemand einen anderen Vorschlag was das verursachen könnte?

    Ja das habe ich natürlich gemacht, meine beiden vdr frontends laufen mit:

    -d 1 -s 192.168.56.56|DVBS2-4|OctopusNet

    der Server mit:

    -d 2 -s 192.168.56.56|DVBS2-4|OctopusNet


    Genau die gleiche Zeile habe ich auch dem neuen vdr gegeben.

    Ja das habe ich per netplan schon gemacht. Das vlan funktioniert auch insofern als dass ich den SatIP Server anpingen kann und auf das Webinterface komme.

    Per tcpdump sehe ich wie gesagt die Kommunikation zwischen vdr und SatIP Server, aber es kommt immer ein Tuning Timeout. Die channels.conf hatte ich mir von einem anderen vdr (auch 2.3.8) kopiert, der auch SatIP nutzt. Es funktionieren auch alle 4 Tuner und es ist auch ein Tuner frei für den neuen vdr.

    Ok, mit Ubuntu Server sieht es jetzt schonmal besser aus. X kommt hoch, sehe den Splashscreen. vdr startet auch, sehe das OSD.

    Leider kommt er mit meinem Sat>IP nicht klar. Dass die automatische Erkennung fehlschlägt dachte ich mir schon (mein Octopus.Net ist in einem eigenen VLAN), aber es kommt gar kein Bild.

    Bin mir aber ziemlich sicher, dass das nicht an dem build script liegt, sondern sich irgendwas im Bionic geändert hat. Die Signalstärke wird mir angezeigt und mit einem tcpdump sehe ich auch die rtsp session und die rtp Pakete eintrudeln. Aber im syslog steht:

    vdr: [2695] SATIP-ERROR: Tuning timeout - retuning [device 0]


    Fernbedienung habe ich noch nicht getestet, der Atric hängt noch am alten VDR.

    Danke Diablo, das erklärt natürlich warum ich das Webinterface nicht erreiche. Genau so ein "diese Features aus 0.6 funktionieren (noch) nicht" meinte ich mit gibt es noch weitere Doku bzw erwartetes Verhalten. Natürlich kann ich ansible Playbooks und deren Ausgabe lesen. Aber deswegen weiß ich immer noch nicht, was ggü. yavdr 0.6.1 fehlt...


    Channels.conf habe ich selbst, es geht ja mehr oder weniger um ein Upgrade eines alten yavdr 0.5 basierten Systems auf moderne Hardware. 0.6.1 installiert ja im Moment nicht mehr und ist technisch auch nah am EOL, deswegen wollte ich es mal mit dem ansible-basierten yavdr probieren bevor ich eine andere Disti teste.

    Gibt es außer git repo clonen und installer starten noch irgendwo Doku zum yavdr ansible playbook?

    Was ist das erwartete Verhalten nachdem es durchgelaufen ist und was muss man manuell machen?


    Ich habe mal ein nackiges Bionic (daily build) installiert und das Playbook drüberlaufen lassen, aber das mit dem Deaktivieren des nativen X-Server scheint nicht so zu funktionieren (beim Bootup kommt weiterhin der Anmeldescreen auf vt1).


    Der vdr service läuft zwar, aber ich sehe weder gebundene Ports für svdrp noch für das Webinterface.

    Ich hab das gleiche Problem mit yavdr 0.6.0

    Den Stream der vom Server kommt kann ich wunderbar per VLC schauen, wenn ich es mit dem iptv Plugin probiere kommt:

    mit streamdev-server -> streamdev-client geht's gar nicht, schwarzes Bild, keine Verbindung, aber würde es sowieso lieber über HTTP streamen (geht über's Internet)