Posts by OleS

  • yavdr ansible

    Moin zusammen,

    mit dem letzten git pull von yavdr-ansible habe ich eine aktualisierte menuorg.xml.j2 mit (unter anderem) folgenden Inhalt erhalten:

    Code
    1. <menu name="Befehle">
    2.      <command name="{{ "Safely remove usb mass storage" | translate }}" confirm="yes" execute="/usr/bin/vdr-mounter --unmount-all &amp;> /dev/null" />
    3.      <command name="{{ "Update vdr recordings list" | translate }}" execute="/usr/bin/vdr-dbus-send /Recordings recording.Update &amp;> /dev/null " />
    4.      <command name="{{ "Restart VDR" |translate }}" confirm="yes" execute="sudo /sbin/initctl restart vdr" />
    5.      <command name="{{ "Reboot system"| translate }}" confirm="yes" execute="/usr/bin/at now -M -f /usr/bin/vdr-reboot" />
    6.      <command name="{{ "Shutdown system" | translate }}" execute="/usr/bin/lircd2uinput-send KEY_POWER2 &amp;> /dev/null &amp; " />
    7. </menu>

    Dies erzeugt im VDR-Menü dann zwei Einträge mit dem Titel "Befehle" (1x im root und 1x unter System). Außerdem denke ich, dass diese Befehle besser in /var/lib/vdr/commands.conf oder /etc/vdr/command-hooks/commands.custom.conf aufgehoben sind, damit auch Benutzer ohne das Plugin menuorg diese nutzen können.


    Cheers,

    Ole

  • Could not load firmware file ngene_18.fw

    RaHe67 wrote:

    Dort ist mir nämlich von Zeit zu Zeit die boot Partition mit kernels vollgelaufen

    Bei Ubuntuversionen vor 18.04 helfe ich mir immer mit den folgenden Einzeiler.


    Installierte Kernelpakete auflisten (alle außer dem aktuell aktiven):

    Code
    1. dpkg -l 'linux-[him]*' | sed '/^ii/!d;/'"$(uname -r | sed "s/\(.*\)-\([^0-9]\+\)/\1/")"'/d;s/^[^ ]* [^ ]* \([^ ]*\).*/\1/;/[0-9]/!d'


    Wenn der Output geprüft und für gut befunden wurde, löschen:

    Code
    1. dpkg -l 'linux-[him]*' | sed '/^ii/!d;/'"$(uname -r | sed "s/\(.*\)-\([^0-9]\+\)/\1/")"'/d;s/^[^ ]* [^ ]* \([^ ]*\).*/\1/;/[0-9]/!d' | xargs sudo apt-get -y purge


    Cheers,

    Ole

  • yavdr ansible

    Die Variante in der autostart habe ich auch schon ausprobiert, hat aber leider nicht geholfen.

    Auch mit zusätzlichem export DISPLAY bin ich nicht zum Erfolg gekommen.


    Cheers,

    Ole

  • yavdr ansible

    Habe das LOG Level mal auf 2 gesetzt, aber im kodi.log wird nichts bzg. des Abschaltens geschrieben.

    Das syslog ist dazu schweigsam und im Xorg.0.log steht auch nichts.


    Cheers,

    Ole

  • yavdr ansible

    Hmm, das bringt auch nichts. Nach ein paar Minuten "Displayinaktivität" gehen beide Displays wieder aus und der Ton ist weg.

    Ich hatte xset s off -dpms in /var/lib/vdr/.config/openbox/autostart eingebaut.


    Cheers,

    Ole

  • yavdr ansible

    Das ist bereits deaktiviert. Bringt leider nichts. In der xorg.conf steht in der Monitor Sektion Option „DPMS“ , kann das im Weg stehen?


    Cheers,

    Ole

  • yavdr ansible

    Moin zusammen, habe hier das Problem, dass Kodi 18 im yaVDR ansible nach einiger Zeit der Wiedergabe (Audio) die Bildschirme abschaltet und den Ton stumm. Ist das jemandem bekannt bzw. kann ich das irgendwie unterbinden?

    Drücke ich dann eine Taste an der FB oder auf der Tastatur, geht es weiter. Vmtl. Der Displaymanager?


    Cheers,

    Ole

  • softhdcuvid with hevc and UHD

    Lustig...


    Code
    1. root@htpc:~/install/libavcodec# apt-get source libavcodec57
    2. Paketlisten werden gelesen... Fertig
    3. Als Quellpaket wird »ffmpeg« statt »libavcodec57« gewählt.


    Das erklärt es dann wohl. Grummel.


    Cheers,

    Ole

  • softhdcuvid with hevc and UHD

    Das hatte ich gelesen, mich dann aber gewundert, dass ffmpeg bei mir momentan gar nicht installiert ist.

    Heißt dass, durch dein ffmpeg werden Teile von libavcodec57 ersetzt/überschrieben?


    Cheers,

    Ole

  • softhdcuvid with hevc and UHD

    seahawk1986 wrote:

    Ich habe mal versucht diese Änderung für ffmpeg 3.4.4 zu übernehmen

    Dumme Frage meinerseit (eventuell habe ich die Info auch einfach nicht gefunden):


    Auf meinem yaVDR ansible ist das Paket ffmpeg gar nicht installiert aber das aus dem PPA kommende softhdcuvid funktioniert trotzdem.

    Ist das so richtig oder muss/sollte ich da noch etwas umstellen bzw ist das mit dem Paket libavcodec57(-dev) abgefrühstückt und auch dieses sollte den Patch bekommen?


    Irgendwie verwirrt mich diese LIB-Thematik...


    Cheers,

    Ole

  • yavdr ansible

    seahawk1986 wrote:

    Dann bekommt das erzeugte Paket aber immer eine Abhängigkeit von libnvidia-decode-390

    Auch wieder war. Dann baue ich mir das Paket weiterhin selbst. Auf jeden Fall mal vielen Dank für deine Mühe!


    Cheers,

    Ole

  • yavdr ansible

    Eine Lösung wäre eventuell folgendes im Control File anzugeben:


    Build-Depends: debhelper (>= 9), vdr-dev (>= 2.2.0), gettext, pkg-config, libva-dev, libx11-xcb-dev, libxcb-dpms0-dev, libxcb-xv0-dev, libxcb-glx0-dev, libxcb-randr0-dev, libxcb-screensaver0-dev, libxcb-image0-dev, libxcb-util0-dev , libxcb-util0-dev, libxcb-icccm4-dev, libxcb-keysyms1-dev, libavcodec-dev, libavformat-dev, libswresample-dev, libswscale-dev, libasound2-dev, libgl1-mesa-dev, libglu1-mesa-dev, libvdpau-dev, libxcb-ewmh-dev, libswscale-dev, libglvnd-dev, nvidia-cuda-dev, libnvidia-decode-390 | libnvidia-decode-396, libglew-dev, freeglut3-dev, libglm-dev, libfreetype6-de


    Depends: ${shlibs:Depends}, ${misc:Depends}, ${vdr:Depends}, libnvidia-decode-390 | libnvidia-decode-396


    Ist zwar auch nur bis zur nächsten Treiberversion haltbar, aber immerhin.



    Cheers,

    Ole

  • yavdr ansible

    seahawk1986 könntest du bitte die Anhängigkeiten vom Paket vdr-plugin-softhdcuvid anpassen?


    Das ist noch von libnvidia-decode-390 abhängig, und nicht von libnvidia-decode, was ein

    Update des nvidia-Treibers unnötig verkompliziert.


    Cheers,

    Ole

  • yavdr ansible

    Moin zusammen,


    ich versuche mich gerade auf meinem VDR1 an softhdcuvid und bin auf folgendes Problem gestoßen:


    Nach dem Einbinden von http://ppa.launchpad.net/graphics-drivers/ppa/ubuntu wollte ich den NVidia Treiber von 390 auf 396 anheben, leider gibt es dort kein Metapackage nvidia-396


    Der Treiber könnte problemlos mittels apt install nvidia-driver-396 xserver-xorg-video-nvidia-396 libnvidia-cfg1-396 installiert werden, würde dann aber vdr-plugin-softhdcuvid entfernen.



    Das Plugin besteht auf libnvidia-decode-390, sollte aber eher von libnvidia-decode abhängig sein.


    Code
    1. root@htpc:~# aptitude show libnvidia-decode
    2. Kein Installationskandidat für libnvidia-decode gefunden
    3. Paket: libnvidia-decode
    4. Zustand: kein echtes Paket
    5. Bereitgestellt von: libnvidia-decode-390 (390.48-0ubuntu3), libnvidia-decode-390 (390.77-0ubuntu0.18.04.1),
    6. libnvidia-decode-390 (390.87-0ubuntu0~gpu18.04.1), libnvidia-decode-396
    7. (396.54-0ubuntu0~gpu18.04.1), nvidia-340 (340.106-0ubuntu3), nvidia-340
    8. (340.107-0ubuntu0.18.04.1), nvidia-340 (340.107-0ubuntu0~gpu18.04.1)

    Cheers,

    Ole

  • yaVDR ansible: Performancethema

    Hi seahawk1986, hier die Infos.


    Server (Synology, NFSv3):

    /volume1/vdr 10.205.1.0/24(rw,async,no_wdelay,all_squash,insecure_locks,sec=sys,anonuid=666,anongid=666)


    Client: 10.205.1.147:/volume1/vdr /srv/vdr/video nfs defaults,rw,hard,intr,async,tcp,rsize=32768,wsize=32768,timeo=5,retrans=5,_netdev,x-systemd.before=vdr.service 0 0


    Es greift nur ein Client (der VDR) auf das Share zu und dmesg zeigt keinerlei Auffälligkeiten. Mit rsize und wsize habe ich schon gespielt, bringt aber nichts, daher steht es wieder auf 32k.



    Ich denke aber, das Problem liegt wie so oft, ganz wo anders:

    Code
    1. root@htpc:/tmp# pv test.ts > test2.ts
    2. 3,54GiB 0:00:53 [68,1MiB/s] [======================================================================>] 100%

    Für eine M.2 SSD ist die Datenübertragung unter aller Sau! Die werde ich mal tauschen.


    Cheers,

    Ole

  • yaVDR ansible: Performancethema

    Moin zusammen,


    seit meinem Update auf VDR 2.4 (yaVDR ansible/Ubuntu 18.04) plagen mich Performanceprobleme.

    So braucht z.B. epg2vdr geschlagene 1,5 Minuten(!) um die recoding list table zu aktualisieren:


    Code
    1. Sep 20 08:50:27 htpc vdr: epg2vdr: Updating recording list tableSep 20 08:52:02 htpc vdr: epg2vdr: Info: Found 484 recordings; 0 inserted; 0 updated and 30 directories

    Zu der Zeit ist der VDR nicht bedienbar und auch osd2web zeigt nichts an, weil es wohl auf aktuelle Daten wartet.


    Auch das Abspielen von Aufnahmen (NFS-Share) zeigt seltsame Aussetzer - immer wieder alsa: avail underrun error? 'Datenübergabe unterbrochen (broken pipe)'.

    Liegen die Aufnahmen lokal, habe ich diese Probleme nicht. Spiele ich die Aufnahmen unter Kodi auf der VDR-Box vom NAS ab gibt es auch keinerlei Aussetzer.


    Ich dachte schon, es läge an meinem Netzwerk bzw. am NAS, aber andere Clients funktionieren tadellos. Das Netzwerk ist reines 1 GBit und liefert auch zum und vom NAS die entsprechende Geschwindigkeit.


    Code
    1. root@htpc:~# pv /srv/vdr/video/Serien/Game_of_Thrones_-_Das_Lied_von_Eis_und_Feuer/06x01_-_051._Die_Rote_Frau/2017-07-15.20.13.92-0.rec/00001.ts > /tmp/test.ts
    2. 3,54GiB 0:00:36 [ 100MiB/s] [======================================================================>] 100%


    Hat hier jemand ähnliche Probleme oder eine Idee, wie das weiter zu analysieren ist?


    Cheers,

    Ole

  • yavdr ansible

    seahawk1986 wrote:

    dafür habe ich in den letzten Tagen eine Lösung erarbeitet und komme hoffentlich bald dazu das python3-yavdrfrontend Paket zu aktualisieren

    Super, vielen Dank.


    Ich hatte mir zum Test eine passende asound.conf gebaut und in /var/lib/vdr/.config/pulse/client.conf den Parameter autospawn = no gesetzt. Nach einem reboot der Box sollte das doch ausreichen, oder?


    seahawk1986 wrote:

    Für micht sieht das nach Fehlern in der Aufnahme aus.

    Ja, in dieser speziellen Aufnahme sind ein paar kleine Fehler, aber bisher ist der VDR damit prima klargekommen. Andere ebenfalls stockende Aufnahmen haben keinerlei Fehler im TS. Ich befürchte es ist ein Problem im Netzwerk, denn lokal abgelegte Aufnahmen spielen sauber ab und irgendwie verhält sich tracepath eigenartig:



    Ich habe zu meinem NAS immer mal wieder Hänger obwohl darauf eigentlich nichts läuft. Habe zum Test extra alle Services angehalten.

    Also doch mal das Netzwerk auf den Kopf stellen...


    Cheers,

    Ole