[Announce] VDR developer version 1.7.35

  • aus der ML

    Vielen Dank für die neue Version!

    Hardware: Zalman HD160XT; Asus H97M-Plus, 1024MB RAM, Digital Devices Cine S2 (rev 7), Atric-Einschalter, NEC3520 DVD-Laufwerk, Samsung 256 GB SSD-Festplatte --> darauf yaVDR 0.6
    Hifi: Denon AVR4306, Samsung UE40ES6300

  • danke für die 1.7.35 kls !


    ich möchte diesen thread ja nicht "versauen" - seit 1.7.34 ist's (für mich zumindest) recht hart am letzten dev-stand zu bleiben (Make... etc):


    ich bekomm mit plain-vdr und anpassung des DVBDIR (nutze mittlerweile UFOs letzten treiberstand --> "DVBDIR = /opt/src/dvb/current/media_build_experimental/linux/include/uapi") diese meldungen beim übersetzen des vdr:


    das vdr-binary wird aber erstellt.


    weiters:

    Code
    1. *** failed plugins: dvbhddevice dvbsddevice

    mit diesen meldungen:


    sorry for the inconvenience ;)


    ciax

  • zu 1.
    Liegt daran, daß DVBDIR bei Bauen der Dependencies nicht verwendet wird. Kleiner Bug im Makefile.


    zu 2.
    CFLAGS erweitern:

    Code
    1. CFLAGS += -D__user= -D__u8=uint8_t


    CU
    Oliver

  • Liegt daran, daß DVBDIR bei Bauen der Dependencies nicht verwendet wird. Kleiner Bug im Makefile.


    CU
    Oliver

    hmm - sorry Oliver, ich will nicht nerven - hab ich da im 1.7.34er thread wieder was überlesen? ich ging halt (als einfacher anwender mit ambitionen zum selbstkompilieren) davon aus, daß die 1.7.35er das ausgemerzt hat ... ?(


    gruß, ciax


    ps:


    ** dein "edit" nicht gesehen


    ad 1) also ein "bug" aber es gibt dafür eine lösung im 1.7.34er thread .. ?
    ad 2) mach ich gleich :)

  • Also bei mir läuft die 1.7.35 (plain) incl. der Plugins von gestern ( Neu / Alt Makefileerkennung) ohne Probleme durch.

    VDR 1 (SD) : ASRock A330 GC, 1 GB RAM, TT- FF Karte rev. 2.3, 7'' TFT, Lirc X10 - Selbstbau Gehäuse - Suse 11.3 (64) vdr-1.7.10 diverse Plugins
    VDR 2 (HD) : MSI G41M-P25, 2 GB RAM, E6700 2x3.20GHz, Gainward GT220, 2TB HD, Lirc X10, TT S2-3600 USB, TT S2-1600, - Suse 11.3 (64) NvidiaTreiber 260.19 vdr-1.7.18 - xineliboutplugin 1.0.90 cvs, xine-lib 1.1.90 , s2-liplianin DVB Treiber

  • Also bei mir läuft die 1.7.35 (plain) incl. der Plugins von gestern ( Neu / Alt Makefileerkennung) ohne Probleme durch.

    hi rudi/rabbit,


    das ist schön (für dich), ich hab aber "problem 1" trotzdem "hier" ... 8)


    gruß, ciax

  • das ist schön (für dich), ich hab aber "problem 1" trotzdem "hier

    Sollte nur ein Hinweiß sein, das es nicht auf jedem System auftritt

    VDR 1 (SD) : ASRock A330 GC, 1 GB RAM, TT- FF Karte rev. 2.3, 7'' TFT, Lirc X10 - Selbstbau Gehäuse - Suse 11.3 (64) vdr-1.7.10 diverse Plugins
    VDR 2 (HD) : MSI G41M-P25, 2 GB RAM, E6700 2x3.20GHz, Gainward GT220, 2TB HD, Lirc X10, TT S2-3600 USB, TT S2-1600, - Suse 11.3 (64) NvidiaTreiber 260.19 vdr-1.7.18 - xineliboutplugin 1.0.90 cvs, xine-lib 1.1.90 , s2-liplianin DVB Treiber

  • Auf die Gefahr hin, dass ich gleich wieder angeranzt werde, fasse ich mal zusammen was meiner Meinung nach nicht passt.



    Das Einführen von UP3 im Makefile und das damit verbundene umsetzen des Includedirs von absolut auf relativ führt bei mir zu Problemen.


    --> UP3 soll wieder verschwinden und CWD soll wieder absolut werden.


    makepkg von Archlinux exportiert CFLAGS und CXXFLAGS. Das kann ich nicht so einfach steuern. Lässt sich wie folgt reproduzieren.


    Code
    1. export CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2"
    2. export CXXFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2"
    3. make plugins


    --> In 1.7.34 war im Makefile noch ein "CXXFLAGS+= -fPIC" Wenn das wieder da wäre wäre diese Problem auch weg.


  • Das Einführen von UP3 im Makefile und das damit verbundene umsetzen des Includedirs von absolut auf relativ führt bei mir zu Problemen.


    --> UP3 soll wieder verschwinden und CWD soll wieder absolut werden.


    +1


    Das macht hier auch Probleme, wie im "1.7.34"-Thread von mir bereites ausführlicher dargelegt.


  • ad 1) also ein "bug" aber es gibt dafür eine lösung im 1.7.34er thread .. ?


    Nicht daß ich wüßte. Ich habe "quick and dirty" im VDR Makefile die MAKEDEP-Zeile auf

    Code
    1. MAKEDEP = $(CXX) -MM -MG -I$(DVBDIR)


    geändert. Ist sicher nicht die endgültige Lösung, aber dieses Makefile ist mir mittlerweile "way too complex".


    CU
    Oliver

  • +1


    Das macht hier auch Probleme, wie im "1.7.34"-Thread von mir bereites ausführlicher dargelegt.


    Es ist schlicht falsch, an ein Plugin relative Pfade zu übergeben, denn damit setzt man eine bestimmte Directory-Struktur voraus.
    Ich dachte, die PKGCFG-Änderung hätte das Ziel, Plugins auch out-of-tree übersetzen zu können. Das kann so nicht funktionieren.


    CU
    Oliver

  • Bei mir läuft auf vdr2 1.7.35 mit den wichtigsten plugins :-)



    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Nicht daß ich wüßte. Ich habe "quick and dirty" im VDR Makefile die MAKEDEP-Zeile auf

    Code
    1. MAKEDEP = $(CXX) -MM -MG -I$(DVBDIR)


    geändert. Ist sicher nicht die endgültige Lösung, aber dieses Makefile ist mir mittlerweile "way too complex".


    CU
    Oliver


    danke Oliver! jetzt sieht auch der "1." punkt - also alles beim compilieren - wieder sauber aus! :]


    eine kleine OT frage. ich hab die X-mas edition der treiber von dir nur als sourcen am system. im einsatz sind deine treiber aus "mitte des jahres". das ist sicher ein problem "beim betrieb" von vdr (ich meine mich daran zu erinern, daß "ihr" das aber auch so macht) ??


    gruß, ciax

  • Hi,


    bei mir läuft der VDR nicht durch:




    Übesetzt habe ich mit:


  • Hi,
    Übesetzt habe ich mit:



    Scheint mir als würde "PREFIX" nirgends gesetzt.

  • Hi,


    hier mal das gesammte Makefile:


  • In der Vergangenheit konnte ich per make / make plugins alles im vdr-source Verzeichnis erstellen. Per make install sind dann die verschiedenen Sachen unter /usr/sbin, /usr/lib64/vdr, ... gelandet. Ich habe das in Make.config definieren können. Wie erreiche ich das mit dem neuen Makefiles? Irgendwie gibt es zwischen Bauen und Installieren keine Trennung mehr.


    Gruß
    e9hack

  • In der Vergangenheit konnte ich per make / make plugins alles im vdr-source Verzeichnis erstellen. Per make install sind dann die verschiedenen Sachen unter /usr/sbin, /usr/lib64/vdr, ... gelandet. Ich habe das in Make.config definieren können. Wie erreiche ich das mit dem neuen Makefiles?


    Genauso.


    Irgendwie gibt es zwischen Bauen und Installieren keine Trennung mehr.


    Doch, ein "make all" baut und ein "make install" instaliert.


    Der Unterschied ist das ein "make install" jetzt auch die Sachen instaliert die die Plugins benötigen (d.h. du musst die Default Pluginconfig (und was die plugins sonst noch so im Dateisystem benötigen) nicht mehr manuell kopieren).


    cu


  • eine kleine OT frage. ich hab die X-mas edition der treiber von dir nur als sourcen am system. im einsatz sind deine treiber aus "mitte des jahres". das ist sicher ein problem "beim betrieb" von vdr (ich meine mich daran zu erinern, daß "ihr" das aber auch so macht) ??


    Nein, so mache ich das nicht. Ich lade den Treiber, gegen den vdr kompiliert ist.
    (Allerdings ist es meist unkritisch, da sich an der Schnittstelle zum Treiber nur selten etwas ändert.)


    CU
    Oliver