Rasperry Pi xine plugin


  • Ich bin da kein Profi in dem Bereich, aber wenn Xine unter GPL und nicht unter LGPL steht, dann ist mein Verständnis der Lizenz, dass Sourcecode, der auf libxine basiert, sogar ganz automatisch wieder unter GPL steht.



    Hier scheiden sich mal wieder die Geister. Ich sehe das anders.
    Es werden weder Änderungen an den xine-Sourcen gemacht noch basiert das Plugin auf libxine, fbxine o.ä.
    xineplug-rpi ist ein "Plugin" welches von der xine-lib benutzen wird und nicht umgekehrt.


    Mag sein, dass ich da falsch liege. Ich möchte das Thema hiermit beenden (nicht der richtige Thread dafür).
    Ich bin halt kein netter Mensch. Also: keine Sourcen!


    ardi

    :welle ASRock K10N78FullHD-hSLI R3.0, Atlon64 X2 4850e (45W), 2GB RAM,500GB SATA, SkyStar2+TT-S21600, yaVDR

  • jo als plugin musst du die sourcen nicht veröffentlichen da es nur Schnittstellen benutzt

  • Auch wenn man die Schnittstellen benutzt gilt das prinzipiell als "abgewandeltes Werk". Um sowas zu erlauben wurde die LGPL geschaffen. Und die Entwickler von Xine haben sich dafür entschieden ihre Library nicht unter diese liberalere Lizenz zu stellen.


    Muss aber jeder selber wissen. Einerseits davon profitieren das andere den Sourcecode offenlegen, aus unerfindlichen Gründen aber selber seinen Source für sich behalten wollen ist (Zitat) in der Tat nicht nett. Würde jeder so denken hätten wir weder VDR noch Xine noch Linux an sich.


    Sei's drum. Ich bin froh das mal angesprochen zu haben. Das Thema ist für mich durch.

  • Quote

    Das Thema ist für mich durch.


    Wohl leider auch für sonstige Raspberry-Pi Distributionen, die man eventuell selber kompiliert und deshalb das Binary mit der vorhandenen Xinelib Version und libc nicht nutzbar ist. Feine Sache das.


    Sent from my Nexus 4 using Tapatalk 2


    8)


    Gentoo overlay mit VDR (und nicht nur) ebuilds, vdrcm, GLCDprocDriver

  • Hi,


    Quote

    Wohl leider auch für sonstige Raspberry-Pi Distributionen, die man eventuell selber kompiliert und deshalb das Binary mit der vorhandenen Xinelib Version und libc nicht nutzbar ist.

    schade sah sehr gut aus.
    Ich denke auch das die Arbeit sich schlecht auf andere Raspberry-Pi Distributionen ohne Quellen übertragen lässt.


    Oder geht Deine Hilfe soweit immer mit Hand anzulegen -- wie soll das laufen?


    Quote

    Ich für meinen Teil habe noch Hoffnung, dass ich ardi nur falsch verstanden habe und wenn er den Code dann herausgibt, wenn er soweit ins Reine geschrieben ist, ist ja letztlich auch besser als nichts. Ich wollte ja lediglich wissen wann er meint das er den Sourcecode veröffentlichen kann.

    Vielleicht ein letztes klaren Wort zu dieser Annahme, wäre schön. :rolleyes:


    Grüße
    cinfo

    (VDR) NUC11PAHi5 * BM2LTS * DD NET S2 Max * NC * (Sound) Cinebar Lux Set * (Stream) Apple TV 4K (2021)* (Light) PHILIPS Hue Play HDMI Sync Box & Gradient Lightstrip * (OLED TV) LG OLED65GX9LA

  • Um das Thema jetzt zu beenden.


    Es werden irgend wann mal die Source geben. Jetzt ist e aber so, dass ich selbst keine hab.
    Das was ich hab ist eine Ansammlung wilder Funktionen voll mit Log-prints.
    Wenn das ganze annährend nach Source-Code aussieht und das Plug-in halbwegs stabil läuft, dann wird's die auch geben.


    Also: Schluss jetzt !!!--- das gehört nicht hier her.
    ardi

    :welle ASRock K10N78FullHD-hSLI R3.0, Atlon64 X2 4850e (45W), 2GB RAM,500GB SATA, SkyStar2+TT-S21600, yaVDR

  • Hi ardi,


    nach der ganzen GPL Diskusion ist glaube ich meine Frage aus meinen vorletzten Post komplett untergegangen.Also stelle ich meine Frage nochmal.Kannst du mir bitte sagen wie ich dein Plugin in die runvdr eintragen muß?
    Für das mcli-plugin ist z.B. der Eintrag -P'mcli --ifname eth0 --sock-path /tmp/mcli.sock --mld-reporter-diable --dvb-s2 1' . So ähnlich wird auch xineliboutput aufgerufen aber das funktioniert so nicht.


    mfg guigra

  • So ähnlich wird auch xineliboutput aufgerufen aber das funktioniert so nicht.


    Zeig doch mal wie dein Aufruf aussieht - das müsste ja sowas in der Art sein:

    Code
    1. -P "xineliboutput -V rpi -A alsa --local=fbfe -f --primary"

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hi seahwk1986,


    danke für deine schnelle Antwort.Mein Pluginaufruf sieht so aus -P'xineliboutput --local=fbfe --video=rpi --display=:0 --primary --audio=alsa:hw:0,3 -f' also ähnlich wie für die runvdr auf meinem PC.
    Trage ich das in die runvdr ein hängt sie mein rpi auf.Ich starte übrigens den VDR von der Console und nicht von der bunten Oberfläche.Rpi ist nicht übertaktet und das Memspliting ist 256MB für System und 256MB für die GPU.Die Bild und Tonausgabe läuft über HDMI.


    mfg guigra

  • Klappt es denn, wenn du vdr-fbfe separat vom VDR startest?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hi seahawk1986,


    ein Start von vdr-fbfe funktioniert nicht auch hier hängt sich der Rpi auf.Ich habe mal versucht den vdr von der Konsole mit folgenden Angaben zu starten :


    pi@raspberrypi ~ $ vdr-fbfe -V rpi -A alsa -P'mcli --ifname eth0 --sock-path /tmp/mcli.sock --mld-reporter-disable --dvb-s2 1' mit den selben Folgen - Rpi hat sich aufgehangen.Da half auch kein AltStrgEntf.


    Das dusslige daran ist im syslog zeigt er nichts an warum er sich erhängt.Das mcliplugin habe ich in einer anderen Installation(VDR 1.7.31 als Streamingserver) getestet und es läuft super.Ich bekomme auch
    kein ODS zu sehen.


    mfg guigra

  • Zu dem mcli-Plugin kann ich nichts sagen, bei mir hängt der VDR mit xineliboutput für den Raspberry über Streamdev an einem anderen VDR mit DVB-Karten. Könnte die Netzwerklast für den Raspberry zu hoch werden?


    Code
    1. vdr-fbfe -V rpi -A alsa -P'mcli --ifname eth0 --sock-path /tmp/mcli.sock --mld-reporter-disable --dvb-s2 1


    Das verstehe ich nicht ganz - das Frontend kann mit dem mcli-Plugin ja nichts anfangen, ich meinte das eher so:


    Code
    1. vdr -P "xineliboutput --local=none --remote=:37890" -P"mcli --ifname eth0 --sock-path /tmp/mcli.sock --mld-reporter-disable --dvb-s2 1"


    Und dann davon unabhängig auf einer zweiten Konsole:

    Code
    1. vdr-fbfe -V rpi -A alsa -f

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hi guigra,


    bist Du sicher das Deine Stromversorgung nicht zu schwach ist. Für mich klingt das nach nem typischen "zu schwaches Netzteil" Problem.


    Claus

    MLD 5.4 mit vdr 2.4.1 - lirc yaUSBir - Octopus NET S2 - SCR - XFX GeForce 9300 mit Intel E3200 - 2GB RAM - WD Green 12TB HDD - SanDisk 64GB SSD - Lian Li PC-C37B - Samsung LE40A559
    MLD 5.4 mit vdr 2.4 - Raspberry Pi 3 - rpihddevice
    MLD 5.4 mit Squeeze Play - Raspberry Pi 2 - 32GB SD - 7" Touch TFT

  • Hi vdr_rossi,


    ich hab das nun selber mal getestet. Nachdem ich den vdr-sxfe Aufruf für den RPI angepasst habe, bekomme ich leider diese Fehlermeldung:


    Das klingt für mich danach, dass das xine rpi Plugin (für xine 1.30 ?) leider nicht zu meiner selbst Kompilierten xine Version 2.2 kompatibel ist. Damit dürfte die MLD leider vorerst außen vor sein.


    ardi ,


    oder siehst Du das anders? Mit strace konnte ich keine Auffälligkeiten ausmachen.


    Claus

    MLD 5.4 mit vdr 2.4.1 - lirc yaUSBir - Octopus NET S2 - SCR - XFX GeForce 9300 mit Intel E3200 - 2GB RAM - WD Green 12TB HDD - SanDisk 64GB SSD - Lian Li PC-C37B - Samsung LE40A559
    MLD 5.4 mit vdr 2.4 - Raspberry Pi 3 - rpihddevice
    MLD 5.4 mit Squeeze Play - Raspberry Pi 2 - 32GB SD - 7" Touch TFT

    The post was edited 1 time, last by clausmuus ().

  • Mit welcher libc Version baust du die MLD? Was nutzt du als Quelle für xineliboutput? Klappt es mit fbxine selbst?
    Ich habe hier die glibc 2.17

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hi seahawk1986,


    habe deinen Vorschlag ausprobiert und bekomme folgene Meldungen :


    Konsole 1 : Eingabe : pi@raspberrypi~$ vdr -P'mcli --ifname eth0 --sock-path /tmp/mcli.sock --mld-reporter-disable --dvb-s2 1' -P'xineliboutput --locale=none --remote=:37890'
    Ausgabe: pi@raspberrypi~$ vdr: /usr/local/src/lib/vdr/libvdr-xineliboutput.so.1.7.31: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden
    Delete my Dev list


    Konsole 2 : Eingabe : pi@raspberrypi ~ $ vdr-fbfe -V rpi -A alsa -f
    Ausgabe: vdr-fbfe 1.0.90-cvs (build with xine-lib 1.2.2, using xine-lib 1.2.2)


    Video driver: rpi
    Audio driver: alsa
    Fullscreen mode


    VDR server not given, searching ...
    ---------------------------------------------------------------
    WARNING: MRL not given and server not found from local network.
    Trying to connect to default port on local host.
    ---------------------------------------------------------------
    [2527] [vdr-fbfe] fbfe_display_open: failed to set /dev/tty to graphics mode
    [2527] [vdr-fbfe] (ERROR (xine_fbfe_frontend.c,178): Invalid argument)
    [2527] [input_vdr] Connecting (control) to tcp://127.0.0.1:37890 ...
    [2527] [input_vdr] Can't connect to tcp://127.0.0.1:37890
    [2527] [input_vdr] (ERROR (xine_input_vdr.c,5353): Operation now in progress)
    [2527] [input_vdr] Can't connect to tcp://127.0.0.1:37890
    [2527] [input_vdr] (ERROR (xine_input_vdr.c,5780): Operation now in progress)
    [2527] [input_vdr] Connections closed.
    [2527] [vdr-fe] fe_xine_open: xine_open("xvdr://127.0.0.1#nocache") failed
    Error opening xvdr://127.0.0.1
    [2527] [vdr-fbfe] fbfe_display_close: failed to set /dev/tty to text mode
    [2527] [vdr-fbfe] (ERROR (xine_fbfe_frontend.c,253): Invalid argument)
    pi@raspberrypi ~ $


    Ausgabe der Konsole 1 ist klar, weil es diese Datei so nicht gibt.


    clausmuus


    Daran hatte ich auch erst gedacht aber 5V und 3A sollten doch reichen. Eine Überprüfung der Versorgungsspannung mit einem Osziloskop brachte auch keine Ergebnisse da ist auch per Langzeitmonitoring keine Spannungseinbruche zufinden sondern immer eine saubere Betriebsspannung. Ich habe ja zum TV sehen das Image von cinfo und das rennt stabil und der Rpi zeigt auch nach 8h Dauerlauf keine Probleme.


    cinfo


    Danke für das Update läuft sehr gut.


    mfg guigra


  • Dann fehlt dir aber das passende xineliboutput Plugin, ohne das kann es ja nicht gehen.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hi seahawk1986,


    guter Hinweis. Ich hatte mein RPI Entwicklungssystem schon länger nicht aktualisiert und bin noch auf glibc-2.13. Das kann natürlich nicht passen. Nun mache ich also erst mal nen Update. Frühstens Morgen Abend gibt's dann nen neues Image. Ich bin grad nicht sicher ob nen kompletter Build ein oder zwei Tage brauchte...


    Claus

    MLD 5.4 mit vdr 2.4.1 - lirc yaUSBir - Octopus NET S2 - SCR - XFX GeForce 9300 mit Intel E3200 - 2GB RAM - WD Green 12TB HDD - SanDisk 64GB SSD - Lian Li PC-C37B - Samsung LE40A559
    MLD 5.4 mit vdr 2.4 - Raspberry Pi 3 - rpihddevice
    MLD 5.4 mit Squeeze Play - Raspberry Pi 2 - 32GB SD - 7" Touch TFT

  • Hi seahawk1986,


    ich werde mein Linux auf Startkonfiguration (Grundinstallationsimage) zurücksetzen und nochmal von vorne und der Reihe nach den VDR aufsetzen.
    Vielen Dank für deine Mühe und Geduld mit mir.


    mfg guigra :]

  • Ich bin grad nicht sicher ob nen kompletter Build ein oder zwei Tage brauchte...


    Hast du dir schon mal distcc angesehen? Ich nutze das unter Arch Linux für den Raspberry Pi - die Idee ist, dass man über andere Rechner im Netzwerk beim Kompilieren mitmachen lassen kann. Für Raspbian gibt es eine Anleitung: http://pastebin.com/raw.php?i=YrtntGtU
    Wichtig ist nur, dass die Header-Dateien und Versionsstände der Bibliotheken auf den Build-Rechnern zueinander passen.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)