Beiträge von wofritz

    Der VDR heißt hdvdr.wofritz.de. Diesen Namen erhält man per "hostname" und auch in Python:

    Code
    root@hdvdr(5):~# python
    Python 2.7.3 (default, Feb 27 2014, 19:58:35) 
    [GCC 4.6.3] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import socket
    >>> socket.gethostname()
    'hdvdr.wofritz.de'
    >>>


    Das nach "avahi" gefilterte Syslog:


    Aber hdvdr.local scheint ihm auch bekannt zu sein, er antwortet auf ping:

    Code
    root@hdvdr(11):~# ping hdvdr.local
    PING hdvdr.local (192.168.1.5) 56(84) bytes of data.
    64 bytes from hdvdr.wofritz.de (192.168.1.5): icmp_req=1 ttl=64 time=0.046 ms


    192.168.1.5 ist die IP des VDR
    aber

    Code
    [oot@hdvdr(14):~# ping hdvdr.wofritz.de
    PING hdvdr (127.0.1.1) 56(84) bytes of data.
    64 bytes from hdvdr (127.0.1.1): icmp_req=1 ttl=64 time=0.043 ms
    64 bytes from hdvdr (127.0.1.1): icmp_req=2 ttl=64 time=0.050 ms

    Die Sache hat sich erledigt.


    Ich weiß zwar nicht, warum der VDR seine eigenen Verzeichnisse mountet, aber die Meldung gibt es nur, wenn man den VDR sofort nach dem Hochfahren wieder runterfahren will. Ich hatte ein wenig experimentiert, um die Bootzeit zu verringern und bei diesen Tests den VDR sofort nach dem Erscheinen des Bildes wieder runterfahren wollen.


    Wenn man ein wenig wartet, fährt er wie gewohnt runter.


    Wolfgang

    Liegt wohl eher an den Einträgen in der "exports".


    Guter Tip!


    Die wird anscheinend automatisch erzeugt und sieht so aus:


    Und ist ziemlich frisch:

    Code
    ls -l /etc/exports
    -rw-r--r-- 1 root root 1725 Jun 14 07:32 /etc/exports


    Es scheint der avahi-daemon zu sein, der die mounts macht, aber warum?

    Hallo,


    eben wollte ich meinen VDR abschalten, was er aber verweigerte mit "NFS mount still active".


    Nun habe ich festgestellt, dass der VDR sich selbst per NFS mountet, wie "mount" zeigt:

    Code
    hdvdr.local:/srv/audio on /media/Musik/hdvdr type nfs (rw,soft,intr,addr=192.168.1.5)
    hdvdr.local:/srv/picture on /media/Bilder/hdvdr type nfs (rw,soft,intr,addr=192.168.1.5)
    hdvdr.local:/srv/share/vdr on /srv/vdr/video.00/hdvdr type nfs (rw,soft,intr,addr=192.168.1.5)
    hdvdr.local:/srv/video on /media/Video/hdvdr type nfs (rw,soft,intr,addr=192.168.1.5)


    Das war mir bisher nie aufgefallen. Ein gestriges Update hat einige VDR-spezifische Pakete aktualisiert, u.a. yavdr-base. Könnte es daran liegen?


    VDR laut Signatur auf aktuellem Testing-Stand.

    Moin!


    Habe den r8168 wieder deinstalliert. Mit diesem hatte ich Ping-Delays von 500 ms bei ca. jedem 2. Ping, und beim ssh-Zugriff deutliche Verzögerungen bei Tastendrücken. Diese Effekte verschwanden, wenn man die Geschwindigkeit umschaltete, und zwar sowohl Richtung 1G -> 100 M als auch 100M -> 1G, aber immer nur bis zum nächsten Reboot.


    Mit dem r8169 habe ich diese Effekte nicht.


    Es gibt von Realtek eine neuere Version des r8168, aber ich habe im Moment keine Lust, den zu testen.


    Wolfgang

    Welches Modul verwendet denn der 3.8.0-41er, wenn der r8168 nicht per dkms einkompiliert ist?


    r8169


    Ich schau mir mal an, ob sich das Buildproblem lösen lässt. Kann aber ein wenig dauern.


    <edit>
    Es gibt das r8168-dkms Modul auch für trusty. Vielleicht lässt sich das ja bauen.
    </edit>


    Wolfgang

    Also im

    Ich wollte am Wochenende auf linux-image-generic-lts-trusty (3.13.0-27-generic) updaten und musste feststellen, dass hier der
    Realtektreiber aus r8168-dkms nicht baut. Der im Kernel befindliche r8168 führt wieder zu den bekannten Problemen. :/


    Also in 3.13.0-27-generic ist der r8168 schon drin oder meinst Du doch den r8169?


    Die Buildprobleme könnte ich mir mal auf meinem Notebook ansehen, da ist Trusty drauf. Am VDR möchte ich ungern spielen, der läuft gerade so schön stabil ;)

    Versuch mal unter System -> Video die Experten-Ansicht zu aktivieren und VAAPI zu deaktivieren.


    Das scheint auch bei anderen "Seltsamkeiten" zu helfen. Bei mir wurden nach dem Update Youtube-Videos nicht mehr richtig abgespielt (Bildschirmsalat), evt. nur im Zuammenhang mit der automatischen Umschaltung der Bildfrequenz. Nach dam Deaktivieren von VAAPI funktionierte alles wieder wie gewohnt.

    Hmmm, bei mir leider nicht. Welchen Kernel hast du momentan aktiv?
    Bei mir läuft der 3.8.0-41 also linux-image-generic-lts-raring.


    Bei mir auch. Hast Du mal geschaut, ob wirklich der r8168-Treiber geladen ist?


    Hier funktioniert WOL ohne ständige Neustarts mit dem Board. Ich musste das Board allerdings erstmal komplett 2x stromlos setzen, damit das Board nicht neu startete.


    Hmm, das habe ich beim meinen Tests vor dem Treiberwechsel auch gemacht, um zu checken, ob das Board danach auch noch neu startete. Aber ich meine, die Neustarts wären erst nach dem Treiberwechsel weggewesen. Bin aber nicht sicher.


    Ich habe nun den VDR immer per WoL gestartet, bisher kein Neustart mehr.


    Blöde Sache, ich dachte wir hätten jetzt eine eindeutige Lösung :§$%

    Bei mir fährt er nach jedem Start per WOL nach dem Runterfahren wieder hoch.


    Mit einer anderen LAN-Karte habe ich nicht getestet mangels Hardware.


    Mmh, Realtek-Chip... Da gibts doch einen kernel-externen Treiber speziell für den Chip, der auf dem Board sitzt, den man mit DKMS einbinden kann... Vielleicht teste ich den mal.


    Was ich auch nicht weiß und nachprüfen werde: "Vergisst" das Board nach einer längere kompletten Trennung vom Netz, dass es nach dem WoL wieder hochfahren will?

    globber: Das Starten mittels WoL funktioniert ja. Das Problem ist, dass mein Board nach dem Runterfahren sofort wieder hochfährt, wenn es per WoL gestartet wurde. Dieses Verhalten ist auch von anderen Boards bekannt, die dafür angegebenen Abhilfen funktionieren leider bei mir nicht.

    Im Beitrag 90 kämpfte "wofritz" noch mit dem gleichen Problem. Egal welche Einstellungen ich nach den Tipps hier im Forum oder dem Internet machte, nichts ändert sich. :(


    Ich kämpfe zwar nicht mehr mit dem Problem, aber es ist leider immer noch da. Inzwischen dürfte ich auch alle Tips ausprobiert haben. Auch ein testweise installiertes Standard-Ubuntu zeigte den gleichen Fehler.


    Ich habs aufgegeben, zumal ich das WoL nur gelegentlich nutze.


    Die 13-15 Sekunden, die das Board beim Booten im BIOS verbringt, stören mich auch, aber auch dafür habe ich keine Lösung gefunden.

    Guten Tach,


    heute wurde beim dist-upgrade auf meinen VDR (siehe Sig) xmbc 13 installiert und ich musste von vnsiserver3 auf vnsiserver5 (bzw. vnsiserver) umsteigen.


    Beim apt-get remove vnsiserver3 kam folgende Ausgabe:

    Code
    Die folgenden Pakete wurden automatisch installiert und werden nicht mehr benötigt:
      vdr-plugin-skinpearlhd vdr-skin-anthra-1920-fse python-qt3 python-sip vdr-skin-narrowhd vdr-skins-anthra vdr-plugin-text2skin
      libqt3-mt vdr-plugin-extrecmenu vdrsymbols-ttf
    Verwenden Sie »apt-get autoremove«, um sie zu entfernen.


    Was könnte die Ursache sein?


    Einige der Plugins werden beim VDR-Start geladen.


    Wolfgang