[gelöst] Faden verloren: live Plugin auf debian-Kiste nicht mehr erreichbar

  • Sorry,


    ich bitte um Brainstorming, meinetwegen auch Shitstorm.


    Eigentlich wollte und habe ich nur folgendes gemacht:
    Debian_Kernel aus experimental auf debian testing installiert. Alle sonstigen Pakete aus testing auf den aktuellen Stand. DVB-Treiber aktualisiert.


    Dann vdr-1.7.30 gezogen. Kompiliert.
    Alles läuft fein und startet ohne Auffälligkeiten:
    vdr, femon, epgsearch, streamdev und xineliboutput.


    Auch das live-Plugin läuft. Zumindest im setup menu (via xineliboutput) wird es angezeigt und ich kann dort die üblichen Optionen setzen. Ich kann die debian-Kiste auch mit ssh erreichen. Versuche ich auf dem gleichen Client aber live aufzurufen, sagt mir Firefox
    "Firefox can't establish a connection to the server at 192.168.0.121:8000"
    oder Konqueror
    "The server 192.168.0.121 refused to allow this computer to make a connection."


    Habe via -p Option den vdr und live mit verschiedenen Ports gestartet - immer der gleiche Misserfolg.


    Dabei ging das doch vor dem Update wie geschmiert, sogar mein Smartphone kam auf die Seiten vom live-Plugin.


    Also, vdr-1.7.30 in Verdacht - daher die alten sourcen mit vdr-1.7.24 gestartet.
    Nach kleiner Korrektur in den vdr-sourcen in der Datei font.c (patch wegen der neuen libfontconfig-Version) startet der alte, aber neu übersetzte vdr auch wieder. Dann meldet live, dass es die Datei libtntnet.so.9 nicht findet. Also auch live neu übersetzt.


    Finales Ergebnis:
    Das gleiche wie bei vdr-1.7.30. Bild via xineliboutput, live im Setup-menu (also tatsächlich gestartet?!), aber wieder erreicht kein Browser die Seiten des Plugin.


    Ich sehe jetzt vor lauter Wald die Bäume nicht mehr und bin wie eingangs gesagt, für jede Idee dankbar. Irgendwo muss ich doch mit dem Ellenbogen drauf gekommen sein und was kaputt gemacht haben?

    Hauppauge WinTV-dualHD auf Desktop mit archlinux ...


    2 Mal editiert, zuletzt von berndb ()

  • Ist der Port vom Live-Plugin nicht 8008 ? Zumindest bei mir ist er das und ich habe ihn nicht manuell geändert.

    Registered VDR User #23
    ===========================================
    VDR1: Gen2VDR 3.0beta8
    Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz mit 2GB Ram
    z.Z. mit Intel Onboard Grafik, beim nächsten SW-Update kommt ne nvidia 9300 rein mit VDPAU
    TT2300
    TT3200

  • Hast du vielleicht in deiner Kiste mehrere Netzwerkkarten? Ich weiß nicht, wie tntnet arbeitet und ob es automatisch auf allen Interfaces lauscht, aber man kann laut Wiki dort irgendwas einstellen.


    Ansonsten mal von deinem VDR aus mit wget oder curl localhost:8008 aufrufen. Wenn selbst das nicht klappt, weiß ich auch nicht mehr weiter.


    Es gäbe dann noch die Varianten mit Port-Analyse zu gucken, ob die Ports überhaupt geöffnet worden. Man könnte die syslogs von Live prüfen, usw.


    Medion Digitainer; AsRock B75 Pro3-M, Celeron G540; Kingston Value 4GB
    Samsung SpinPoint 250GB 2,5"; Samsung WriteMaster DVD-Brenner;
    TT-S2-6400, 2x TT-S2-1600, Ubuntu 12.04 mit YaVDR-Paketen. VDR 1.7.27, UPnP/DLNA-Plugin

  • Also ab einer bestimmten tntnet Version benötigt live zwingend den Parameter "-i" um es an ein bestimmtes Interface (auch wenn es nur eines gibt) zu binden.


    cu

  • Mit der -i Option hatte ich schon gespielt, dachte aber, da muss man die IP des Clients eintragen, von dem man live aufruft. Offenbar muss da aber die IP des Servers, oder genauer des Netzwerksgerätes, dass das live-Plugin in das Netzwerk trägt, mit der -i Option übergeben werden.
    "Schuld" daran, dass es vorher ohne ging, ist dann wohl das Update von libtntnet von Version 9 auf 10.


    Jedenfalls starte ich in meinem Fall das Live-Plugin mit


    -P "live -p 8081 -i 192.168.0.121"


    und tata, ich erreiche den vdr auch wieder via live-Plugin.


    Merci bien für alle Hinweise !!!

  • Ich habs mal in den live Bugtracker geschrieben. Bisher betraf (oder betraf nicht, weil die habens ja vorkonfiguriert bekommen) es ja nur die yaVDR und restfulapi Nutzer *).


    cu


    *) Wobei ich vermutlich der einzige "nicht yaVDR" restfulapi Pluginnutzer bin ;)

Jetzt mitmachen!

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