vdr-sxfe läuft nicht

    Hallo zusammen,


    bislang lief mein VDR mit vdr-sxfe als Frontend tadelos. Plötzlich will vdr-sxfe nicht mehr. Beim Versuch die Anwendung zu starten, erhalte ich folgende Fehlermeldung:


    [13165] [vdr-fe] fe_xine_open: xine_open("xvdr://localhost:37890#nocache") failed
    Error opening xvdr://localhost:37890


    Der VDR läuft und lauscht auch auf dem Port:

    $ netstat -tulpn | grep 37890


    tcp 0 0 0.0.0.0:37890 0.0.0.0:* LISTEN 15209/vdr
    udp 0 0 255.255.255.255:37890 0.0.0.0:* 15209/vdr


    Im syslog gibt's vom VDR noch folgende Meldung:



    Jun 20 22:05:30 vdr vdr: [15231] [discovery] Received valid discovery message VDR xineliboutput DISCOVERY 1.0#015#012Client: 255.255.255.255:37890#015#012#015

    Jun 20 22:05:30 vdr vdr: [15231] [discovery] BROADCAST: VDR xineliboutput DISCOVERY 1.0#015#012Server port: 37890#015#012Server version: xineliboutput-1.0.90-cvs#015#012#015


    Ich habe bereits die Konfigurationsdatei config_xineliboutput entfernt - das hat leider nichts gebracht.


    Es sind die aktuellen e-tobi Pakete installiert.


    Hat jemand einen Tipp für mich?


    Gruß
    Rob

    Evtl löst localhost nicht nach 127.0.0.1 auf? (testen mit: "grep localhost /etc/hosts" oder "ping localhost")
    Und ist in der /etc/vdr/plugins/xineliboutput/allowed_hosts.conf evtl nur 127.0.0.1 erlaubt? (testen mit "cat /etc/vdr/plugins/xineliboutput/allowed_hosts.conf")

    Wenn du vdr-sxfe startest, achte mal auf die libxine version, ob die installierte mit der für sxfe beim compilieren benutze zusammen passt.
    Nutzt du vdpau? libvdpau evtl nicht installiert? Probiere es auch mal mit --video=xv als option.

    Habe leider nach einem Upgrade von squeeze auf wheezy exakt das gleiche Problem, ich nutze ebenfalls das e-tobi Repository.
    Unter squeeze lief alles problemlos.


    Zitat von SOliver

    Wenn du vdr-sxfe startest, achte mal auf die libxine version, ob die installierte mit der für sxfe beim compilieren benutze zusammen passt.
    Nutzt du vdpau? libvdpau evtl nicht installiert? Probiere es auch mal mit --video=xv als option.


    Ich nutze kein vdpau.
    Ein startx geht einwandfrei, der X-Server funktioniert also.
    vdr-sxfe gibt folgende Versionsinformationen aus: vdr-sxfe 1.0.90-cvs (build with xine-lib 1.2.2, using xine-lib 1.2.2)
    Die Option --video=xv bringt keine Änderung.
    Gestartet wird vdr-sxfe via

    Code
    xinit -e /usr/bin/vdr-sxfe --aspect=16:9 --width=1368 --height=768 --audio=alsa --syslog --reconnect -f xvdr+tcp://127.0.0.1


    Der VDR selbst läuft problemlos im Hintergrund (kann Umschalten und das via syslog verifizieren, auch wenn ich kein Bild habe).


    Hier mal die Ausgabe von /var/log/Xorg.0.log


    Ausserdem noch ein kleiner Auszug des syslog...


    ...und ein apt-cache policy für einige libxine-Pakete:

    Hier mal noch die Ausgabe eines blanken vdr-sxfe -f xvdr+tcp://localhost (also ohne xinit -e davor):


    Ich bin wirklich ratlos und wäre für jede Hilfe, wo ich noch ansetzen könnte, dankbar...

    Zitat von rüsseltier

    Hier mal noch die Ausgabe eines blanken vdr-sxfe -f xvdr+tcp://localhost (also ohne xinit -e davor):


    Ohne xinit davor wird ja kein X-Server gestartet. Hast du ihn denn vorher mit startx, oder auf andere Weise gestartet?


    Wenn ja, dann bedeutet die Fehlermeldung, dass der X-Server unter einem anderen user als vdr-sxfe gestartet wurde und du

    Code
    xhost +

    brauchst um dem anderen User Zugriff zu erlauben.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

    Einmal editiert, zuletzt von gda ()

    Danke für Deine Hilfsbereitschaft!


    Ich lies und lasse vdr-sxfe über folgenden Eintrag in der /etc/inittab starten:
    sxfe:23:respawn:xinit -e /usr/bin/vdr-sxfe --aspect=16:9 --width=1368 --height=768 --audio=alsa --syslog --reconnect -f xvdr+tcp://127.0.0.1


    Ein xinit -e xterm wird ganz normal ausgeführt.
    Ich sehe auch in der Xorg.0.log nichts, was einen Hinweis geben könnte (der Auszug weiter oben ist nach einem xinit -e vdr-sxfe).


    Wie kann ich denn feststellen, ob vdr-sxfe und xterm die selben Rechte in X haben?


    Hier noch ein Auszug des VDR-Startes aus dem syslog...


    ...und der Inhalt der /etc/vdr/plugins/plugin.xineliboutput.conf:

    Zitat von rüsseltier

    Ich lies und lasse vdr-sxfe über folgenden Eintrag in der /etc/inittab starten:
    sxfe:23:respawn:xinit -e /usr/bin/vdr-sxfe --aspect=16:9 --width=1368 --height=768 --audio=alsa --syslog --reconnect -f xvdr+tcp://127.0.0.1


    Das ist doch jetzt Quatsch, du hast in dem Post, auf den ich geantwortet habe, geschrieben, dass du vdr-sxfe nicht mit xinit davor gestartet hast. Wie hast du dann in dem Fall den Xserver gestartet?


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

    Also, ich habe jetzt als root in einer Konsole X gestartet und in einer zweiten vdr-sxfe --aspect=16:9 --width=1368 --height=768 --audio=alsa --syslog --reconnect -f xvdr+tcp://127.0.0.1.


    Ergebnis im syslog...


    und die Ausgabe von vdr-sxfe auf der Konsole:


    Ein anschliessendes export DISPLAY=:0.0 ändert den dbus-daemon-Fehler wieder auf den üblichen gnome-Fehler:

    Code
    Sep  8 09:54:12 vdr-dg vdr-sxfe[3417]: [3417] [scrnsaver] Error: The name org.gnome.SessionManager was not provided by any .service files
Sep  8 09:54:12 vdr-dg vdr-sxfe[3417]: [3417] [scrnsaver] Error: The name org.gnome.ScreenSaver was not provided by any .service files

    Ich habe auch nochmal die Freigaben der allowed_hosts.conf und svdrphosts.conf kontrolliert, beide haben den Inhalt:

    Code
    127.0.0.1             # always accept localhost
192.168.178.0/24     # any host on the local net


    Auch netstat -tulpn | grep 37890 führt zu
    tcp 0 0 127.0.0.1:37890 0.0.0.0:* LISTEN 2915/vdr


    Hat jemand noch eine Idee?
    Die scrnsaver-Meldung sollte ja nicht die Ursache sein...
    Gibt es eine Chance, eine detailliertere Fehlermeldung als das ominöse fe_xine_open: xine_open("xvdr+tcp://127.0.0.1#nocache") failed zu erhalten?


    Denn irgendwo ist es ja kurios: ich hab an sich nichts anderes gemacht, als in der /etc/apt/sources.list squeeze durch wheezy zu ersetzen und dann ein apt-get update && apt-get dist-upgrade durchzuführen.

    Zitat von rüsseltier
    Code
    127.0.0.1             # always accept localhost
192.168.178.0/24     # any host on the local net


    Soweit ich weiß gilt das nicht additiv. Die zweite Zeile überschreibt die erste. Versuche es also mal mit 192.168.178.XX statt mit 127.0.0.1 in der vdr-sxfe Kommandozeile.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

    Sind meines Wissens nach additiv ("This file describes a number of host addresses")


    Habe trotzdem probeweise mal beide Dateien auf
    127.0.0.1 # always accept localhost
    und dann noch in einem zweiten Versuch auf
    0.0.0.0/0 # any host on any net (USE THIS WITH CARE!)
    geändert, natürlich jeweils mit anschliessendem /etc/init.d/vdr restart -> keinerlei Änderung im Verhalten oder in den logs.

    Gerade mal xinit -e vdr-sxfe mit --verbose aufgerufen, dadurch habe ich nun ein paar Zeilen mehr im syslog:


    Etwas weiterhelfendes erkenne ich da aber auch nicht wirklich... :|


    Kann vielleicht mal ein Nutzer von VDR 2.0.x + xineliboutput von seiner /var/lib/vdr/setup.conf die xineliboutput-Parameter posten?
    Nicht, dass da bei mir nach dem Upgrade neue Parameter fehlen...

    So, nun habe ich mal einen strace gemacht:


    Täusche ich mich, oder liegt das Problem bei xine: cannot find input plugin f...,
    was soviel wie xine: cannot find input plugin for MRL xvdr+tcp://127.0.0.1:37890#nocache) bedeuten könnte?

    Zitat von rüsseltier

    Kann vielleicht mal ein Nutzer von VDR 2.0.x + xineliboutput von seiner /var/lib/vdr/setup.conf die xineliboutput-Parameter posten?
    Nicht, dass da bei mir nach dem Upgrade neue Parameter fehlen...


    Code
    -P "xineliboutput --local=none -f --remote=37890"


    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Oh, meine Nerven...
    Ich habe den Fehler endlich gefunden:
    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660316
    Die Ursache sind Pakete von deb-multimedia.org.
    Also, das Repository aus der sources.list rausschmeissen und folgendes ausführen:

    Code
    apt-get update
apt-get remove libxine2 libxine2-xvdr xine-console xineliboutput-sxfe libxine2-bin libxine2-console libxine2-ffmpeg libxine2-misc-plugins  libxine2-x
apt-get install libxine2 libxine2-xvdr xine-console xineliboutput-sxfe libxine2-bin libxine2-console libxine2-ffmpeg libxine2-misc-plugins  libxine2-x


    Jetzt läuft es wieder bei mir.

    Slightly OT, aber doch in dem Zusammenhang:
    Die deb-multimedia.org-Pakete haben in der Versionsnummer ja alle noch dmo stehen.
    Wie kann ich mir den alle noch installierten Pakete mit dmo in der Versionsnummer anzeigen lassen?


    In jedem Fall ein Danke an gda und auch seahawk1986 für die Mühe!

    Die dmo Pakete machen aber schon Sinn, beispielsweise für aktuellere Versionen von ffmpeg oder andere multimediageschichten. Du kannst meiner meinung nach auch festlegen, dass die xine-Pakete von etobi kommen.

    - Client1: Thermaltake DH 102 mit 7" TouchTFT * Debian Stretch/vdr-2.4.0/graphtft/MainMenuHooks-Patch * Zotac H55-ITX WiFi * Core i3 540 * 4GB RAM ** Zotac GT630 * 1 TB System HDD * 4 GB RAM * Harmony 900 * satip-Plugin

    - Client2: Alfawise H96 Pro Plus * KODI
    - Server: Intel Pentium G3220 * DH87RL * 16GB RAM * 4x4TB 3.5" WD RED + 1x500GB 2.5" * satip-Plugin
    - SAT>IP: Inverto iLNB

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden