Kannst du den Inhalt des Verzeichnis listen lassen? ls -l /srv/vdr/video
Den Pfad kannst du find mitgeben:
find /srv/vdr/video -maxdepth 1 -type l -delete
Das Löschen der Symlinks würde auch von einem Live-Medium aus gehen.
yavdr ansible
-
-
seahawk1986 Du bist mein Held !!!!!
Er läuft wieder, als ob nie was gewesen wäre !
Ich habe nicht nur per Live-System die Links vom Videoverzeichnis gelöscht, sondern auch vom /media, da sich hier jeweils 2 Links pro Verzeichnis eingenistet haben, einmal für yavdr und einmal für yavdr-2.
Ich danke dir für deine Zeit und für deine Geduld !!!
Einen guten Rutsch !
Armin
-
Gerne, das ist ein gemeiner Fehler, bei dem ich mir nicht ganz sicher bin, wie man ihn im avahi-linker zuverlässig abfangen kann. Ich kann auf jeden Fall dafür sorgen, dass Freigaben mit dem Hostname localhost ignoriert werden.
-
Hallo,
vorab möchte ich mich für yavdr-ansible bedanken, super Arbeit.
Mit yavdr-ansible war das aktuelle System in wenigen Minuten aufgesetzt.
Dabei sind mir die folgenden zwei Punkte aufgefallen:
- irman: Link irman auf ttyACM0 wird nicht gesetzt -> manuelles Anlegen erforderlich (nutze atric USB device)
- Plugin directory: vdr-User hat keine Schreibrechte für /var/cache/vdr/plugins/ (Verzeichnis gehört root) -> Besitzer der Dateien ab /var/cache/vdr auf vdr.vdr geändert (aufgefallen mit dem zusätzlich in host_vars/localhost aufgenommenen Plugin vdr-plugin-robotv)
Danke
Bernhard
-
- irman: Link irman auf ttyACM0 wird nicht gesetzt -> manuelles Anlegen erforderlich (nutze atric USB device)
War das nach einem Reboot auch noch so?
Das Anlegen des Links sollte über diese udev-Regel passieren (das hat damals IIRC zumindest unter trusty und xenial funktioniert): https://github.com/yavdr/yavdr…atric-ir-wakeup-usb.rules - die wird aber nicht berücksichtigt, bis es ein neues "add"-Event vom Empfänger gibt - ich kann mal versuchsweise ein udevadm trigger -c add -w -s tty /dev/ttyACM* in die Rolle einbauen, dann müsste er das Event erneut senden.
Falls es nach dem Reboot nicht mit dem Symlink geklappt hat:
Kannst du bitte mal zeigen, was udevadm info --query=all --name /dev/ttyACM0 für deinen Empfänger ausgibt?
- Plugin directory: vdr-User hat keine Schreibrechte für /var/cache/vdr/plugins/ (Verzeichnis gehört root) -> Besitzer der Dateien ab /var/cache/vdr auf vdr.vdr geändert (aufgefallen mit dem zusätzlich in host_vars/localhost aufgenommenen Plugin vdr-plugin-robotv)
Da ist mir noch nicht ganz klar, woher die verbogenen Rechte kommen (die Plugins legen die Verzeichnisse im CACHE_DIR normalerweise erst bei Bedarf an) - welche Plugins hast du neben robotv installieren lassen?
-
Hallo,
sollte bei einer bestehenden ssh-Verbindung, der Shutdown bei Inaktivität, nicht mit entsprechenden Meldung abgebrochen werden?
Hier ist das bei einer älteren Installation von 2018 und bei einer Installation von gestern jedoch nicht der Fall.
War zumindest bei yavdr-0.62 immer so. Wo ist die Ursache zu suchen? Danke im Voraus schon mal.
mfg
-
Es funktioniert jedenfalls, wenn das vdr-addon-lifeguard-ng installiert und ssh im /etc/lifeguard.conf auf
EnableSSH = True
gesetzt ist (sollte Standard sein, wenn das Addon installiert ist).
-
Hallo,
habe es gefunden, danke.
Sollte man vielleicht standardmäßig aktivieren.
mfg
-
Hallo,
nach dem Aufwachen aus dem Standby sind hier jede Menge Einträge folgender Art,
Failed to canonicalize path /home/user/.local/share/....: Permission denied
im syslog vorhanden
Wieso wird Zugriff auf home vom user benötigt, ist etwas schief gelaufen bei der Installation ?
mfg
-
Was genau hast du da gemacht bzw. am System und Playbook angepasst? Eigentlich sollte es durch yavdr-ansible keine Systemd Units für den Installations-User geben (nur für den User vdr) - ~/.config/systemd und ~/.local/share/systemd existieren auf meinen Systemen für den Installations-User nicht mal...
-
Hallo,
Was genau hast du da gemacht bzw. am System und Playbook angepasst?
kann ich jetzt nicht mehr sagen. Installiere gerade alles nochmal schnell neu. Danke
mfg
-
Ich würde gerne mal yavdr ansible auf einem Rechner mit Kaby Lake Intel Core i7-7700K installieren, nur so zum ausprobieren, ob damit 4K HDR schon vernünftig läuft. Leider habe ich den Faden verloren, was die diesbezügliche Entwicklung betrifft. Nach der Installation von ansible muss ich vermutlich das softhddevice ersetzen, aber gegen welches genau?
-
Hallo,
kann ich jetzt nicht mehr sagen. Installiere gerade alles nochmal schnell neu. Danke
mfg
alles neu installiert. Leider unverändert. Playbook ebenso unverändert.
mfg
-
War das nach einem Reboot auch noch so?
Ja, habe gerade noch einmal in die Logs geschaut.
Erst nach dem manuellen Anlegen des Links waren der lircd und damit der vdr zufrieden.
Da ist mir noch nicht ganz klar, woher die verbogenen Rechte kommen (die Plugins legen die Verzeichnisse im CACHE_DIR normalerweise erst bei Bedarf an) - welche Plugins hast du neben robotv installieren lassen?
Das robotv Plugin wollte beim ersten Start des vdr ein Verzeichnis im CACHE_DIR anlegen.
Daher ist es mir aufgefallen.
Im CACHE_DIR waren auch die Dateien commands.conf und reccmds.conf mit Besitzer root angelegt.
VG
Berrnhard
-
Erst nach dem manuellen Anlegen des Links waren der lircd und damit der vdr zufrieden.
Dann zeig bitte noch was udev zu dem Empfänger sagt: udevadm info --query=all --name /dev/ttyACM0
-
alles neu installiert. Leider unverändert. Playbook ebenso unverändert.
Das sieht fast so aus, als würde der nfs-server nicht als System-Job laufen, sondern im Rahmen der User-Session...
Was sagen denn systemctl --user und systemctl nach dem Aufwachen?
-
Nach der Installation von ansible muss ich vermutlich das softhddevice ersetzen, aber gegen welches genau?
Ich dachte, dass das softhddevice auch mit HEVC-Material kann - aber der skindesigner zickt bei 4k Auflösung und 10-Bit Ausgabe mit HDR ist tricky und soll mit etwas Mühe mit softhddrm möglich sein, wenn alle Voraussetzungen erfüllt sind.
Am besten gleich bei der Installation das experimental-vdr PPA durch https://launchpad.net/~seahawk…+archive/ubuntu/vdr-2.4.1 ersetzen und https://launchpad.net/~seahawk…rchive/ubuntu/softhdvaapi dazu nehmen., dann hast du einen aktuellen VDR in Kombination mit einem aktuellen ffmpeg und kannst das vdr-plugin-softhdvaapi installieren, sobald du wie in softhdcuvid jetzt mit VAAPI und HDR support beschrieben die Anpassungen an der 20-intel.conf und der .drirc gemacht hast (der Teil fürs yavdr-frontend ist nicht mehr nötig).
Alternativ kannst du auch einen Focal Server mit dem Alternative Iso installieren und den focal-Branch von yavdr-ansible nehmen - das hat den Vorteil, dass alle Pakete bereits in experimental-vdr stecken.
Für softhddrm fehlt im Playbook noch eine Möglichkeit eine Systemd-User Session analog zu xlogin@vdr.service zu starten - da bin ich aktuell noch am Überlegen, was ich da anbieten kann, weil man neben dem VDR-Frontend momentan nicht wirklich etwas anderes nutzen kann (softhdcuvid jetzt mit VAAPI und HDR support).
-
Hallo,
Das sieht fast so aus, als würde der nfs-server nicht als System-Job laufen, sondern im Rahmen der User-Session...
Was sagen denn systemctl --user und systemctl nach dem Aufwachen?
Poste ich dann morgen, habe die Platte für heute bereits abgeklemmt. Danke erstmal.
mfg
-
Dann zeig bitte noch was udev zu dem Empfänger sagt: udevadm info --query=all --name /dev/ttyACM0
Sorry, die Frage hatte ich übersehen.
Hier die Ausgabe:
P: /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3/1-1.3:1.0/tty/ttyACM0
N: ttyACM0
S: irman
S: serial/by-id/usb-Atric_Development_GbR_Atric_IR-Wakeup_USB-if00
S: serial/by-path/pci-0000:00:1a.0-usb-0:1.3:1.0
E: DEVLINKS=/dev/serial/by-path/pci-0000:00:1a.0-usb-0:1.3:1.0 /dev/irman /dev/serial/by-id/usb-Atric_Development_GbR_Atric_IR-Wakeup_USB-if00
E: DEVNAME=/dev/ttyACM0
E: DEVPATH=/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3/1-1.3:1.0/tty/ttyACM0
E: ID_BUS=usb
E: ID_MODEL=Atric_IR-Wakeup_USB
E: ID_MODEL_ENC=Atric\x20IR-Wakeup\x20USB\x20\x20\x20\x20\x20\x20
E: ID_MODEL_FROM_DATABASE=7 Series/C216 Chipset Family USB Enhanced Host Controller
E: ID_MODEL_ID=f844
E: ID_PATH=pci-0000:00:1a.0-usb-0:1.3:1.0
E: ID_PATH_TAG=pci-0000_00_1a_0-usb-0_1_3_1_0
E: ID_PCI_CLASS_FROM_DATABASE=Serial bus controller
E: ID_PCI_INTERFACE_FROM_DATABASE=EHCI
E: ID_PCI_SUBCLASS_FROM_DATABASE=USB controller
E: ID_REVISION=0100
E: ID_SERIAL=Atric_Development_GbR_Atric_IR-Wakeup_USB
E: ID_TYPE=generic
E: ID_USB_CLASS_FROM_DATABASE=Communications
E: ID_USB_DRIVER=cdc_acm
E: ID_USB_INTERFACES=:020201:0a0000:
E: ID_USB_INTERFACE_NUM=00
E: ID_VENDOR=Atric_Development_GbR
E: ID_VENDOR_ENC=Atric\x20Development\x20GbR\x20\x20\x20\x20
E: ID_VENDOR_FROM_DATABASE=Microchip Technology, Inc.
E: ID_VENDOR_ID=04d8
E: MAJOR=166
E: MINOR=0
E: SUBSYSTEM=tty
E: TAGS=:systemd:
E: USEC_INITIALIZED=3216371
VG
Bernhard -
Ja, habe gerade noch einmal in die Logs geschaut.
Erst nach dem manuellen Anlegen des Links waren der lircd und damit der vdr zufrieden.
Merkwürdig, an meinem bionic Testsystem klappt das Anlegen des Links einwandfrei - sowohl beim Anstecken als auch beim nachträglichen Auslösen des Signals mittels udevadm trigger -c add -s tty /dev/ttyACM*
Durch das yavdr-remote Paket sollte es folgende udev-Regel im System geben:Code: /lib/udev/rules.d/91-atric-ir-wakeup-usb.rulesACTION=="add", KERNEL=="ttyACM[0-9]*", SUBSYSTEM=="tty", ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="f844", SYMLINK+="irman"Kannst du mal den Empfänger abstecken, den udevadm monitor starten und dann den Empfänger wieder anstecken?
Code$ udevadm monitor -u -pAuf meinem Test-Rechner für bionic sieht das dann z.B. so aus:
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!