[solved] vdr-vnsiserver compiliert nicht mit vdr-2.1.2 und v3 vs. v4

  • UPDATE: Geloest durch vdr-vnsiserver-0.9.3_p20140104.ebuild von hd_brummy in vdr-devel overlay - Danke!


    ----------------
    Aehnlich wie beim vdr-mplayer plugin, das vdr-vnsiserver (versionen 0.9.0_p20130105 und 0.9.2_p20131021 nicht mit vdr-2.1.2
    compilieren, weil es auf die funktion VideoDiskSpae zugreift, die in 2.1.2 halt nur noch eine Objektfunktion ist.


    Temporaer gefixed in /usr/include/vdr/videodir.h via:
    #define VideoDiskSpace(x) cVideoDirectory::VideoDiskSpace(x)


    scheint dann ganz gut zu tun mit XBMC, also einfacher fixup.


    Wem muss man da Bescheid geben, um das zu fixen ?


    Ausserdem: die version 0.9.0 vom vnsiserver unterstuetzt nur version 3 des VNSI protokolls, also fuer Frodo. Sollte es da nicht
    gegenseite Abhaengigkeiten in den ebuilds eben, so dass man da nicht aus versehen die version 0.9.2 compiliert, wenn man
    XBMC 12.x im tree hat ?


    Ausserdem: nachdem die plugins von frodo/0.9 vnsiserver und die von xbmc-13/0.9.2 vnsiserver4 heissen, also verschiedene
    namen haben, kann man die nicht in verschiedene slots setzen, also zulassen dass beide gleichzeitig installiert werden Macht vor allem sinn,
    wenn man auch beide gleichzeitig aktivieren kann um so gleichzeitig xbmc-12 und xbmc-13 clients zu unterstuetzen. Weiss nicht ob das
    gehen wuerde.

  • Yeah, figuring out how to patch the source of vnsiserver isn't the real issue. Trying to figure out how to get that into a gentoo ebuild version is. Otherwise, how would i use that diff when i want to emerge vnsiserver ?

  • @ te36


    ich habe dir/euch die version
    vdr-vnsiserver-0.9.3_p20140104.ebuild
    ins overlay vdr-devel gelegt, bitte testen.
    das plugin ist dann vnsiserver5


    zu: Wem muss man da Bescheid geben, um das zu fixen ?
    Ich glaube ich hab dich schon einmal auf https://bugs.gentoo.org verwiesen
    bitte den bug dann gleich an vdr(at)gentoo.org assignen (spart unserem bug-wrangler arbeit)
    wenn das ebuild aus einem overlay kommt, bitte noch in der betreffzeile vermerken [overlay vdr-devel]
    und folgende angaben bitte nicht vergessen!:
    output from "emerge --info"
    und das komplette compile log attachen


    erreichen kannst Du mich (oder sicherlich einen von den anderen mitglieder da) auch über IRC auf freenode #gentoo-vdr


    und natürlich schau ich auch regelmässig hier vorbei :)


    zum slotten:
    könnte in diesem fall functionieren
    bitte mal local bei dir die 3 ebuilds
    vdr-vnsiserver-0.9* editieren
    Zeile
    SLOT="0"
    in
    SLOT="0/${PF}"
    ändern


    auf eins von den 3 ebuilds ein digest ausführen


    danach sollte jedes der 3 ebuilds einzeln emerge bar sein.


    eventuell kann es zu einer ACCESS_VIOLATION kommen, weill alle 3 ebuilds allowed_hosts.conf in /etc/vdr/plugins/vnsiserver installieren wollen.
    ich bin ich mir jetzt aber nicht sicher, eventuell kann portage das auflösen und die files werden parallel abgelegt und die versionen per "etc-update" aufgelöst.
    falls das nicht gehen sollte, melden, dann muss noch ein klein wenig mehr im ebuild gefixt werden ;)


    wie es dann letzendlich im realbetrieb aussieht, wenn du mehrere version von dem plugin beim vdr start lädst, muss du mal selber probieren


    und wie immer an dieser stelle: Rückmeldung!


    Cheers :prost2


    /dev/joerg

  • Danke!


    Das vdr-vnsiserver-0.9.3_p20140104.ebuild compiliert und scheint zu funktionieren mit vdr-2.1.3 und XBMC-13 alpha.


    Das mit dem slotting werde ich mir merken, habe jetzt aber nicth die cycles das zu probieren. Wuerde sich aber wohl anbieten, das in die ebuilds einzubauen so dass man zumindestens die richtige vnsiserver version fuer 12.3 und 13 emerged bekommt. Fuer mich allerdings nicht mehr relevant, weil im 12'er nicht mehr der crash gefixt wird den ich habe, also laeuft bei mir jetzt nur der 13 alpha.

  • Hallo,


    bei mir kommt immer folgende Fehlermeldung:
    VNSI: Welcome client 'XBMC Media Center' with protocol version '3'
    VNSI-Error: Client 'XBMC Media Center' have a not allowed protocol version '3', terminating client


    Was habe ich da falsch gemacht?

  • Du nutzt vermutlich XBMC Frodo, statt einer Vorabversion von XBMC Gotham. Das pvr-vdr-addon-vnsi und das vdr-plugin-vnsiserver müssen immer zusammenpassen und mit der PVR-API Version von XBMC kompatibel sein. Für Frodo muss beides aus dem Frodo-Branch gebaut werden: https://github.com/opdenkamp/xbmc-pvr-addons/tree/frodo

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hallo,


    ich habe die aktuelle Beta 13.0 alpha 1 installiert. gleiche Fehlermeldung. Dort ist das gleiche 1.6.4 Plugin wie bei Frodo dabei. Wo bekomme ich ein aktuelleres als zip? Sollte da nicht automatisch ein aktuelles vnsi Plugin dabei sein?


    Edit: ein


    svdrpsend plug


    bringt


    220 vdrserver SVDRP VideoDiskRecorder 2.1.4; Mon Feb 17 12:14:58 2014; UTF-8
    214-Available plugins:
    214-femon v2.0.2 - DVB Signal Informationsanzeige (OSD)
    214-vdrmanager v0.9 - VDR-Manager support plugin
    214-svdrpservice v1.0.0 - SVDRP client
    214-live v0.3.0 - Live Interactive VDR Environment
    214-xineliboutput v2.0.0-cvs - X11/xine-lib output plugin
    214-epgsearch v1.0.0 - Suche im EPG nach Wiederholungen und anderem
    214-svdrposd v1.0.0 - Publish OSD menu via SVDRP
    214-xvdr v0.9.9 - XVDR Server
    214-tvguide v1.2.0 - A fancy 2d EPG Viewer
    214-vnsiserver5 v0.9.3 - VDR-Network-Streaming-Interface (VNSI) Server
    214 End of plugin list

  • Dort ist das gleiche 1.6.4 Plugin wie bei Frodo dabei.


    Dann hat derjenige der das Paket geschnürt hat Mist gebaut (oder du hast das alte Addon nicht auf deinem Benutzer-Ordner rausgeworfen). Die aktuellste Version des pvr-vdr-addon-vnsi ist wie man hier sehen kann die Version 1.9.6: https://github.com/opdenkamp/x…9d72fb3a0475a10f4a862f0b7

    Wo bekomme ich ein aktuelleres als zip?


    Einfach aus den Quellen mit "make zip" bauen...

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Wie bekomme ich auf amd64 ein Plugin für arm gebaut? Muß ich jetzt erst eine Android Entwicklungsumgebung installieren und dann den ARM Code bauen lassen? Oder geht das auch eleganter?


    Achso verwendeVersion 71e5b8c1da7acf726d00bde30da8554662cf97e1


    ist das egal?

  • Wovon reden wir jetzt genau? In dem Thread ging es (ursprünglich) darum Pakete unter Gentoo zu kompilieren...
    Der einfachste Weg ist auf dem ARM-Gerät selbst zu kompilieren (wenn ein brauchbares Linux darauf läuft). Für Android braucht es soweit ich weiß einen Cross-Compiler - allerdings bringt der aktuellste nightly-Build das das Addon auch schon in Version 1.9.6 mit...

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hallo,


    also ich habe unter gentoo den Server per ebuild installiert.Möchte jetzt unter Android das xbmc mit vnsi zum Laufen bringen. Bisher verwendete ich xvdr.
    Habe nun unter Android (Handy und TV-Box) vnsi Plugin 1.9.6 leider paßt wohl der Server unter gentoo nicht dazu.
    Das Einfachste wäre wohl den Server anzupassen (auf die richtige Version).


    Da hängt es.....


    Alternativ würde ich auch gerne weiter xvdr verwenden...nur das habe ich nicht für Android und xbmc gefunden.

  • man oh man, tinitus
    Du machst einen fertig, und das seit jahren
    alles in einen topf werfen und dann den mist hier auskippen, nachdem du den tread gekapert hast....


    Ich kann immer noch nicht ersehen worauf du überhaupt hinaus willst?


    plugin vdr-plugin-vnsiserver ist actuell, laut der sourcen, 0.9.4


    keine Ahung was das da mit der version 1.9.6 sein soll, dabei geht es doch nicht um das plugin?


    was konkret brauchst du denn nun eigentlich?
    nen actuellen snapshot vom vdr-plugin-vnsiserver?



    btw. compile arm auf amd64, da gibts gute howtos bei gentoo, stichwort crosscompiler build umgebung
    fuer android gibts auch die sdk/ndk und bestimmt auch n gutes howto auf gentoo


    aber ich denke mal, da wirst du leicht überfordert sein, wenn du schon an der fehlermeldung weiter oben strauchelst ... ;)

  • keine Ahung was das da mit der version 1.9.6 sein soll, dabei geht es doch nicht um das plugin?

    Nein, um das VNSI-Addon für XBMC. Irgendwie muss man den Anwender ja durch lustiges Kombinieren der Versionsnummern auf Trab halten ;)

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • hd.brummy Vielen Dank für die netten Höflichkeiten


    seahawk1986 Danke für die aufmunternden Worte. ymmd


    Ich möchte nur ein passendes addon zum Server. Deshalb und wegen der verworrenen Versionierung und Protokolländerung folgender Vorschlag:


    Es wäre schön wenn das Ebuild


    1. noch ein make zip ausführt --> Das würde die passenden Module für die aktuelle Plattform bauen
    2. Diese zip Dateien irgendwo ablegt. --> Dann könnte man z.B. auf einem Rechner mit der gleichen Plattform schon mal testen, ob die eigene config funktioniert.


    Der Zuckerguß wäre dann noch:


    wenn man das jeweilige passende gezippte Plugin z.B. für Arm, Android, Atom etc.bauen lassen könnte.


    Denn wer blickt schon genau durch welches vdr Plugin mit welchem Protokoll arbeitet und welches z.B. xbmc Plugin deshalb mit welchem vdr Plugin zusammenarbeitet!?


    Habe das mal im Workdir getestet. Funktioniert eigentlich ganz gut. Nach ein paar Minuten sind die zip Dateien zumindest für amd64 erstellt gewesen.

  • hd.brummy Vielen Dank für die netten Höflichkeiten


    :D :D :D Immer wieder gerne :D :D :D
    Ich hoffe das kannst Du wegstecken, nachdem man sich schon jahrelang kennt ...


    Ich möchte nur ein passendes addon zum Server. Deshalb und wegen der verworrenen Versionierung und Protokolländerung
    folgender Vorschlag:
    Es wäre schön wenn das Ebuild


    Ich habe soebend
    media-plugins/vdr-vnsiserver-0.9.4_p20140213
    media-plugins/xbmc-addon-pvr-0.0.1_p20140213

    ins overlay vdr-devel eingebracht, das plugin zieht jetzt automagisch die passende version vom xbmc-addon-pvr mit rein
    zusätzlich hab ich den beiden ebuilds das arm keyword verpasst


    1. noch ein make zip ausführt --> Das würde die passenden Module für die aktuelle Plattform bauen
    2. Diese zip Dateien irgendwo ablegt. --> Dann könnte man z.B. auf einem Rechner mit der gleichen Plattform schon mal testen, ob die eigene config funktioniert.


    Wo in den sourcen soll denn da ein zip file sein, ich hab nix gefunden...