Beiträge von minixjr

    Da ich Schreibrechte für das Skindesigner-git unter projects.vdr-developer.org/git/vdr-plugin-skindesigner.git/ habe,, kann ich mir auch vorstellen, dort einen zusätzlichen Branch für die Logos anzulegen und sie dort zu sammeln. Im Moment scheinen sie ja sehr verstreut zu liegen.

    Super Idee, aber scheinbar werden die Logos für YaVDR von Frodo geholt.

    Hier müsste seahawk1986 dann seine Pakete anpassen.

    Wenn die von Dir aufgezählten Optionen nicht funktionieren, bleibt eigentlich nur noch die Pakete auf hold zu setzen.

    Auf meinem Server sieht das dann so aus:

    Code
    @vdrserver:~# apt-mark showhold
    epgd
    epghttpd
    mariadb-plugin-epglv
    vdr-epg-daemon

    Bei Dir dann noch zusätzlich vdr-plugin-epg2vdr

    Also z.B. sudo apt-mark hold vdr-plugin-epg2vdr

    Das schützt Dich vor ungewollten Updates.

    Wenn Du die Pakete dann updaten willst, gibst Du sie zur Installation frei z.B.sudo apt-mark unhold vdr-plugin-epg2vdr

    und sperrst sie danach wieder.

    Mache ich auch so, damit meine selbst gebauten Pakete nicht ersetzt werden.

    So, habe es endlich gefunden. Der Link im vorherigen Beitrag enthielt die Lösung.

    Ich habe einen Switch der auch Securityfeatures hat.

    Aus welchen Gründen auch immer war unter "DoS Defend" die Option "SYN sPort less 1024" aktiv, deshalb konnte der Portmapper auf Port 111 nicht angesprochen werden.

    Ausgeschlossen hatte ich diesen Fehler weil ja mein Debian-Rechner funktioniert hat, der Grund ist aber scheinbar einfach, Debian und NAS sind direkt an der Fritzbox angeschlossen und nicht am Switch, werden also nicht geblockt :wand


    seahawk1986 , besten Dank für Deine Unterstützung und das schöne Wort:thumbup:

    Ein kleiner Lichtblick, ich habe einen Würgaround mit dem ich wieder per NFS mounten kann.

    Nach einem Hinweis von hier LINK, habe ich udp als Mountoption hinzugefügt und damit funktioniert es.

    Wenn man die Option auch in /etc/auto.master.d/avahi-linker.autofs einfügt, klappt auch das automatische Mounten wieder.


    Interessanterweise wird dann auch nicht NFS4 sondern Version 3 verwendet.

    ip addr eines yaVDR-Rechners

    und des Debian-Rechners

    Der Würgaround (schönes Wort :]) hat leider nicht geholfen.

    Jetzt habe ich nur eine IPv4 aber beim manuellen Mounten kommt immer noch ein Timeout

    Zitat

    Löst dein Debian die Hostnamen auch als IPv6-Adressen auf?

    Ja und nein :) --> ping HOSTNAME
    yavdr-ansible-Clients löst es IPv6 auf (bei -4 dann auch als IPv4), das NAS IPv4.

    Die yavdr-ansible-Clients untereinander als IPv6 (bei -4 dann auch als IPv4), das NAS als IPv4

    Zitat

    Unterstützt dein NAS NFS über IPv6?

    Scheinbar nicht, obwohl es eigentlich IPv6 können müsste. Aber nicht mal das anpingen funktioniert (von keinem Rechner)

    Code
    ping -6 nas
    ping: nas: Der Name oder der Dienst ist nicht bekannt
    Zitat

    Klappt ein Mount, wenn du die IPv4-Addresse des NAS angibst?

    Debian Client, nach dem Befehl ist das Share sofort verbunden:

    Code
    sudo mount -v -t nfs -o tcp 192.168.64.168:/VDR /mnt
    mount.nfs: timeout set for Wed Feb  5 14:31:00 2020
    mount.nfs: trying text-based options 'tcp,vers=4.2,addr=192.168.64.168,clientaddr=192.168.64.173'

    yavdr-ansible-Clients, nach dem Befehl kommt nach ca. 5 Minuten ein Timeout:

    Code
    sudo mount -v -t nfs -o tcp 192.168.64.168:/VDR /mnt
    mount.nfs: timeout set for Wed Feb  5 14:33:04 2020
    mount.nfs: trying text-based options 'tcp,vers=4.2,addr=192.168.64.168,clientaddr=192.168.64.191'
    mount.nfs: mount(2): Connection timed out
    mount.nfs: Connection timed out

    Nach dem das Problem bei mir aufgetreten ist, gab es jetzt von Ubuntu noch Updates zu mount und libmount, hat aber am Verhalten nichts geändert.


    Das hier LINK sieht nach meinem Problem aus, leider ohne Lösung. Ich werde aber mal die Kabel prüfen/tauschen.

    Mounten über IPv4 funktioniert nicht, hatte ich schon probiert. Den Rest kann ich erst testen/nachsehen wenn ich wieder Zuhause bin, ab Mittwoch.

    Das Mounten der yavdr-Rechner untereinander funktioniert auch nicht. Anpingen über den Rechnernamen funktioniert bei allen.

    Nein, wenn ich es versuche passiert nix, sieht nach einem Timeout aus.

    Code
    sudo mount -v -t nfs vdrserver:/srv/vdr/video /mnt
    mount.nfs: timeout set for Sun Feb  2 19:31:47 2020
    mount.nfs: trying text-based options 'vers=4.2,addr=2003:e0:cf2c:e300:3f77:3212:1f0d:366,clientaddr=2003:e0:cf2c:e300:962:8c20:990a:2107'
    mount.nfs: mount(2): Connection timed out
    mount.nfs: trying text-based options 'vers=4.2,addr=fd00:3a10:d5ff:feb6:ff37:c496:362d:43c1,clientaddr=fd00:3a10:d5ff:feb6:e5:81ea:8716:4c70'

    Mit Optionen wie "tcp", also nur ipv4, keine Änderung.


    Von meinem Debian-Client kann ich nur das NAS mounten, bei den yavdr Freigaben passiert auch nix, wie oben.

    So wie es aussieht, werden die Links per avahi-linker angelegt, aber Zugriff auf die Dateien habe ich nicht.

    Das letzte Update habe ich versucht rückgängig zu machen und die alten Pakete für bionic heruntergeladen und installiert, leider ohne Erfolg.

    Mangels für mich sichtbarer Fehlermeldungen, bin ich völlig ratlos ;(

    Info: nase64f00 ist mein QNAP, vdrserver und yavdrbox sind ansible bionic Installationen.

    Niemand eine Idee was ich versuchen könnte?

    Hallo zusammen,

    habe grade das Problem, dass ich von keinem meiner Clients ein NFS Share mounten kann ;(

    Kann das Jemand bestätigen, oder bin ich alleine?

    journalctl -b | grep -E "NFS|nfs"

    An meinem QNAP scheint es nicht zu liegen, mit Debian Sid (Siduction) kann ich meine NFS Freigaben mounten.


    Gruß

    Frank

    epgd und epghttpd hast Du bestimmt schon mal neu gestartet?


    Unter yavdr-ansible mit den selben GIT Versionen sehe ich diese Fehler nicht.

    Code
    root@vdrserver:~# epgd-tool -show-stats
    +--------------------------------------------+-------+--------+----------------+----------+---------------------------+---------------------------+---------------------------+
    | version                                    | dbapi | master | ip             | state    | last touch                | last download             | next download             |
    +--------------------------------------------+-------+--------+----------------+----------+---------------------------+---------------------------+---------------------------+
    | vdr 2.4.0 epg2vdr 1.1.106-GIT (23.12.2019) |     7 | n      | 192.168.64.166 | attached | 8th January 2020 19:56:54 | 8th January 2020 01:18:13 | NULL                      |
    | vdr 2.4.0 epg2vdr 1.1.106-GIT (23.12.2019) |     7 | n      | 192.168.64.190 | attached | 8th January 2020 19:56:38 | 8th January 2020 19:02:46 | NULL                      |
    | vdr 2.4.0 epg2vdr 1.1.106-GIT (23.12.2019) |     7 | Y      | 192.168.64.191 | attached | 8th January 2020 19:56:39 | 8th January 2020 19:02:46 | NULL                      |
    | epgd 1.1.149-GIT (15.12.2019)              |     7 | -      | 192.168.64.191 | standby  | 8th January 2020 19:46:38 | 8th January 2020 19:06:16 | 9th January 2020 07:06:16 |
    +--------------------------------------------+-------+--------+----------------+----------+---------------------------+---------------------------+---------------------------+

    rkp, mit der neuen Version gab es eine Änderung in der Datenbank. LINK

    Schau mal ob Du in der Datei /etc/epgd/epg.dat einen Eintrag für für das Feld _ENDTIME (Unterstrich beachten) hast.
    Wenn nicht, wurde die Datei vermutlich nicht upgedatet, dann müsste es aber eine epg.dat.dpkg-distgeben.

    Die musst Du umbenennen und epgd neustarten. Vorher natürlich ein Backup der alten machen.

    Ich nutze nur die yavdr ansible Pakete, bei mir läuft es.
    Zugegebenermaßen baue ich epgd aus den deb-src neu, aber einzige Änderung sind die Plugins.

    Code
    dpkg -l | grep epg
    hi  epgd                                  1.1.149+git20191215-1-71cd459-0yavdr0~bionic+local1    amd64        a EPG daemon which fetch the EPG data
    hi  epghttpd                              1.1.149+git20191215-1-71cd459-0yavdr0~bionic+local1    amd64        Webinterface for epgd
    hi  mariadb-plugin-epglv                  1.1.149+git20191215-1-71cd459-0yavdr0~bionic+local1    amd64        mariadb plugin epglv (used by epgd)
    hi  vdr-epg-daemon                        1.1.149+git20191215-1-71cd459-0yavdr0~bionic+local1    all          Metapackage for epgd
    ii  vdr-plugin-epg2vdr                    1.1.104-0yavdr0~bionic                                 amd64        VDR EPG2VDR Plugin
    ii  vdr-plugin-epgsearch                  2.4.0+git20191202-10-602d66c-0yavdr0~bionic            amd64        VDR plugin that provides extensive EPG searching capabilities

    Hallo seahawk1986 ,


    habe gerade vdr-plugin-epg2vdr per apt upgedatet, leider wird das Plugin nun nicht mehr geladen.

    syslog:

    Code
    Nov 28 18:36:39 vdrslz vdr: [1157] loading plugin: /usr/lib/vdr/plugins/libvdr-epg2vdr.so.2.4.0
    Nov 28 18:36:39 vdrslz vdr: [1157] ERROR: /usr/lib/vdr/plugins/libvdr-epg2vdr.so.2.4.0: undefined symbol: PyObject_GetAttrString
    Nov 28 18:36:39 vdrslz vdr[1157]: vdr: /usr/lib/vdr/plugins/libvdr-epg2vdr.so.2.4.0: undefined symbol: PyObject_GetAttrString
    Code
    vdrslz:~# apt policy vdr-plugin-epg2vdr
    vdr-plugin-epg2vdr:
      Installiert:           1.1.102-0yavdr0~bionic
      Installationskandidat: 1.1.102-0yavdr0~bionic
      Versionstabelle:
     *** 1.1.102-0yavdr0~bionic 500
            500 http://ppa.launchpad.net/yavdr/experimental-vdr/ubuntu bionic/main amd64 Packages
            100 /var/lib/dpkg/status

    Gruß

    Frank

    Hi seahawk1986 ,


    ich habe heute mal wieder das Playbook laufen lassen, dabei sind mir zwei Fehler/Warnungen aufgefallen.

    Warnung 1 ist vermutlich meinem Setup geschuldet, bei Warnung 2 bin ich mir nicht sicher.

    Verwendete Ansibleversion (Debian sid): 2.8.3+dfsg-1

    Warnung 1:

    Code
    [DEPRECATION WARNING]: The TRANSFORM_INVALID_GROUP_CHARS settings is set to allow bad characters in group names by default, this will change, but still be user configurable on deprecation. This feature 
    will be removed in version 2.10. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.

    Dies wird durch die Benennung der Groups verursacht. Entweder man benennt die Gruppen um, also - durch _ ersetzen oder ergänzt die ansible.cfg entsprechend. Siehe auch LINK


    Warnung 2:

    Code
    TASK [yavdr-common : disable release-upgrade notifications] **************************************************************************************************************************************************
    fatal: [vdrslz]: FAILED! => {"msg": "No file was found when using first_found. Use the 'skip: true' option to allow this task to be skipped if no files are found"}
    ...ignoring

    Ich vermute diese Warnung habe ich sonst immer überlesen, da auf meinen drei Systemen die Datei /etc/update-manager/release-upgrades nicht geändert wurde. Ich habe die Funktion etwas abgeändert, dann hat es funktioniert. Diff anbei.configure_system.yml.diff


    Gruß

    minixjr

    Das das ein Bug ist glaube ich fast nicht, ich tippe eher darauf das epgd, wie auch epgsearch, nur die Änderungen eines bestimmten Zeitraums von eplists holt.

    Ich glaube bei epgsearch sind es 72 Stunden!?

    Wenn es also Störungen gibt, die verhindern, dass Du eplists abfragen kannst (wie von Dir beschrieben LINK), kann es meines Erachtens vorkommen, dass Du Änderungen oder neue Serien nicht mitbekommst.

    Aber das ist nur eine Vermutung, vielleicht weiß CKone mehr.