Beiträge von FireFly

    Warum so kompliziert mit MQTT? Einfach per SSH vom VDR (Client) auf den Proxmox-Server würde auch gehen, aber dafür ist er natürlich nicht gedacht.

    Ich habe auf jedem VDR mehrere Root-Partitionen, von denen immer eine die aktuelle OS-Version und eine die vorhergehende hat. Via Grub Bootmenü kann man (notfalls) die ältere booten und wieder zur Standard-Boot-Partition machen.

    Denke nicht, dass wir aneinander vorbei geredet haben.

    Die Praxis hat gezeigt, dass, wenn es deadlocks geben kann, es normalerweise auch deadlocks gibt.

    Normalerweise schon, aber in seltenen Fällen halt nicht. Darauf wollte ich hinweisen.

    Und Deadlocks sind für mich nicht akzeptabel, auch wenn's ein Hobbyprojekt ist. Da muss dann der jeweilige Entwickler ran.

    "dass ein Plugin die Channels lockt und ein anderes danach die Timer. Dann kommt diese Meldung"

    glaube ich nicht.

    Ist aber damals lt. syslog so gewesen (wobei es auch andere der vier Resourcen gewesen sein können).


    Oder gibt es einen thread, den sich mehrere Plugins teilen? Falls ja, dann solllten die Plugins in diesem thread lieber nichts locken.

    Die Plugins laufen ja erst mal alle innerhalb des Main Thread des VDR.


    Es geht ja darum Deadlocks zu vermeiden, d.h. wenn verschiedene Threads die vier Resourcen in unterschiedlicher Reihenfolge locken kann es dazu kommen. Wenn jetzt ein Plugin nur die Channels braucht sehe ich keinen Grund auch die Timers zu locken. Wenn der andere Thread dann zusätzlich die Channels locken will, muss er halt warten bis der erste die Channels frei gibt. Zum Deadlock kommt es ja erst dann, wenn der Thread, der die Channels gelockt hat noch die Timers locken möchte. Das darf er eben nicht in dieser Reihenfolge.

    VDR protokolliert nur die Reihenfolge der Locks, weshalb er auch solche Konstellationen meldet.

    Empfehlen kann ich da das Buch "Multicore Software" von Gleim und Schüle aus dem dpunkt Verlag.

    Die Meldungen wird man nie ganz weg bekommen. Es kann z.B. sein, dass ein Plugin die Channels lockt und ein anderes danach die Timer. Dann kommt diese Meldung, aber es besteht keine Gefahr eines Deadlocks weil das Plugin mit den Channels die Timer nicht lockt. Wenn es natürlich auch die Timers braucht (inklusive Locks im Core-VDR), muss es die in der richtigen Reihenfolge locken.

    jetzt musst Du natürlich auch auf IPv4 in Deiner vdradmin.conf gehen.

    Wieso?

    Lt. Source: CONFIG{SERVERHOST} = Question(gettext("On which address should VDRAdmin-AM listen (0.0.0.0 for any)?"), $CONFIG{SERVERHOST});

    Also nur, wenn er mehrere IPs hat.

    Der Starscript für vdradmin heißt wie?

    Tja, das hängt davon ab, wie Dein System konfiguriert ist (ich habe kein yaVDR).

    Ich vermute mal, dass systemd benutzt wird, dann kannst Du die Config und deren Dateiname mit systemctl cat vdradmind.service sehen. Interessant ist das, was hinter ExecStart steht.

    Ausgabe:

    tcp6 0 0 :::8001 :::* LISTEN 1721/vdradmin

    Ok, das tcp6 erklärt's :(

    Im vdradmin steht:

    Code
    sub subnetcheck { #TODO: IPv6 support
        my $ip   = $_[0];
        my $nets = $_[1];

    Der vdradmin kann zwar mit IPv6 kommunizieren, aber der Subnet-Check geht bisher nur mit IPv4. Deshalb erkennt er nicht, dass er im gleichen (IPv6-) Subnetz ist und fragt nach dem Passwort.


    Was mich etwas wundert ist, dass er IPv6 nur aktiviert, wenn man es als Startparameter (-6 oder --ipv6) mitgibt. Falls das im Startskript gesetzt ist kannst Du es ja mal deaktivieren.

    Ok, SEARCH_FILES_IN_SYSTEM = 1 bedeutet, dass er seine Dateien im Dateisystem sucht (anstatt nur unter /var/lib/...), d.h. die Configfiles stehen in /etc/vdradmin.

    Wann hast Du den vdradmin das letzte Mal gestoppt (z.B. durch herunterfahren des Rechners) ? Am 7.10. 18:30 ?

    Wenn ja, dann kann er auch schreibend auf die vdradmind.conf zugreifen.

    Ich fürchte, da hilft nur Patchen um zu sehen , was da wirklich abläuft.


    Davor noch ein letzter Versuch: Nutzt Du IPv6? vdradmin kann nur IPv4.

    Was zeigt netstat -tlnpa|grep 8001 ?

    IPv6 würde auch mit Deiner Erinnerung übereinstimmen, dass beim Ubuntu in der Netzwerkconfig "etwas gemacht" werden muss ....

    Das sieht schon mal ok aus (das LOCAL_NET_ONLY hast Du sicher auf 0 gesetzt weil es sonst noch nicht funktioniert).


    Das nächste wäre die vdradmind.conf - wo liegt die?

    Evtl. sucht vdradmin im falschen Verzeichnis.

    Was zeigt grep SEARCH_FILES <Pfad zu Deinem Executable>/vdradmind ?

    Funktioniert das Plugin bei Dir/Euch fehlerfrei? Nachdem ich es vor längerer Zeit mal installiert hatte, hat es an den unterschiedlichsten Stellen in anderen Plugins Seg Faults gegeben, weshalb ich es wieder deinstalliert habe (und der VDR dann wieder problemlos lief).

    Einige Sachen funktionieren auch gar nicht wie das "VACCUM" von sqlite oder es löscht Bilder für demnächst anstehende Sendungen weil sie n Tage nach dem Runterladen gelöscht werden und holt sie erst beim nächsten Update wieder.

    Ok, damit konnte ich es nachvollziehen und habe Deinen Patch übernommen. Das hat wohl im ersten Anlauf funktioniert, aber dann habe ich drei ähnliche Codeblöcke zusammengefasst und mich dummerweise nach der Beschreibung von SetItemEvent() gerichtet, die für WithDate nicht korrekt ist. Da das Event-Menü von EPGsearch das WithDate aber richtig setzt, ist es wohl (nicht nur mir) bisher nicht aufgefallen.


    Download wie immer via https://github.com/FireFlyVDR/…chihd/releases/tag/v1.2.3