[Announce] VDR developer version 1.7.35

    grappi


    Gestern Tatort zeitversetzt lief einwandfrei
    - VDR Client aus der SIG mit SOftHDDevice (kein XBMC)


    Ist zwar 1.7.34, aber ich glaube vom eigentlichen VDR Code ist da kein Unterschied zu 1.7.35

    Server PC leap42.3 ::: vdr-2.3.8 ::: DD Cine C2 + 1 Erweiterung headless

    zbox leap42.3 ::: vdr-2.3.8 + SatIP Plugin

    OctopusNet DVBC mit 4 Tunern

    Clients 2 x Raspberry 2 + libreElec 8.2.1 verbunden mit zbox

    Ich weiß nicht ob das offiziell als Problem definiert ist...
    Aber bei Plugins die mehere Plugins bauen oder Subplugins nutzen sehe ich Probleme. Hast du das mal mit epgsearch und LCLBLD=1 getestet?


    Wobei die meisten Plugins bei dieser Art von build (LCLBLD=1) eh nicht funktionieren (weil sie mehr als lib und mo brauchen) und der VDR dann eh nicht startet. Daher die Frage ob das jetzt überhaut nen Problem ist oder nicht?


    cu

    Zitat von Copperhead

    Hier nochmal ein Patch. Jetzt funktioniert das Installieren von den VDR-eigenen Sprachdateien auch.


    Ich sehe im Moment keine Probleme mehr. Ihr?


    Ich muß DVBDIR setzen. Da das beim compilieren nicht per -I$(DVBDIR) übergeben wird, gibts schon Fehler beim ersten File:

    Code
    g++ -g -O3 -Wall -D__user= -D_KERNEL_STRUCT_NAMES= -D__u8=uint8_t -fPIC -Werror=overloaded-virtual -Wno-parentheses -fPIC -c -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DREMOTE_KBD -DLIRC_DEVICE=\"/var/run/lirc/lircd\" -DVIDEODIR=\"/video\" -DCONFDIR=\"/video\" -DCACHEDIR=\"/video\" -DRESDIR=\"/video\" -DPLUGINDIR=\"/usr/local/lib/vdr\" -DLOCDIR=\"/usr/src/vdr-1.7.35-test4/locale\" -I/usr/include/freetype2   audio.c
In file included from audio.c:12:
dvbdevice.h:18:2: error: #error VDR requires Linux DVB driver API version 5.3 or higher!
make: *** [audio.o] Fehler 1


    Unabhängig davon, halte ich den Schalter für local Build falsch. Ein normales 'make' muß ausreichen, damit das Programm und alle zum laufen des Programms notwendige Dateien innerhalb des Source- bzw. Build-Verzeichnisses abgelegt werden. Teile der Variablen sind fixe Parameter für den VDR, wie z.B. LIBDIR und LOCDIR. Die dürfen sich für einen Build zum Testen (local Build) und einen Build für eine Installation nicht ändern. Genaugenommen muß ein Makefile alles neu bauen, wenn sich eine Konfigurationsdatei ändert.


    Es sollten alle konfigurierbaren Parameter, auch wenn per Default auskommentiert, in der Make.config.template verbleiben (DVBDIR).


    Gruß
    e9hack

    Mal eine kurze Anmerkung zu DVBDIR: wenn man den Hinweis von UFO befolgt, und in original Kernelsources # error in frontend.h einträgt, sieht man sehr schnell wo das richtige -I überall fehlt. Ich glaube das von newplugin erzeugte plugin-Makefile sollte an MAKEDEP dringend(!) Angepasst werden. Da kann Copperhead nämlich durchreichen was er will, im MAKEDEP kann es nicht ankommen.


    Ich habe als Notlösung -I...uapi mit in CXX und CC eingebaut - und selbst das rennt bei vielen Plugins in die Wand, weil bei DEPMOD g++ anstatt $(CXX) stteht.


    Gruß, Ingo

    Ich nutzt seit langer Zeit schon immer die neuste vdr-version.
    Da ich die 1.7.34 verpasst habe habe ich mit der 1.7.35 begonnen.
    Ich bin allerdings erst einmal richtig erschrocken, da kein einziges Plugin mehr funktioniert.
    Auch das "make install" will nimmer, bzw. es kopiert die Plugins + Zubehört nicht an den richtigen Stelle.
    zum Glück kann man das noch händisch kopieren.


    Warum ich hier eigentlich Post ist ein Verständnis Problem.


    Es gibt jetzt eine Patch für die "Makefile" Datei.
    Macht das denn überhaupt Sinn? Ich vermute mal das kls nicht mehr zurück schwenken wird.
    Wäre es da nicht sinnvoller die Plugins zu überarbeiten damit die mit der neuen Struktur funktioniert? Anstatt sich am Makefile auszutoben?


    So das es am schluss wieder alles ohne Patchen funktioniert?

    Zitat von Copperhead

    Hier nochmal ein Patch. Jetzt funktioniert das Installieren von den VDR-eigenen Sprachdateien auch.


    Ich sehe im Moment keine Probleme mehr. Ihr?


    Hab nur mal schnell quergelesen (momentan keine Zeit zum testen).
    Das hier ist dir wohl versehentlich ins VDR-Makefile reingerutscht:

    Code
    -       xgettext -C -cTRANSLATORS --no-wrap --no-location -k -ktr -ktrNOOP --package-name=VDR --package-version=$(VDRVERSION) --msgid-bugs-address='<vdr-bugs@tvdr.de>' -o $@ `ls $^`
+       xgettext -C -cTRANSLATORS --no-wrap --no-location -k -ktr -ktrNOOP --package-name=vdr-$(PLUGIN) --package-version=$(VERSION) --msgid-bugs-address='<see README>' -o $@ `ls $^`


    Klaus

    Ich glaube, die Patches die Copperhead hier postet, sind die Testfälle für die nächste Version - also immer fleißig testen. Am besten auch Leute, die media_build_experimental als dvb-Treiber benutzen...


    Gruß, Ingo

    Zitat von kasper-ls

    Wäre es da nicht sinnvoller die Plugins zu überarbeiten damit die mit der neuen Struktur funktioniert? Anstatt sich am Makefile auszutoben?


    So das es am schluss wieder alles ohne Patchen funktioniert?


    Erstmal muss die Makefilesache fertig sein, DANN kann man die Plugins anpassen. Aktuell macht es noch keinen Sinn da jetzt wild an den Plugins rumzufummeln solange die Makefilesache sich ständig ändert.


    Bleibe einfach bei deinem aktuellen funktionierenden Softwarestand und warte ab, das wird sich dann schon regeln.


    cu

    Zu DVBAPI: Ich verstehe immernoch nicht, warum das nötig ist. Was passiert denn wenn der VDR gegen die Kernel-Header gebaut wird? Es ist doch nicht so, als würde sich stündlich die API ändern. Ich habe das vor einiger Zeit selbst mal getestet und das läuft problemlos.


    Das ist meiner Meinung nach eine Altlast, die aus der Zeit stammt, wo HDTV noch neu war. Da wurde ja noch recht viel an der API gebastelt.


    kls: Ja, das soll da nicht sein. Ist jetzt erstmal auch nicht schlimm, aber im finalen Patch muss es dann natürlich wieder richtig.


    e9hack: Tolle Idee. Ich lade dich hiermit herzlich dazu ein, es selbst als Patch umzusetzen. Ich bastle jetzt schon seit Stunden am Makefile rum und das was du machen willst geht schlicht nicht.

    Zitat von Copperhead

    Zu DVBAPI: Ich verstehe immernoch nicht, warum das nötig ist. Was passiert denn wenn der VDR gegen die Kernel-Header gebaut wird? Es ist doch nicht so, als würde sich stündlich die API ändern. Ich habe das vor einiger Zeit selbst mal getestet und das läuft problemlos.


    ...wenn man einen halbwegs aktuellen Kern hat, hast Du heute um 18:55 recht. Aber für alle die alte Kerne mit neuen dvb-Treibern benutzen, und auch weil wir nicht wisden ob und wann sich in den Headern etwas ändert, sollte man die Möglichkeit haben, gegen die RICHTIGEN Header zu bauen, die zu den Treibern gehören, die man benutzt. Ich halte das für keine Altlast, sondern für eine nachhaltige Notwendigkeit, wenn man ein zukunftssicheres Konzept verfolgt.


    Gruß, Ingo

    Bis in die Plugins sollte es aber kommen. Es landet zumindest in der vdr.pc über die cflags cxxflags.


    Vielleicht sollte man hier etwas weiter gehen und statt.


    Code
    pkg-config --variable=cflags vdr
pkg-config --variable=cxxflags vdr


    Das allgemein üblichere

    Code
    pkg-config --cflags vdr
pkg-config --includes vdr


    benutzen.


    Dann könnten die Includes einzeln behandelt werden.

    Zitat von Copperhead

    e9hack: Tolle Idee. Ich lade dich hiermit herzlich dazu ein, es selbst als Patch umzusetzen. Ich bastle jetzt schon seit Stunden am Makefile rum und das was du machen willst geht schlicht nicht.


    Habe ich doch, mußt nur mal den Thread lesen. Ich habe auch versucht zu beschreiben, was das Build-System/Makefile alles können sollte.


    Gruß
    e9hack


    Auf meinem gentoo (aktuell) gibts kein --includes, sondern --cflags-only-I.


    Das Problem bei v10 ist, dass -I/bla/uapi gar nicht in vdr.pc landet. Ich glaube deshalb bricht der build bei 9ehack auch wegen der alten kernel-api ab, aber das ist nur Spekulatius - ich kenne sein System nicht.


    Ich kann jedenfalls nur mit den Kernel-Headern bauen. Habe 7,8,9 ausgelassen, deshalb kann ich Dir leider nicht sagen, wenn es nicht mehr in vdr.pv und im compiler-Aufruf verschwunden ist. (ja, in Make.config habe ich DVBDIR nachgezogen)


    Gruß, Ingo

    Bei mir leider nicht. vdr-1.7.35 aus git mit makefilefix10 gepatched:


    Sorry. Ist aber so.


    Gruß, Ingo

    Wenn ich mir noch etwas wünschen darf (ja, ich weiss, Du hast - mit Recht - die Schnauze von von Sonderlocken). Ich fände es gut sowas in Make.config zu haben:

    Code
    #remove Comment to get Debug information
#GDB_DEBUG = 1
ifdef GDB_DEBUG
CFLAGS += -g -ggdb -O0
CXXFLAGS += -ggdb -O0
LDFLAGS += -g -ggdb -O0
endif


    Gruß, Ingo

    Zitat von e9hack


    Unabhängig davon, halte ich den Schalter für local Build falsch. Ein normales 'make' muß ausreichen, damit das Programm und alle zum laufen des Programms notwendige Dateien innerhalb des Source- bzw. Build-Verzeichnisses abgelegt werden. Teile der Variablen sind fixe Parameter für den VDR, wie z.B. LIBDIR und LOCDIR. Die dürfen sich für einen Build zum Testen (local Build) und einen Build für eine Installation nicht ändern. Genaugenommen muß ein Makefile alles neu bauen, wenn sich eine Konfigurationsdatei ändert.


    Kein "Makefile-System" kann jeden erdenklichen Fall von externer Einflussnahme erkennen. Spätestens wenn Variablen von außen kommen (Environment, Parameter an "make") ist es vorbei mit automatischem Erkennen. Ein "make clean" nach Umkonfigurieren ist also nie verkehrt.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden