Das ware doch etwas für eine KI
Beiträge von FireFly
-
-
/etc/init.d/satip.init
/etc/init.d? Das geht aber schon in Richtung deprecated .... mit systemd wäre es zukunftssicherer
-
Ok, dann hatte ich es auch noch nicht ganz verstanden .....
Man spart sich also das satip-Plugin (und dessen curl Abhängigkeit), muss dafür aber (bei jedem Kernel-Upate?) das vtuner-Kernelmodul compilieren.
-
Wenn das Modul geladen ist
Modul? Denke das ein Executable und muss als Deamon gestart werden, oder?
-
Ich hab's auch erst mit Github verstanden ...
Das Vtuner-Programm legt Devices wie /dev/dvb/adapterX/frontend0 an, die auch der Treiber einer SAT-Karte anlegen würde. Für den VDR sieht das dann wie eine lokale SAT-Karte aus.
-
Bei skinelchihd ist der weiße Kanal-Hintergrund vorgegeben
Aber nur durch das Theme, was Du ändern kannst.
-
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.
-
S:oren hat doch betimmt schon ne Version für Kernel 6.5 in seinem Repo ....
-
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.
-
Arghhh! Das Deaktivieren wäre besser in der Netzwerk-Config aufgehoben ....
-
Ausgabe:
tcp6 0 0 :::8001 :::* LISTEN 1721/vdradmin
Ok, das tcp6 erklärt's
Im vdradmin steht:
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 ....
-
Was zeigt grep SEARCH_FILES <Pfad zu Deinem Executable>/vdradmind ?
und was hat /var/lib/vdradmin-am/vdradmind.conf für einen Zeitstempel ?
-
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 ?
-
Poste doch endlich mal Deine Einträge von LOCAL_NET und LOCAL_NET_ONLY sowie die Ausgabe von "ip a" auf dem Rechner auf welchem vdradmin läuft.
Und welche Adresse hat das Gerät, auf dem der Browser aufgerufen wird?
-
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