Beiträge von Tournevis

    Ich habe mal wieder ein wenig Zeit um mich der Sache anzunehmen.

    Code
    yavdr@yavdr2:~$ systemctl status nvidia-persistenced
    Unit nvidia-persistenced.service could not be found.
    
    yavdr@yavdr2:~$ systemctl start nvidia-persistenced
    ==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
    Legitimierung ist zum Starten von »nvidia-persistenced.service« notwendig.
    Authenticating as: yavdr
    Password:
    ==== AUTHENTICATION COMPLETE ===
    Failed to start nvidia-persistenced.service: Unit nvidia-persistenced.service not found.

    Xorg.0.log.txt

    Ich verzweifele beim Versuch, YaVDR Ansible auf meinem Client zum Laufen zu bringen.


    Der ehrwürdige YaVDR 0.5 macht seine Arbeit stabil, mit Ausgabe über vdr-sxfe@vdr-plugin-xineliboutput.


    YaVDR 0.7 (Ansible) zeigt nur ein schwarzes Bild (anfänglich mit dem Logo, danach ohne). OSD-Menü gibt's auch keins.

    Umschalten zu Kodi (frontend-dbus-send switchbetween kodi vdr) funktioniert manchmal, je nach Ausgabe-Plugin (?), dann gibt's auch Bild und Ton. Zurück zum VDR -> alles schwarz.

    Das Live-Plugin zeigt die Kanäle, aber ohne Daten.

    Channels.conf ist vorhanden, die Serververzeichnisse werden eingehängt, umschalten mit der Fernbedienung scheint laut Log auch zu funktionieren.


    Irgendwelche Hinweise, an welcher Stelle ich suchen sollte?

    Wartet der VDR auf irgenwelche -nicht vorhandene- Empfangskarten?

    Ich habe auf zwei Partitionen YaVDR 0.5, basierend auf Ubuntu 12.4.

    Jetzt ist neu auf einer weiteren Partition YaVDR 0.7, mit der Basis ubuntu-20.04.3-live-server-amd64.

    Grub wurde erfolgreich (von 20.04) im Bootsektor der Platte installiert; die vorhandenen Kernel auf anderen Partitionen wurden erkannt und sind im Bootmenü eingetragen.

    Starten von Ubuntu 20.04 ist erfolgreich. :)

    Starten von Ubuntu 12.04 führt nach einigen Sekunden zu einem Reboot und ich bin wieder im Startmenü. :(

    Gibt es eine Möglichkeit zum Tracen/Loggen oder dgl. um herauszufinden was genau da schiefläuft?


    Anmerkung:

    Ich habe auch schon zwischenzeitlich den alten Grub wieder hergestellt (boot von Live-CD, chroot zum Ubuntu 12.4). Dabei geschieht folgendes:

    update-grub stolpert über das Filesystem von Ubuntu 20.04, es wird als defekt erkannt und (trotz tune2fs -O ^metadata_csum) gibt es Meldungen wg. inkompatiblen Flags im Journal superblock. Nach einigen Mühen habe ich den Menüeintrag doch hinbekommen und Grub aus der alten Partition installiert, booten von Ubuntu 12.4 funktioniert dann, aber beim Booten von Ubuntu 20.04 kann dann das alte Grub mit dessen Filesystem nichts anfangen. :wand

    Ich habe eine Merkwürdigkeit entdeckt:

    Der Client sagt bei mount, das serveseitige /srv/audio/ sei in /media/Musik eingehängt.

    Ich sehe dort aber die Inhalte von /srv/public.

    Hat jemand eine Idee?


    Wo kommen denn die Ordner /media/Musik, /media/Bilder etc. her, ist das Magie aus dem Paket "yavdr-i18n"?


    [Gelöst]:

    aus syslog: rpc.mountd[820]: /srv/public and /srv/audio have same filehandle for *, using first

    -> in /etc/exports waren zwei Einträge mit gleicher fsid

    Der Client sieht über avahi die vom Server angebotenen Freigaben

    Nächster Versuch zum Verständnis:

    - Der Server gibt Ordner in einem *.service frei und legt auch die Art des Ordners mit 'subtype' fest.

    - Der avahi-mounter/linker auf dem Client erfärt den Subtyp vom Server, hat aber eine eigene Konfiguration wo der Subtyp eingehängt werden soll.


    Die Blacklist ist ein guter Hinweis, Dankeschön.


    OT: In welcher Datei sind die Liveguards konfiguriert?

    wmautner: Die Signatur ist veraltet, muss ich mal überarbeiten. Aber auf dem Client ist tatsächlich noch 0.5 vom September 2012 :]


    Mal sehen ob ich das richtig verstanden habe:

    -/srv/share/vdr ist obsolete und wurde nur benötigt um die möglichen /srv/vdr/video.0x einzusammeln.

    - Der Server benötigt keine *.sevices und gibt alles über NFS in /etc/exports frei

    - Der Client verwendet *.services um die freigegebenen Verzeichnisse einzubinden, /etc/exports kann leer bleiben

    - An welchem Ort (von den beiden) der Client die Freigabe einbindet sollte egal sein, da der Server nichts einbindet.


    Macht es einen Unterschied, ob /srv/vdr/video.00 oder /srv/vdr/video (Symlink auf video.00) per NFS freigegeben wird? Samba folgt standardmäßig keinen Symlinks und benötigt /srv/vdr/video.00.


    Nachrag:

    Wenn in /etc/exports "/srv/vdr/video" steht, dann gibt exportfs -rav

    exporting *:/srv/vdr/video.00

    Und von den ganzen Freigaben wird lediglich /srv/public eingebunden, obwohl showmountauf dem Client alle Freigaben auflistet.

    Ich habe jetzt einen neuen Server mit YaVDR-Ansible aufgesetzt. Läuft. Gut.

    Aber auf dem Client (0.6) kommt das Aufnameverzeichnis entweder nicht mehr an oder mit Zirkelbezug. Schlecht.


    1. Server:

    /srv/share/vdr ist leer. Das wurde mal von ,hddfs-vdr.conf mits "mount --bind /srv/vdr/video.00" eingebunden, das Skript gibt es aber nicht mehr.

    Auf welchem Weg würde das normalerweise gefüllt?


    2. Avahi:

    Was machen eigentlich die "*.services"? Sind die für die Freigabe oder für das Einbinden verantwortlich, oder für beides?


    3. Was sollte freigegeben und wo eingebunden werden?

    Das Forum nennt mal als Freigabe /srv/vdr/video, mal /srv/vdr/video.00, mal /srv/share/vdr. (Muss aber laut verschiedener Posts ein Symlink sein um Zirkel zu verhindern.)

    Der Ort zum Einbinden ist auch nicht klar und und nennt die drei obigen Orte.

    Momentan bei mir:

    Server: in /etc/avahi-daemon/default.cfg: /srv/vdr/video

    Client: in /etc/default/avahi-mounter: /srv/vdr/video.00

    (Mag sein dass ich das Originalsystem schon ein wenig verpanscht habe.:saint:)


    4. Welche Rolle spielt /etc/exports dabei?


    Für sachdienliche Hinweise wäre ich dankbar.

    Achja, bevor die Frage aufkommt: In /etc/fstab ist nichts davon eingetragen.

    Hallo,
    mein Yavdr läuft seit dem letzten dist-upgrade nicht mehr (wird aber vermutlich eine ganz andere Ursache haben)!
    Das Verhalten ist etwas unübersichtlich:


    Im Prinzip habe ich YaVDR 0.5 im Einsatz. Anfang Dezember habe ich ein dist-upgrade durchgeführt (aus mir nicht näher erklärbaren Gründen ...).
    Seitdem wird das Backend kurz nach dem Start wieder gestoppt.


    Um wenigstens ein lauffähiges System zu haben, habe ich daher auf die alte Installation von YaVDR 0.4 auf einer anderen Partition gewechselt. Hier läuft das Backend stabil, aber die DVB-S2 Karte wird nicht erkannt. Die DVB-T Karte ist erkannt und liefert auch Signale.


    Ich habe einiges durchprobiert
    - DVB-S2 Karte entfernt -> keine Änderung im Verhalten
    - YaVDR 0.5 aus älterem Backup in eine weitere Partiton installiert -> keine Änderung im Verhalten


    Kann jemand mit diesen Informationen schon einen Hinweis geben, was das eigentliche Problem sein könnte?
    Zur Not habe ich noch etliche logfiles vom Startvorgang der verschiedenen Konfigurationen.

    Hallo,
    Bisher hatte ich im Server eine DVB-T und eine L4M-Twin S2 laufen: keine Probleme.


    Dann habe ich eine DVB-S 1.5 FF dazugetan. Im Testbetrieb (ohne Client und mit aktivem Frontend auf dem Server) hat sie tadellos funktioniert. (Einzige Auffälligkeit: Femon zeigte nur den oberen Balken an.) Dazu gehört folgendes Logfile:
    20130503-OK-2.zip
    Im Betrieb hat es dann nicht funktioniert (diesmal hat der Client den Server gestartet, am Server war das Frontend disabled). DVB-S2 und DVB-T Empfang sind problemlos, aber die DVB-S Karte liefert kein Signal. Logfile:
    20130504-NOK-2.zip
    Im Vergleich sehe ich, dass der VDR schon deutlich früher gestartet wird, kann das die Initialisierung verhageln?


    Grüße,
    Tournevis

    So, ich habe mir jetzt selbst geholfen:


    A) Im Skript imageplugin.sh die Werte für OUT_DISPLAY_X und OUT_DISPLAY_Y auf die gewünschte Größe setzen.


    Das hat natürlich Problem (B) deutlich verschärft. Bei 4 MB großen Bildern läuft das tmpfs auf /tmp (size=128MB) doch sehr schnell voll. (Vergrößern geht natürlich, sind ja 4 GB RAM da, aber eine Lösung ist das nicht.)


    B) Ich habe ein kleines Skript cleanuptmp.sh geschrieben, das die Nutzung überprüft und bei über 50% Ausnutzung die älteste Datei löscht.
    Der Rückgabewert signalisiert, ob gelöscht wurde (1) oder nicht (0).


    Das Skript imageplugin.sh habe ich um eine while-Schleife erweitert: Solange cleanuptmp.sh 1 zurückliefert, wird es nochmal aufgerufen.
    Und dann sind wieder mehr als 50% frei.


    - Das Skript liegt bei mir im selben Ordner (usr/lib/vdr-plugin-image) wie imageplugin.sh.
    - Einziger Parameter ist der Pfad zum temporären Verzeichnis, wie er an imageplugin.sh übergeben wurde.
    - Das Löschen geht nur in Verzeichnissen, die auf none gemountet sind (Nein, ich habe nicht Testweise den Parameter /video ausprobiert!)


    Im Anhang sind die beiden Skripte, viel Spaß damit.
    Ach ja: Ich bin kein Skriptkünstler, und etliches hätte sich sicher eleganter lösen lassen. Lasst es mich wissen, ich lerne gerne.

    Hallo,


    nachdem ich endlich auf neue Hardware umgestiegen bin (von LinVDR und Röhre auf YaVDR und Flach-TV) sieht das Bild deutlich besser aus.
    Leider aber nicht bei der Diaschau...


    So wie ich das beobachte, werden die Bilder alle auf SD-Format herunterberechnet.
    Leider bietet das Einstellungsmenu keine Option, Höhe und Breite (und Seitenverhältnis) des Displays vorzugeben.
    (Mir ist schon klar, dass das Plugin für FF-Karten entwickelt wurde und
    Softdevice-Ausgaben nicht im Fokus der Entwicklung stehen.)


    Ich sehe zwar im Syslog, dass das Skript mit den entsprechenden (kleinen) Parametern aufgerufen wird, sehe aber nicht von wo es aufgerufen wird, geschweige denn wie ich den Aufruf anpassen kann.


    Hat jemand dafür eine Lösung parat?


    Ach ja: Die temporär angelegten Dateien werden erst nach dem Ende der Diaschau gelöscht. Das schreibt den Speicher früher oder später voll. Eine etwas agressivere Vorgehensweise beim Löschen der Zwischenprodukte täte dem Plugin (und dem WAF) sicherlich gut. Jedenfalls eher als unvollständige Bilder, die Stück für Stück kürzer werden...


    Tournevis