Posts by Piet

    ... da war doch noch was ;)

    Piet


    ... am sinnvollsten erscheint mir, den Pfad zum PID-File konfigurierbar zu machen.

    Dann könnte man das per vdr-transcode.conf einfach auf jede Distribution anpassen, gute Idee!


    Eröffnet dann die Möglichkeit vt als Automatik aus dem VDR Menü sauber zu Starten und zu Beenden, auch wenn er nicht als Root läuft. Der „einfache“ Aufruf ist ja ohnehin kein Problem.

    Funktioniert tadellos, Danke!

    Eine Anmerkung noch zum "Automatik-Modus":

    vt --as selber läuft auch mit normalen Benutzerrechten, lediglich das PID-File kann nicht angelegt / geändert werden, da /run keine Schreibrechte für User bietet. Somit findet vt --ak natürlich dann ggf. keinen Prozeß zum Beenden.


    Wenn Du das PID-File so ablegst, daß auch User schreiben darf, sollte die Automatik eigentlich auch als normaler Benutzer perfekt laufen. Ich habe nicht im einzelnen geprüft, ob es nicht auch noch andere Dateien betrifft, aber sonst wäre mir nichts aufgefallen.

    Nachdem ich nun von to_h264 auf vdr-transcode umgestiegen bin, hier kurz zwei "Issues":

    Die Datei /tmp/vt wird scheinbar aus dem Quellverzeichnis kopiert. Da dieses bei mir auf dem NAS liegt, haben die Quelldateien als Owner alle "1024:users". Das ist an sich kein Problem, aber in /tmp ist das Sticky-Bit gesetzt, so daß nur der Owner löschen darf, was beim erneuten Aufruf von vt zum Problem führt. Lösungen hierfür wären entweder ein chown nach dem Kopieren, oder den Inhalt der Quelldatei einfach stattdessen in eine neue zu kopieren.


    Die Lösung, einfach die tmp-Verzeichnisse im Script umzubiegen, hat mich zum zweiten Issue geführt. Du verwendest nicht durchgehend die Variable vt-log, es gibt noch ein paar Stellen, wo es hartkodiert ist. ;)


    Danke auch für dieses Script & MfG

    Piet

    Dasselbe Setup mit 4 x S2 + Dual-CI läuft übrigens auch hier als Recording- und Streamdevserver und stellt nebenbei noch Jellyfin via Docker bereit.


    2 x 120er SSD RAID1 für System und Docker, Daten per NFS auf Synology-NAS.


    Danke für die „Vorauswahl“ ;)

    Ich verstehe das Problem glaube ich nicht...


    Wer bedient denn bei Dir was fern?


    Hier bei mir: Fernseher-Fernbedienung bedient den NUC-VDR mit internem Pulseeight-Adapter über das cecremote-Plugin, alles was Du oben haben willst, macht die FB direkt mit dem Fernseher aus.


    Wo fehlt da bei Dir was?

    Nachdem to_h264 soeben mein letztes Video im .vdr - Format transkodiert hat, möchte ich mir die Zeit nehmen, hier noch einmal Danke für das Script zu sagen!


    Ich werde jetzt auch zum Nachfolger wechseln, habe aber bis zur letzten "alten" Aufnahme den Wechsel gescheut, weil es einfach so zuverlässig funktionierte.


    MfG


    Piet

    MLD nutzt IMHO ab Werk nicht den --vfat Parameter, der Problematische Zeichen umkodiert, dann kommt sowas bei der Anzeige per SMB/CIFS heraus. Aber Achtung: wenn Du ihn nutzt, hast Du dann Stattdessen andere Sonderzeichen im Namen, z.B. #3A statt Doppelpunkt :)


    Edit: welches System nutzt Du oben für den Zugriff? Evtl. hilft es, wenn Du den Share per NFS mounten kannst.

    Die begonnene Diskussion innerhalb der EU um die Abschaffung der Zeitumstellung wurde offenbar durch Corona in den Hintergrund gedrängt ...


    Nein, übliches Vorgehen: Wir meinen mit Gewalt alles vereinheitlichen zu müssen, und scheitern dann an den unterschiedlichen Meinungen zu Problemen, die wir ohne nicht hätten.

    Hatte mein Samsung auch, habe dann per Farbtaste ein anderes Menü geöffnet, und bin mit der Exit / Zurück / wieauchimmersieheissenmag Taste wieder zurück.


    Ich meine mich zu erinnern, daß man in der Konfiguration der Tastenzuordnung im CEC-Client oder Plugin eine andere Taste wählen konnte, habe das aber nicht weiter verfolgt, weil ich dann auf meinen Sony gewechselt bin, der das Problem nicht hat.


    Die „Menü“ Taste wird wie vermutet nicht per CEC übermittelt, war mW die Quintessenz.

    Moin moin!

    Nachdem mein headless Keller-Server nun absolut klaglos und zuverlässig mit den yavdr-experimental Paketen seinen Pflichten nachkommt, ist Heute der Wohnzimmer-Client dran.


    Ubuntu 20.04 minimal mit yavdr-Paketen als streamdev-client ist bereits eingerichtet (war nach der "Lernkurve" vom Server ja eher einfach), und läuft auch bereits inklusive vorher gemountetem video-Verzeichnis vom NAS, allerdings wird sich nur mit Dummydevice als Ausgabeplugin kein positiver WAF einstellen ;-)


    Der Client ist ein NUC7PJYH2 mit einem 46" Sony am HDMI2 (wird so für den CEC-Adapter benötigt), und soll per SoftHDDevice (oder einem der aktuellen Derivate) ein FullHD Bild darauf zaubern.


    Wer kann mir mal auf die Sprünge helfen, wie ich systemd-konform nun einen möglichst minimalen XServer automagisch starten lasse? Ich würde auch ungern 500 Pakete installieren wollen, wenn's auch "ein paar" weniger tun, es wird ansonsten kein Desktop o.Ä. benötigt.

    Meine bisherigen Suchen verweisen leider immer auf die historischen Möglichkeiten, aber ich würde schon ganz gerne im "aktuellen systemd-Standard" arbeiten wollen.


    Ciao

    Piet

    Es muß irgendwo in den Tiefen von systemd "verbogen" gewesen sein.

    Nach beherzter Neuinstallation mounten NFS-Shares aus der fstab wieder "wie gewohnt" (auch ohne besondere Optionen), lediglich den vdr.service musste ich nach /etc/systemd/system klonen, und statt


    After=network.target wartet er nun auf After=srv-vdr-video.mount (die automatisch generierte unit aus der fstab).

    Zusammengefasst: Problem war, das network-online.target schon erreicht war, wenn network-online noch nicht gegeben war (warumauchimmer)

    Ich habe den Weg gewählt, VDR auf den automatischen Mountpoint warten zu lassen, weil ich noch mehrere nfs-mounts benötige, die Lösung dieser Thematik also vorrangig war.

    Danke allen Mitstreitern!

    Aber Deine Meldung sagen IMHO eigentlich was anderes ... schräg ...

    Genau da liegt für mich der Hund begraben, aber wie ändern? Das Target ist halt doch noch nicht "reached". Nervig...


    Habe auch schon mal Netplan auf DHCP umgestellt, macht aber keine Unterschied. Ich hatte die Hoffnung, daß er dann auf die IP wartet, somit Link schon da sein muß -> negativ.

    Nachlieferung für fnu:


    root@server:~# systemctl status srv-vdr-video.mount

    ● srv-vdr-video.mount - /srv/vdr/video

    Loaded: loaded (/etc/fstab; generated)

    Active: failed (Result: exit-code) since Sun 2021-02-14 12:55:58 CET; 31s ago

    Where: /srv/vdr/video

    What: 192.168.1.55:/volume2/video

    Docs: man:fstab(5)

    man:systemd-fstab-generator(8)


    Feb 14 12:55:58 server systemd[1]: Mounting /srv/vdr/video...

    Feb 14 12:55:58 server mount[678]: mount.nfs: Network is unreachable

    Feb 14 12:55:58 server systemd[1]: srv-vdr-video.mount: Mount process exited, code=exited, status=32/n/a

    Feb 14 12:55:58 server systemd[1]: srv-vdr-video.mount: Failed with result 'exit-code'.

    Feb 14 12:55:58 server systemd[1]: Failed to mount /srv/vdr/video.


    Wie gesagt: Netzwerk ist halt noch nicht da :-/

    Das network-online.target ist definitiv "defekt", und das ist IMHO auch das Problem. Es wird zu früh gestartet, hier zwei Sekunden, bevor NetworkManager einen Link hat. Die .mount - Unit wird aus der fstab autogeneriert. Auf Ubuntu 18.04 war das alles kein Problem, lief sofort OOTB. Sieht auch alles genauso aus, was die dependencies etc. angeht. Den NetworkManager hatte ich testhalber mal Installiert, macht aber auch ohne keinen Unterschied.


    Feb 14 09:53:51 server systemd[1]: Reached target Network is Online.

    Feb 14 09:53:51 server systemd[1]: Mounting /srv/vdr/video...

    Feb 14 09:53:51 server mount[670]: mount.nfs: Network is unreachable

    Feb 14 09:53:51 server systemd[1]: srv-vdr-video.mount: Mount process exited, code=exited, status=32/n/a

    Feb 14 09:53:51 server systemd[1]: srv-vdr-video.mount: Failed with result 'exit-code'.

    Feb 14 09:53:51 server systemd[1]: Failed to mount /srv/vdr/video.

    Feb 14 09:53:51 server systemd[1]: Dependency failed for Remote File Systems.

    Feb 14 09:53:51 server systemd[1]: remote-fs.target: Job remote-fs.target/start failed with result 'dependency'.

    Feb 14 09:53:53 server systemd-networkd[326]: enp3s0: Gained carrier

    Feb 14 09:53:53 server NetworkManager[533]: <info> [1613292833.7330] device (enp3s0): carrier: link connected

    Feb 14 09:53:53 server systemd-timesyncd[527]: Network configuration changed, trying to establish connection.

    Feb 14 09:53:53 server systemd-timesyncd[527]: Initial synchronization to time server 91.189.89.198:123 (ntp.ubuntu.com).


    root@server:~# systemctl list-dependencies srv-vdr-video.mount

    srv-vdr-video.mount

    ● ├─-.mount

    ● ├─system.slice

    ● └─network-online.target

    ● ├─NetworkManager-wait-online.service

    ● └─systemd-networkd-wait-online.service