vdr-plugin-live für VDR 2.3.x ...

    Zitat von jasminj

    Ja, das kann ich reproduzieren. Danke, ich werde es mir anschauen.

    Fixed auf beiden Branches.


    LG,
    Jasmin

    Gefällt mir 1

    Hi!


    Nachdem jetzt die Umstellungen im Makefile und das Integrieren des OSD Patches abgeschlossen ist, habe ich das Repository zusammen geräumt.


    Auf Branch vdr-2.3.x ist jetzt alles verfügbar.
    Branch vdr-2.3.x_work ist mein Branch für Erweiterungen zum Test, bevor sie auf den vdr-2.3.x Branch gemerged werden. Dieser Branch wird von mir ev., auch in der Commit History umgeschrieben (wie gerade eben) und muss deshalb beim Updaten mit Vorsicht behandelt werden.


    Die anderen Branches (vdr-2.3.x_osd und vdr-2.3.x_osd_work) wurden gelöscht.
    Bitte die URLs für die Distributionen entsprechend anpassen. Wenn TAGs gewünscht werden, bitte um Info.


    Außerdem bin ich am Überlegen recht bald den master auf 2.3.x umzustellen und den derzeitigen master auf vdr-2.x.x (oder so ähnlich) umzubenennen. Vorher muss ich aber die Lock Reihenfolge fertig machen (ist immer noch falsch !) und das eine Feature mit den inaktiven Such-Timern implementieren.


    LG,
    Jasmin

    Gefällt mir 1
    Zitat von jasminj

    Der Branch "vdr-2.3.x_work" compiliert jetzt mit VDR 2.2.0 und Branch "vdr-2.3.x_osd_work" auch. Solltest letzteren verwenden, weil der wird der neue Head.
    Ich werde es anscheinend doch schaffen die Kompatibilität zu VDR 2.2.0 aufrecht zu erhalten. Wobei ich derzeit nicht mit VDR 2.2.0 testen kann. Also wundere dich ned, wenn irgendwas nicht funktioniert.

    Hat das funktioniert?


    Zitat von jasminj

    Ja, das wäre fein, dann brauch ich das nicht machen.

    Gibt es da schon irgendwas? :O


    LG,
    Jasmin

    Hi!


    Ich habe eine neue Version am vdr-2.3.x_work Branch, die beim Bauen nicht so gesprächig ist (kann man mit "VERBOSE=1 make" wieder gesprächig machen).
    Und einen Fix für das "gen_version_suffix.h" erzeugen hab ich auch drinnen.


    Ganz wichtig sind aber die Lock Order fixes. Ich bin mir da auch nicht sicher, ob das wirklich funktioniert. Also ned erschlagen, wenn was nicht geht.
    Ich warte noch auf einen Lock Order "Debugger" von Klaus. Damit sollten wir in allen Plugins alle falschen Reihenfolgen schnell finden können.


    LG,
    Jasmin

    Leider stimmt die Skalierung in der Detailansicht nicht mehr:


    [Blockierte Grafik: http://imagizer.imageshack.us/v2/280x200q90/924/4TaaS0.png]


    Auch oben, wird "Hole Status ..." nicht mehr korrekt angezeigt.


    Als erstes, vielen Dank für die ganze Arbeit die ihr in epgsearch und vdr-live steckt.


    Beim vdr-live des VDR version 2.2 gibt es eine kleine Unanehmlichkeit: man kan das EPG eines inaktiven Timers nicht einsehen und ich nehme an, es ist noch das gleiche im aktuellen development branch.


    Obwohl ich wegen Klaus Antwort von damals davon ausgehe, dass etwas dagegen zu unternehmen wahrscheinlich immer noch sehr schwierig sein wird, wollte ich es trotzdem hier erwähnen.

    Wenn man ein Debian-Paket für live im pbuilder bzw. auf Launchpad baut, schlagen wohl die Befehle fehl, die das LIBDIR bzw. LOCDIR betreten wollen, (weil das Paket vdr nicht installiert ist und LIBDIR und LOCDIR nicht in der Build-Umgebung existieren): https://github.com/jasmin-j/vd…r-2.3.x_work/Makefile#L56
    Das hat dann den Effekt, dass die libvdr-live*.so Datei und die Locale-Dateien beim make install nicht in den zuvor von pkg-config ermittelten Pfaden, sondern direkt im DESTDIR landen - wäre es da nicht sinnvoller an der Stelle eine Funktion wie abspath zu verwenden?

    Zitat von https://www.gnu.org/software/make/manual/html_node/File-Name-Functions.html

    $(abspath names…)
    For each file name in names return an absolute name that does not contain any . or .. components, nor any repeated path separators (/). Note that, in contrast to realpath function, abspath does not resolve symlinks and does not require the file names to refer to an existing file or directory. Use the wildcard function to test for existence.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    So hab mich auch mal an die 2.3.5 rangetraut, leider kann ich das live nicht aufrufen. Grundsätzlich startet das live
    wenn ich es aber aufruf < http://192.168.178.23:8008 > passiert nichts.
    wenn ich dann wieder auf die 2.2 umstelle geht wieder alles



    svdrphosts

    VDR 4: AMD Kabini 5310, Asrock AM1H-ITX, Gen2Vdr V6, Cine S2, Atric , Harmony 515 , Streacom ST-F7CB EVO

    Beim Start des VDR sollten eigentlich solche Ausgaben von live kommen:


    Code
    vdr01_64 ~ # grep "\[live" /log/messages
Jun 03 07:31:01 [vdr] [6549] [live] INFO: validating server ip '192.168.177.52'
Jun 03 07:31:04 [vdr] [6658] [live] INFO: attempt to listen on ip = '192.168.177.52'
vdr01_64 ~ #


    Startes Du denn das Plugin nicht mit dem Parameter "ip"?


    README:

    Code
    [...]
You can also specifiy this parameter via commandline:


  -p PORT,  --port=PORT     use PORT to listen for incoming connections
                            (default: 8008)
  -i IP,    --ip=IP         bind server only to specified IP, may appear
                            multiple times
                            (default: 0.0.0.0, ::0)
    Zitat

    Startes Du denn das Plugin nicht mit dem Parameter "ip"?

    ehrlich gesagt hab ich noch nie gemacht, und ging trotzdem


    aber was soll ich sagen


    Zitat

    Versuch mal live mit dem Parameter '--ip=0.0.0.0'

    war die Lösung


    danke euch beiden

    VDR 4: AMD Kabini 5310, Asrock AM1H-ITX, Gen2Vdr V6, Cine S2, Atric , Harmony 515 , Streacom ST-F7CB EVO

    Mir scheint, da hat sich was geändert. Am 2. Juni habe ich wohl live upgedated, da kam wohl dieses bindv6only dazu. Am 3. Juni habe ich dann die 0.0.0.0 hinzugefügt. Ohne die 0.0.0.0 lauscht live per ip4 nur auf localhost, nicht auf der externen IP. Vorher war die Angabe nicht nötig, da default.



    Christian

    Zitat von hopsi

    Am 2. Juni habe ich wohl live upgedated, da kam wohl dieses bindv6only dazu. Am 3. Juni habe ich dann die 0.0.0.0 hinzugefügt.

    Das glaube ich nicht. "bindv6only" kommt nur in setup.cpp vor und ein "git blame setup.cpp" sagt:

    Sprich der Code ist seit 2011 nicht angerührt worden.
    Ich kann mich nicht erinnern an der Stelle irgendetwas verändert zu haben.


    LG,
    Jasmin


    PS: Ich arbeite gerade an den Lock fixes, falls es jemanden interessiert.

    Zitat von seahawk1986

    wäre es da nicht sinnvoller an der Stelle eine Funktion wie abspath zu verwenden?

    Hab das mal in commit 99cdbf48 eingebaut. Bitte testen.


    LG,
    Jasmin

    Gefällt mir 1
    Zitat von jasminj

    PS: Ich arbeite gerade an den Lock fixes, falls es jemanden interessiert.

    Ich habe zwei Lock Order fixes gemacht. So wie ich das jetzt mache, könnte es ev. zu Problemen kommen, wenn zwei Threads sich gegenseitig die Objekte in den Listen raus löschen. Ich will das aber mal so ausprobieren, weil auf diese Art die Lockings kürzer gehalten werden.
    Hintergrund: Die Timer Funktion in epgsearch lockt die Timer Liste und da darf keine andere Liste gelockt sein, also muss man vor dem Aufruf alle Locks freigegeben haben.


    Bitte testen, die neue Version steht im Git auf Branch vdr-2.3.x_work.
    Man sieht mit VDR Version 2.3.6 jetzt Locking Reihenfolge Probleme. Bitte reporten, wenn es noch etwas gibt, was ich nicht gesehen habe.


    LG,
    Jasmin

    Zitat von jasminj

    Das glaube ich nicht. "bindv6only" kommt nur in setup.cpp vor und ein "git blame setup.cpp" sagt:


    Ich glaubs Dir ;)


    Nach etwas Recherche habe ich nun rekonstruiert, daß ich am 2. Juni vieles geupdatet habe, unter anderem gcc von 4.x auf 5.4.0.
    Dabei habe ich auch libtntnet und cxxtools neu gebaut. Die Version (2.2.1) ist allerdings gleich geblieben.
    Nachdem libtnt in setup.cpp ganz in der Nähe von bindv6only auftaucht, könnte sich auf dieser Ebene hier doch was in meinem System geändert haben. Ich hatte zuvor nie einen '[live] INFO: bindv6only=' im log. Kernel ist unverändert, System nicht neu gestartet seit 2 Wochen.


    Christian

    Selbes Verhalten wie bei Hopsi, habe am Wochenende das Live Plugin aktualisiert und seit dem die Log Modung "INFO: bindv6only...".
    Ich muss auch explizit --ip=0.0.0.0 angeben, damit ich Zugriff habe.


    Wenn ich zurück auf die ältere Live Version wechsele, dann gibt es diese "INFO: bindv6only..." nicht.


    Funktional sieht es sonst sehr gut aus!


    Ich bin auch froh, das es wieder eine Anlaufstelle gibt, wo man das Live Plugins findet...


    Gruß
    Stefan

    Zitat von fox71

    Wenn ich zurück auf die ältere Live Version wechsele, dann gibt es diese "INFO: bindv6only..." nicht.

    Was ist die ältere Version?
    Welcher Git Stand?
    Irgendwie muss sich dann etwas anderes geändert haben, was ich mir anschauen muss.


    Zitat von fox71

    Funktional sieht es sonst sehr gut aus!

    Bitte immer wieder in SysLog schauen, ob es einen Lock Sequence Error gibt:

    Ich habe einfach noch nicht alle Stellen gefunden, weil man die ja auch reproduzieren muss um das zu beheben. Außerdem spielt hier auch das epgsearch Plugin mit. Wenn das geändert wird, kann es zu einer falschen Lock Reihenfolge auch ohne Code Änderung in Live kommen.



    Zitat von fox71

    Ich bin auch froh, das es wieder eine Anlaufstelle gibt, wo man das Live Plugins findet...

    Ich mache das mal jetzt, aber ob ich es sehr lange machen kann weiß ich ned. Und ich muss noch ein zwei offene Punkte implementieren.


    LG,
    Jasmin

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden