Reel eHD: VDR mit TS & "Reel" Plugins

  • Hi,


    ivh würde sagen, leid kann VDPAU nur mitspielen wenn auch das reelbox Plugin mit schleppt wird.


    Es werden beide Plugins benötigt - aber wie man dann die Ausgabe vom reelbox Plugin auf VDPAU umleitet???


    Grüße
    cinfo

    (VDR) NUC11PAH & GEEKOM MINI-IT11-11. Generation * BM2LTS * DD NET S2 Max * NC * (Sound) Cinebar Lux Set * (Stream) Apple TV 4K (2022) *

    (Light) PHILIPS Hue Play HDMI Sync Box & Gradient Lightstrip * (OLED TV) LG OLED65G29LA

  • Hi,


    aber der Skinreel macht schon sehr viel Fun.


    Hier noch eine Anwendung - frisch von Reel_Quick


    LastFM 2.6 mit dem Skinreel.


    Beste Dank an Reel_Quick der die Sourcen hierfür bereitgestellt hat.



    Download:
    http://www.mediafire.com/?jt01o27p8bom11s


    Grüße
    cinfo

  • Habe noch nen VDR 1.7.0 mit eHD im meiner S100 am werkeln?
    Da der Server jetzt auf 1.7.15 upgedated wurde, muss die S100 jetzt aber nachziehen. Mir graust schon etwas vor dem Zusammensuchen der ganzen Patches für reelbox, skinreel und dem ganzen Xine Krams zum Abspielen von DVDs (war damals mit dem 1.7.0 schon ein Akt, bis es lief).


    Hat irgend ein Held vielleicht Zeit und Lust, mal kurz zusammenzufassen, welche Patches für den VDR 1.7.15 mit eHD aktuell notwendig sind? Meine Dankbarkeit sei Dir sicher. ;)


    gcc 4.4 ist bei mir kein Problem, da ich der S100 kein neues System verpassen möchte. Derzeit habe ich noch den Extension Patch drauf, der IMHO auch für den 1.7.15 existiert. Ich denke, ich könnte aber darauf verzichten, wenn der sich mit den reel Patches beißt.


    Grüße Pete

  • Hi,


    für die "normalen" Reel Plugins z.B. dvdswitch, skinreel etc... kannst Du die Quellen vom VDR-1.7.0 nehmen.


    Wenn Dein VDR-1.7.15 saubegepatcht ist - dann benutze aus dem Anhang die Patches für den xinemediaplayer und diese reelbox Plugin Version


    reelbox Plugin für den VDR-1.7.15
    http://www.mediafire.com/?twpjcwivwa6c168


    viel Erfolg
    cinfo

  • Hi,


    hier ein Patch für den Fehler
    "Wenn XML-Tags manchmal in der Anzeige durchschlagen."



    Grüße
    cinfo

    (VDR) NUC11PAH & GEEKOM MINI-IT11-11. Generation * BM2LTS * DD NET S2 Max * NC * (Sound) Cinebar Lux Set * (Stream) Apple TV 4K (2022) *

    (Light) PHILIPS Hue Play HDMI Sync Box & Gradient Lightstrip * (OLED TV) LG OLED65G29LA

    2 Mal editiert, zuletzt von cinfo ()

  • Hi,


    hier der aktuelle Patch für das LastFm Plugin mit Skinreelunterstützung.


    Änderungen:

    Zitat

    Das rechtsbündige Ausrichten von Datum/Uhrzeit hatte ich auf dem NetClient getestet. Ob der Hinweistext kommt, wenn keine Künstlerinfos konnte ich nicht mehr testen. Müsste aber funktionieren.


    Patch Build 575


    Grüße
    cinfo

    (VDR) NUC11PAH & GEEKOM MINI-IT11-11. Generation * BM2LTS * DD NET S2 Max * NC * (Sound) Cinebar Lux Set * (Stream) Apple TV 4K (2022) *

    (Light) PHILIPS Hue Play HDMI Sync Box & Gradient Lightstrip * (OLED TV) LG OLED65G29LA

    2 Mal editiert, zuletzt von cinfo ()

  • Hi,


    hier eine Änderung im Patch Build 575 --> in der web_serviceconnector_webservices.c wird der Wert auf return 0 geändert.



    Grüße
    cinfo

    (VDR) NUC11PAH & GEEKOM MINI-IT11-11. Generation * BM2LTS * DD NET S2 Max * NC * (Sound) Cinebar Lux Set * (Stream) Apple TV 4K (2022) *

    (Light) PHILIPS Hue Play HDMI Sync Box & Gradient Lightstrip * (OLED TV) LG OLED65G29LA



  • Grüße
    cinfo

    (VDR) NUC11PAH & GEEKOM MINI-IT11-11. Generation * BM2LTS * DD NET S2 Max * NC * (Sound) Cinebar Lux Set * (Stream) Apple TV 4K (2022) *

    (Light) PHILIPS Hue Play HDMI Sync Box & Gradient Lightstrip * (OLED TV) LG OLED65G29LA

    2 Mal editiert, zuletzt von cinfo ()

  • hi,


    das ist mit gestrigen datum nicht mehr aktuell
    es gibt jetzt eine neue linux.bin mit includiertem hdplayer so das der tft mit uplaod des hdplayers entfällt
    (habe ich gestern auch getestet)


    http://www.onlinelaufwerk.de/reel/svn_log.html


    r15202 | rollercoaster | 2010-10-07 14:05:39 +0200 (Thu, 07 Oct 2010) | 2 lines
    - new decypher image with hdplayer now included


    je nach dem ob weiterhin versucht wird den hdplayer nachzuladen könnte es passieren das man eine ältere version nachläd als die in linux.bin, da habe ich im moment zu wenig infos
    zur sicherheit sollte man den hdplayer im tftp verzeichnis umbenennen oder den tft dienst abschalten

  • Hi,


    Zitat

    es gibt jetzt eine neue linux.bin mit includiertem hdplayer so das der tft mit uplaod des hdplayers entfällt
    (habe ich gestern auch getestet)


    das ist verwirrend da, beim laden des hdplayer auch der 07.10.2010 angezeigt wird und beide Dateien vom 07.10.2010 sind.


    Soll denn jetzt nur noch die linux.bin geladen werden?


    Grüße
    cinfo

    (VDR) NUC11PAH & GEEKOM MINI-IT11-11. Generation * BM2LTS * DD NET S2 Max * NC * (Sound) Cinebar Lux Set * (Stream) Apple TV 4K (2022) *

    (Light) PHILIPS Hue Play HDMI Sync Box & Gradient Lightstrip * (OLED TV) LG OLED65G29LA

  • Hi,


    Zitat

    Soll denn jetzt nur noch die linux.bin geladen werden?


    OK getestet, es wird nur noch die linux.bin benötigt


    Zitat


    Grüße
    cinfo

    (VDR) NUC11PAH & GEEKOM MINI-IT11-11. Generation * BM2LTS * DD NET S2 Max * NC * (Sound) Cinebar Lux Set * (Stream) Apple TV 4K (2022) *

    (Light) PHILIPS Hue Play HDMI Sync Box & Gradient Lightstrip * (OLED TV) LG OLED65G29LA

    Einmal editiert, zuletzt von cinfo ()

  • ja, im alten fall läd die linux.bin und via tftp wurde vom linux auf der karte der hdplayer nachgeladen
    war doch schon immer ungewöhnlich das man den hdplayer so umständlich nachladen musste, so was macht man bei der entwicklung wenn ständig neue versionen testet aber darüber ist die eHD ja eigentlich hinweg, zumindet ist nicht zu erwarten das rmm neue codecs auf der eHD implementiert und so groß ist der aufwand auch nicht wenn man 2 oder 3 x im jahr eine neue linux.bin compilieren muss weil man was am hdplayer änder und vermutlich kann man ja auch manuell veranlassen das ein neuerer hdplayer nachgeladen wird
    ist ein hindernis weniger beim in betrieb nehmen und eine fehlerquelle weniger (falls man mal versehentlich verschiedene linux.bin und hdplayer mixt die nicht passen)

  • Neue linux.bin eben mal ausprobiert:


    In dasselbe Verzeichnis geladen, wo die alte lag, alte entsprechend umbenannt.
    hdplayer im tftboot Verzeichnis umbenannt, damit der nicht mehr nachgeladen werden kann.


    Ergebnis: VDR Start hängt beim Initalisieren des Reelbox plugins.


    Dann im Syslog
    vdr: ERROR: Can't get HDE control area (hdctrld not running on HDE?). Using dummy.


    und der VDR rebooted endlos. :(



    Habe in meinen Bootscripten einen Test auf funktionierende eHD vor Start des VDR mittels:


    nc -w 5 192.168.99.129 23


    und da bekomme ich jetzt mit der neuen linux.bin


    (UNKNOWN) [192.168.99.129] 23 (telnet) : Connection timed out


    Entweder nutzt die eHD jetzt eine andere IP, oder bootet mit der neuen linux.bin nicht gescheit.



    Jemand ne Idee?

  • Nachdem das Reelbox plugin schon geraume Zeit mit meinen vdr 1.7.15 funktioniert, wollte ich mich jetzt dran machen und den skinreel wieder zum Laufen zu kriegen.


    Ergo aktuelles skinreel svn ausgecheckt.


    Make bricht ab mit:



    Suche im Forum brachte mich nicht wirklich weiter.


    Hat jemand ne Idee, woran es liegen könnte?


    Pete

  • Hi,


    zum Skinreel & reelboox Plugin steht weiter oben die Lösung zur Anpassung
    der Plugins skinreel & reelbox Plugin mit der Änderung am VDR 1.7.15


    Dann sollte auch die neue Linux.bin ohne Fehler bei Dir laufen.


    Grüße
    cinfo

    (VDR) NUC11PAH & GEEKOM MINI-IT11-11. Generation * BM2LTS * DD NET S2 Max * NC * (Sound) Cinebar Lux Set * (Stream) Apple TV 4K (2022) *

    (Light) PHILIPS Hue Play HDMI Sync Box & Gradient Lightstrip * (OLED TV) LG OLED65G29LA

    Einmal editiert, zuletzt von cinfo ()

  • hi,


    wenn du eine akuelle version des reelbox plugin benutzt muss du das framebuffer device der ehd angeben


    -P'reelbox --fbdev /dev/fb1'


    ansonsten wüße ich auf anhieb nicht warum die linux.bin mit integriertem hdplayer nicht gehen sollte (du hast die linux.bin selbst frisch ausgecheckt?)


  • Problem gefunden. Ich hatte die linux.bin mit folgendem Befehl geladen:


    hdboot -e 0x802ad000 -i linux.bin


    Das gibt wohl die Speicheradresse vor wohin das System geschrieben werden soll und das passt wohl nicht für die neue.


    mit


    hdboot -i linux.bin


    klappt es. :)


    Hier mal mein Start-eHD Skript:



    Ist da was bei, was ich mit dem neuen linux.bin jetzt nicht mehr brauche?


    Pete

  • > Das gibt wohl die Speicheradresse vor wohin das System geschrieben werden soll
    > und das passt wohl nicht für die neue.


    Das -e ist der Kerneleinsprungpunkt und war in den Urzeiten des linux.bin erforderlich. Seit sicher fast zwei Jahren ist die Info im linux.bin selbst drin und wird vom hdboot ausgewertet.


    > Ist da was bei, was ich mit dem neuen linux.bin jetzt nicht mehr brauche?


    Rein theoretisch der shmnetd, weil der hdplayer nicht mehr über tftp kommen muss. Aber das Starten vom shnetd kostet weder Zeit noch sonst was, und ein telnet-Zugang ist immer gut...


    Ansonsten finde ich die while-Schleife etwas seltsam. Entweder ist nach dem insmod das hdshm geladen oder nicht. Der hdboot ist dafür nicht notwendig. D.h. eigentlich könnte man die while-Schleife ganz weglassen.

  • Zitat

    Original von real_schorsch
    > Das gibt wohl die Speicheradresse vor wohin das System geschrieben werden soll
    > und das passt wohl nicht für die neue.


    Das -e ist der Kerneleinsprungpunkt und war in den Urzeiten des linux.bin erforderlich. Seit sicher fast zwei Jahren ist die Info im linux.bin selbst drin und wird vom hdboot ausgewertet.


    So alt ist wahrscheinlich meine erste eHD Installation, oder zumindest die erster Anleitung, die ich damals benutzt hatte. ;)


    Zitat

    > Ist da was bei, was ich mit dem neuen linux.bin jetzt nicht mehr brauche?


    Rein theoretisch der shmnetd, weil der hdplayer nicht mehr über tftp kommen muss. Aber das Starten vom shnetd kostet weder Zeit noch sonst was, und ein telnet-Zugang ist immer gut...


    Ansonsten finde ich die while-Schleife etwas seltsam. Entweder ist nach dem insmod das hdshm geladen oder nicht. Der hdboot ist dafür nicht notwendig. D.h. eigentlich könnte man die while-Schleife ganz weglassen.


    Schleife stammt auch aus der alten ich-weiß-nicht-mehr-woher Anleitung. Ich schmeisse beides mal raus. Cleaner ist besser.


    Merci


    Pete

  • Zitat

    Original von cinfo
    zum Skinreel & reelboox Plugin steht weiter oben die Lösung zur Anpassung
    der Plugins skinreel & reelbox Plugin mit der Änderung am VDR 1.7.15


    Ich probiere mal mein Glück mit einem vanilla vdr 1.7.15 und nur dem reelbox und skinreel plugin. Wenn ich es damit zu Laufen kriege mache ich weiter.


    Noch ein paar Basics zur Sicherheit:


    Deine o.g. Änderungen sind durchzuführen, nachdem z.B. der reelbox-svn14835-v4-vdr.diff patch von derdag aus dem Parallelthread angewendet wurde? D.h. ohne Reelbox Patch geht nach wie vor nix mit einem vanilla VDR?


    Im Makefile vom reelbox plugin muss REELSKIN=1 gesetzt sein?


    Für den svn14835-v4-vdr.diff müssen noch utils/bspshm und utils/hdshm3/src in das reelbox plugin Verzeichnis verlinkt werden?


    Brauche ich eigentlich noch die Make.common und die Make.global im VDR Sourceverzeichnis? Der svn14835-v4-vdr.diff entfernt gerade das include $(VDRDIR)/Make.common aus dem Makefile.


    und dann make, make plugins und Daumen drücken ...


    Pete

Jetzt mitmachen!

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