Posts by woggle

    Du hast es getroffen! pmtv3.local wird aufgelöst, pmtv3 nicht!


    showmount -e pmtv3 sagt: clnt_create: RPC: Unknown host was zu erwarten war.

    Ein cd /net/pmtv3/srv/vdr/video funktioniert dementsprechend auch nicht.


    Ich scheine da ein Chaos in der Namesauflösung in meinem lokal en Netz zu haben!:(

    Das muss ich mir mal in Ruhe zu Gemüte führen...


    Deinen Tipp mit der Änderung des avahi-linkers habe ich noch nicht probiert. Ich glaube ich sollte lieber das Chaos mit der Namesauflösung beheben.

    Im syslog habe ich doch noch etwas gefunden:

    Code
    1. May 20 15:05:08 pmtv4 automount[757]: create_client: hostname lookup for pmtv3 failed: Temporary failure in name resolution
    2. May 20 15:05:08 pmtv4 automount[757]: get_exports: lookup(hosts): exports lookup failed for pmtv3
    3. May 20 15:05:08 pmtv4 automount[757]: key "pmtv3" not found in map source(s).

    Schaut doch nach Namensauflösung aus. Nur warum? EIn ssh pmtv3.local funktioniert prima. Hmmm???

    Noch ein Problem ;)

    Wenn ich zwei yavdr-ansible Rechner habe sollten die doch gegenseitig ihre freigegebenen Verzeichnisse sehen: /srv/audio, backup, files, picture, video aber vor allem die Aufnahmen unter /srv/vdr/video.

    Announciert wird es via avahi Services und der avahi-linker guckt wer was zur verfügung stellt und mountet das dann. So ähnlich funktioniert das prima auf meinem uralt yaVDR 0.5.

    Nur mit dem yavdr-ansible will das nicht. Es werden jede Menge Symlinks angelegt, z.B. in /srv/vdr/video/ findet sich ein Symlink 'recordings_on_pc1(nfs' der zeigt auf '/media/vdr/Recordings on pc1 for pc2'. Unter /media/vdr/ finde ich wieder einen Symlink 'Recordings on pc1 for pc2' der zeigt auf '/net/pc1/srv/vdr/video'. Nur unter /net ist nix!

    Ok, irgendetwas mit autofs. Aber das autofs muss doch auch wissen was es wohin mounten soll. Dazu habe ich leider nix gefunden. In /etc/auto.master.d/avahi-linker.autofs steht nur '/net -hosts -intr,soft --timeout=60'.


    Was geht da schief?


    Der avahi-linker macht ja etwas. Sonst würde es die Symlinks nicht geben. Aber wann werden die Verzeichnisse denn gemountet?

    Moin zusammen,

    wenn ich es richtig verstanden habe dann sollte doch die yavdr-ansible-Installation die timezone auf 'Europe/Berlin' setzen.

    Ich habe es nun mehrfach probiert, auf Hardware und VM aber die timezone bleibt immer auf 'etc/UTC'.

    Verwendet habe ich ubuntu 20.04.2-server und ein frisch geklontes yavdr-ansible ohne irgendwelche Änderungen. Und dann ein:

    Code
    1. sudo -H ./install-yavdr.sh

    Ich habe die timezone dann einfach per Hand umgestellt.


    Mache ich etwas falsch oder ist das ein Bug?

    Hab's mir mal angeschaut.
    Ich habe es fast befürchtet: das ist kein Poti sondern ein Drehimpulsgeber.
    Deshalb springt die Lautstärke nach dem Aus- und Einschalten wieder auf einen normalen Wert zurück.
    Leider sagt das Service-Manual nichts über den Typ des Gebers aus. Die gibt es mit verschiedenen Rastungen und Impulsen pro Umdrehung (einfach mal bei Reichelt nach Drehimpulsgeber suchen).
    Das bekommst du vermutlich nur heraus indem du die Kiste zerlegst und guckst ob auf dem Drehimpulsgeber eine Typenbezeichnung aufgedruckt ist.
    Natürlich muss nicht unbedingt der Drehimpulsgeber defekt sein! Aber es ist ein Ansatz...

    4. Ja, einen Quattro-LNB habe ich, aber was genau ist ein Stammausgang eines Multischalters? Kann ich die 4 freien Ausgänge meines Multischalters als Stammausgang betrachten?


    Die Stammausgänge sind die vier Ausgänge deines Quattro-LNB.


    Wenn du die Signale an die Max-S8 anschließen möchtest und noch normale Sat-Geräte via Multiswitch brauchst, dann benötigst du einen kaskadierbaren Multiswitch. Ein kaskadierbarer Multiswitch hat vier Eingänge für die Signale vom LNB und vier Ausgänge (Stammausgänge) an die die Signale vom LNB durchgereicht werden.


    Falls du keine normalen Sat-Geräte brauchst, könntest du die Max-S8 auch direkt an deinen Quattro-LNB anschließen. Dann allerdings mit fmode=2.

    Danke an alle für die Info!
    Den von mini73 erwähnten Thread hatte ich gefunden. Allerdings hatte ich die Lösung in dem Thread anders verstanden. Da hatte wohl die vdr-essential gefehlt.


    Mir geht es eigentlich eher um die Ästhetik als um den Plattenplatz. ;-)
    Ich finde es halt nicht besonders angenehm wenn mir das apt-get bei jeder Aktion diesen "Schwall" um die Ohren haut...

    Hallo zusammen,
    ich haben eben einen yaVDR 0.5.0a neu aufgesetzt. Komplette Neu-Installation.
    Nach der erfolgreichen Installation habe ich ein
    sudo apt-get update
    und ein
    sudo apt-get dist-upgrade
    ausgeführt.
    Beim nächsten apt-get install z.B.
    sudo apt-get install yavdr-hardware-sundtek
    bekomme ich dann die Meldung

    Code
    1. Die folgenden Pakete wurden automatisch installiert und werden nicht mehr benötigt:
    2. vdr-plugin-skinpearlhd libhal-storage1 vdr-tft-anthraize vdr-skin-anthra-1920-fse libmagickcore4 libsdl-mixer1.2 libmagickwand4 vdr-tft-standard libmagick++4 liblqr-1-0 vdr-tft-pearlhd python-qt3 imagemagick-common python-sip libhal1 libmikmod2
    3. vdr-skin-narrowhd libgraphicsmagick++3 vdr-skins-anthra libjpeg62 vdr-plugin-text2skin libcxxtools7 libtntnet9 libqt3-mt vdr-plugin-graphtft vdr-plugin-extrecmenu vdrsymbols-ttf
    4. Verwenden Sie »apt-get autoremove«, um sie zu entfernen.


    Frage: kann ich das autoremove gefahrlos laufen lassen oder ist das ein Bug in der Paketverwaltung?
    Mich verwundern die vielen vdr-Pakete die plötzlich überflüssig sein sollen...

    apt-get sagt leider nur ich möchte doch bitte
    dpkg --configure -a
    ausführen.
    Und täglich grüßt das Murmeltier... ;-)


    Das syslog gibt leider auch keinen richtigen Hinweis.
    Da steht nur
    NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
    (aber diese Meldung kommt auch wenn's normal läuft)


    Also habe ich mal in dieses Verzeichnis geschaut. Dort fand ich drei Unterverzeichnisse und die Dateien
    .etab.lock
    etab
    rmtab
    state
    xtab


    Hmmm, eine übrig gebliebene Lock-Datei ist immer verdächtig ;-)
    Also einfach mal gelöscht. Die vier anderen Datei auch gelöscht (vorher natürlich gesichert).


    Nun läuft es wieder!

    Nach einem reboot


    Tja, und so steht es bis zum nächsten reboot... :-(