[ANNOUNCE] VDR developer version 1.7.34

Zitat von kls

Was du an dieser Stelle machen willst ist ja eigentlich, eine zweite "Skin" zu betreiben, oder?
Da fände ich es viel sinnvoller, das dann auch wirklich als eigene Skin zu implementieren, und nicht ins cStatus "reinzuquetschen". Allerdings müsste ich dazu VDR erst beibringen, mehrere Skins gleichzeitig zu betreiben, und das kann frühestens nach der Version 2.0 erfolgen (falls dieser Weg überhaupt sinnvoll machbar ist).

Das wäre sicherlich der eleganteste Weg, da die Skin-Schnittstelle alles benötigte mitbringt. Hast du schon eine Idee, ab wann es einen Stable VDR 2.0 gibt?

Falls du dann an der Skin-Schnittstelle entwickelst, könnte man da versuchen diese noch etwas flexibler für die Plugin-Entwicklung zu gestalten? Ich nutze z.B. beim CD-Player Plugin das cSkinDisplayMenu zur Titelanzeige. Hier habe ich zwar eine Menüdarstellung, die für die einfache Titeldarstellung ausreichend ist, aber z.B. eine Equalizer-Darstellung via Span-Plugin ist da nicht möglich. Ich müsste dazu ein eigenes OSD-Display schreiben, aber ob das dann zu dem gewählten Skin passen würde, ist dann auch Glückssache. Wenn es soweit ist, sollte man sich vielleicht auch mal an der Ecke noch was ausdenken.

Für das Autostart, CD-Player und Trayopenng Plugin habe ich für VDR 1.7.34 angepasste Makefiles in mein Repository eingecheckt

kls

Hallo,

ich habe hier noch ein anderes Problem (nicht erst seit der letzten Version, leider kann ich aber nicht mehr sagen, wann es mir zum ersten Mal aufgefallen ist):

Normalerweise kommt nach dem Beenden einer Aufzeichnungswiedergabe ja das normale Fernsehbild wieder (so wie in folgendem Beispiel-Log zu sehen):

Dec 25 15:20:05 home-05 vdr: [11250] replay /video/video0/Celtic_Woman_-_A_Christmas_Celebration/2012-12-23.22.12.1-0.rec
Dec 25 15:20:05 home-05 vdr: [11250] playing '/video/video0/Celtic_Woman_-_A_Christmas_Celebration/2012-12-23.22.12.1-0.rec/00001.ts'
Dec 25 15:20:05 home-05 vdr: [12526] dvbplayer thread started (pid=11250, tid=12526, prio=high)
Dec 25 15:20:05 home-05 vdr: [12527] non blocking file reader thread started (pid=11250, tid=12527, prio=high)
.
.
.
Dec 25 15:22:14 home-05 vdr: [12527] non blocking file reader thread ended (pid=11250, tid=12527)
Dec 25 15:22:14 home-05 vdr: [12526] dvbplayer thread ended (pid=11250, tid=12526)
Dec 25 15:22:14 home-05 vdr: [11250] switching to channel 1

In der letzten Zeile wird dann wieder zeitnah für LiveTV auf Kanal 1 geschaltet.

Nun tritt aber in unregelmäßigen Abständen und um so häufiger je länger eine Wiedergabe läuft, der Effekt auf, das nach Ende der Wiedergabe nicht auf LiveTV zurückgeschaltet wird (das Bild bleibt schwarz). Das er aber tatsächlich wieder im Live-Modus ist erkennt man, wenn man mit OK den Status aufruft, hier wird die Information vom erwarteten Kanal angezeigt.

Das Log sieht dann z.B. so aus:

Dec 25 15:22:42 home-05 vdr: [11250] replay /video/video0/POLETTOS_Kochschule/Meine_Lieblingsrezepte:_Hirschkalbsrücke/2012-12-23.16.28.26-0.rec
Dec 25 15:22:42 home-05 vdr: [11250] playing '/video/video0/POLETTOS_Kochschule/Meine_Lieblingsrezepte:_Hirschkalbsrücke/2012-12-23.16.28.26-0.rec/00001.ts'
Dec 25 15:22:43 home-05 vdr: [12778] dvbplayer thread started (pid=11250, tid=12778, prio=high)
Dec 25 15:22:43 home-05 vdr: [12779] non blocking file reader thread started (pid=11250, tid=12779, prio=high)
.
.
.
Dec 25 15:26:05 home-05 vdr: [12779] non blocking file reader thread ended (pid=11250, tid=12779)
Dec 25 15:26:05 home-05 vdr: [12778] dvbplayer thread ended (pid=11250, tid=12778)
Dec 25 15:26:10 home-05 vdr: [11264] frontend 3/0 timed out while tuning to channel 1331, tp 111641
Dec 25 15:27:07 home-05 vdr: [12940] epg data writer thread started (pid=11250, tid=12940, prio=low)
Dec 25 15:27:08 home-05 vdr: [12940] epg data writer thread ended (pid=11250, tid=12940)
Dec 25 15:27:14 home-05 vdr: [11264] frontend 3/0 timed out while tuning to channel 1331, tp 111641
Dec 25 15:27:31 home-05 vdr: [11250] switching to channel 1

Was also fehlt ist nach Zeile 9 das "switching to channel 1".
Ich rufe dann in so einem Fall einfach den gleichen oder auch einen anderen Kanal nochmal auf (hier in Zeile 14 zu sehen, bitte den zeitlichen Abstand zu Zeile 9 beachten) und dann geht es ganz normal weiter.
Es treten hierbei auch keine offensichtlichen Nebeneffekte auf.

Da ich hier mit Device-Bonding arbeite (ein Kabel - 4 Device), mit der Konfiguration wie unten zu sehen, könnte es durchaus auch damit zusammenhängen.

Dieser Effekt tritt auf beim Plain-VDR + remote + dvbhddevice.

Interessant wäre auch, ob das schon jemand Anderem, möglicherweise auch mit einer abweichenden Konfiguration, aufgefallen ist.

Gruß
kamel5

Zitat von Ulrich Eckhardt

Hast du schon eine Idee, ab wann es einen Stable VDR 2.0 gibt?

Das kann ich dir sogar ganz genau sagen: wenn er fertig ist ;-).
SCNR

Ich strebe natürlich an, das so bald wie möglich zu schaffen. Es kommen halt immer wieder irgendwelche Dinge daher, die sinnvollerweise noch vorher gemacht werden sollten. Die ganze Makefile-Geschichte war zum Beispiel sowas, denn wenn schon eine größere Änderung, dann lieber jetzt.

Klaus

Zitat von kls

Das kann ich dir sogar ganz genau sagen: wenn er fertig ist ;-).
...

Ach?? - Doch schon so früh?

Ist die Nummer der VDR´s nicht vollkommen egal ??
Macht doch einfach ein ..
ln -s vdr-1.7.34 vdr-2.0
und schon ist alles gut
speed

Moin!

Frohes Fest für'n Rest auch noch mal von mir...

Zitat von Copperhead

dass Plugins bestimmte/alle Header-Dateien nach /usr/include/plugins/$PLUGNAME ablegen

Wenn, dann bitte /usr/include/vdr/plugins/$PLUGNAME.

Zitat von kls

Da fände ich es viel sinnvoller, das dann auch wirklich als eigene Skin zu implementieren, und nicht ins cStatus "reinzuquetschen". Allerdings müsste ich dazu VDR erst beibringen, mehrere Skins gleichzeitig zu betreiben, und das kann frühestens nach der Version 2.0 erfolgen (falls dieser Weg überhaupt sinnvoll machbar ist).

Das wäre in der Tat schön, um Mehrschirmbetrieb vernünftig unter eine Haube zu bekommen.

Aber da spinnen sich bei mir schon wieder weitere Gedanken: Eine Kombination aus Eingabegerät (Fernbedienung, Tastatur usw.), Skin, OSD-Provider und Ausgabegerät als Einheit zu sehen und davon mehrere im vdr verwalten zu können. Dann könnte man schöne Multi-Seat-Umgebungen realisieren. Aber das geht jetzt viel zu weit...

Lars.

Moin,

auch von mir einen fröhlichen Rest vom Fest.

Zitat von kls

Und generell sollte man sich bei jedem Parameter dreimal fragen, ob der *wirklich* konfigurierbar sein *muß*! Wenn ich ein Programm benutze, und ich muß erstmal hunderte von Parametern einstellen, dann reicht's mir schon. Ein Programm soll erstmal einfach funktionieren und das tun, was es soll.

Amen!

Besser kann man es nicht sagen - sehe ich zu 100% genauso.

Zitat

Ehrlich gesagt ist mir diese "Überfrachtung" der cStatus-Schnittstelle schon lange ein Dorn im Auge.
...
Was du an dieser Stelle machen willst ist ja eigentlich, eine zweite "Skin" zu betreiben, oder?

Hm, also ne 2. Skin ist für mich keine Alternative für eine (wie auch immer geartete) Status-Schnittstelle.
Mit Einführung von LCars als default wurde das dev-status-Plugin in den Gulli gekickt.
Da ich noch eine SD-FF am Start habe, ist LCars für mich nicht verwendbar, weshalb ich immer noch das alte TNG-Skin verwende.
Funktionalität ist für mich wichtger, als optische Spielerei.
Leider gibt es keine alte Naive für das dev-status-Plugin.

Selbst im Hinblick auf C/S-Umgebungen finde ich eine Schnittstelle, über die sämtliche Zustandsparameter des VDR abgefragt werden können für äußerst sinnvoll.
Ob das jetzt unbedingt die cStatus-Klasse sein muss - sei mal dahin gestellt.

Zitat

Falls du dann an der Skin-Schnittstelle entwickelst, könnte man da versuchen diese noch etwas flexibler für die Plugin-Entwicklung zu gestalten?

+1

Ich würde es für sinnvoll halten, wenn man die jetzigen OSD-Klassen etwas aufbricht und "echte" GUI-Elemente einführt, wie es bei GUI-Entwicklung Gang und Gäbe ist.
Zusammen mit einer Trennung nach MVC würde sich die Bedienung auch stringenter anfühlen.
So ist z.B. nicht unbedingt einsichtig, dass wenn ich in einer Menüseite einen Text eingebe, dass bei Druck auf 'm' das ganze Menü geschlossen wird (und somit meine Eingaben im Eimer sind).

Meiner Ansicht nach entspräche ein Plugin dem 'M' von MVC und es müsste nur die Daten bereit stellen.
Wenn z.B. die Lautstärker geändert werden soll, wäre das für ein Plugin nur eine Zahl. Erst im Skin wird daraus ein Oberflächen-Element.
Für den Plugin-Entwickler dürfte es völlig Banane sein, ob der Skin-Entwickler für die Erfassung der Benuzereingabe (der Zahl) einen Schieberegler, Drehknopf oder ein Eingabefeld verwendet. Nach erfolgter Eingabe erhält das Plugin die geänderte Zahl und kann darauf reagieren.

Wenn die Verantwortlichkeiten derart getrennt sind, ist es auch möglich, eine remote-Bedienung zu schnitzen, ohne sich nen Wolf zu coden

Gruß Gero

Zitat von geronimo

So ist z.B. nicht unbedingt einsichtig, dass wenn ich in einer Menüseite einen Text eingebe, dass bei Druck auf 'm' das ganze Menü geschlossen wird (und somit meine Eingaben im Eimer sind).

Niemand zwingt dich dazu die Taste "m" der VDR Fernbedienungsfunktion "Menu" zuzuweisen Gegen solche Doppelbelegungen helfen auch Änderungen am VDR OSD System nix

Ist aber auch auf anderen Sytemen so, wenn ich unter Windows der Tastaturtaste "s" dann Kommando "Windows runterfahren" zuweise klappt das mit dem Textschreiben auch nicht mehr toll Dafür nutze ich dann lieber Tastenkombinationen wie z.B. strg+alt-s.

cu

Hi,

ich bekomme zwar softhddevice compiliert, aber leider weder Bild noch Ton. Im log nichts Auffälliges. Dagegen habe ich pvr350 ans Laufen bekommen. Läuft das bei irgendwem?

MfG,

jsffm

Moin moin,

Zitat

Gegen solche Doppelbelegungen helfen auch Änderungen am VDR OSD System nix ...

Du hast zwar ein Smiley angefügt, ich nehme die Aussage trotzdem mal ernst ...
... denn mir ist z.B. ein Dorn im Auge, dass (fast) jedes Plugin eine Tastatur-Verarbeitung programmiert hat, die - schaut man mal genauer hin - meist nur für OSD-Menüverarbeitung verwendet wird.
In jeder GUI-Anwendung werden viele Tasten mehrfach belegt und wenn die Verarbeitungs-Hierarchie, bzw. deren Kapselung richtig ist, dann gibt es auch keine Konflikte.
Vom gleichen Autor stammt ja auch der Adler - für mich ein Vorbild an genialer Mehrfachbelegung von Tastatur und Maustasten.
Ich habe noch keine Anwendung gesehen, die den Adler in Sachen "situationsgerechter Bedienung" schlagen könnte. Mit etwas Einarbeitung erreicht man eine Produktivität, von der andere nur träumen können
Schade nur, dass die Entwicklung in völlig falsche Bahnen geraten ist. Nun ja, Leben ist das was passiert, während wir andere Pläne machen.

Der VDR könnte etwas von der Bedienung-Genialität vom Adler gebrauchen.
Es gibt jede Menge Callbacks, die mit Tasten verbunden werden können. Durch die vielen Plugins könnten die Tasten knapp werden
Also ist eine kontextabhängige Auswertung Pflicht.
Das wiederum bedeutet, dass wenn ich im Menü in einem Eingabefeld bin, "keine" Callbacks ausgewertet werden dürfen.
Ich würde den Kontext sogar so hoch aufhängen, dass es Sinn machen würde, die Definitionen in remote.conf nach Kontext zu gruppieren - und somit dort schon eine Mehrfachbelegung zuzulassen.
Rein technisch wird die Kapselung der Event-Verarbeitung meines Wissens derart gemacht, dass eine Funktion "handleEvent" über den Rückgabewert mitteilt, ob der Event verarbeitet wurde oder nicht.
So könnte der VDR nach den Plugins/GUI-/OSD-Elementen prüfen, ob es unverarbeitete Tastendrücke gibt und dann deren angemeldete Callbacks ausführen.

Naja - wenn für das OSD (zertifizierte?) Core-GUI-Elemente existieren besteht auch keine Gefahr mehr, dass Plugins Tasten auswerten, die nur den VDR was angehen - denn dann braucht kein Plugin mehr die Tastatur-Verarbeitung zu kodieren.

Gruß Gero

FULL ACK. Ich möchte kontextabhängig jeden Tastendruck mit einem Pluginaufruf übersteuern können.
Bsp. Taste 0 mit dem Aufruf von zaphistory.
Auf den MainMenuHooks Patch für den Aufruf von epgsearch und extrecmenu verzichten können.
usw.

Es ist Weihnachten. Da kann man sich mal was wünschen.

Dazu müsste aber die Main Loop in vdr.c umgebaut werden,
z.B. das was unter
"// Keys that must work independent of any interactive mode:
steht.
Und nicht nur das. Das wäre eine riesige Änderung auch für
alle Patches, die da rein greifen um sich Tasten zu klauen.

Zitat

Und nicht nur das. Das wäre eine riesige Änderung auch für
alle Patches, die da rein greifen um sich Tasten zu klauen.

Ja und?
Ich habe nicht behauptet, dass die Änderung in 5 Minuten erledigt wäre.

... aber wenn Klaus an dem Punkt ist, alte Zöpfe abzuschneiden, bzw. in Frage zu stellen, dann wollte ich nur deutlich machen, was ich noch als alten Zopf ansehe, der unbedingt ab sollte.
Wobei ich mich bewusst auf die Sicht des Anwenders beschränkt habe.
Wenn ich mir den Code, bzw. die Klassen anschaue würde mir noch viel mehr einfallen

Gruß Gero

So, habe soeben mal die Version 1.7.34 compiliert - plain-VDR mit remote-Plugin und dvbhddevice 0.0.4 aus den VDR-Sourcen (wo liegt hier eigentich der Unterschied zu dvbhddevice vom 12.12.2012 im Internet?).

Ich habe mit Version 1.7.34 kein Bild (mehr, mit 1.7.33 ging es noch) und das Menü hat keinen Text.

Dec 26 14:20:57 vdr2 vdr: [3327] VDR version 1.7.34 started
Dec 26 14:20:57 vdr2 vdr: [3327] codeset is 'UTF-8' - known
Dec 26 14:20:57 vdr2 vdr: [3327] found 28 locales in /home/vdr2/vdr/vdr-1.7.34/locale
Dec 26 14:20:57 vdr2 vdr: [3327] loading plugin: /home/vdr2/vdr/vdr-1.7.34/PLUGINS/lib/libvdr-dvbhddevice.so.1.7.34
Dec 26 14:20:57 vdr2 vdr: [3327] loading plugin: /home/vdr2/vdr/vdr-1.7.34/PLUGINS/lib/libvdr-remote.so.1.7.34
Dec 26 14:20:57 vdr2 vdr: [3327] loading /etc/vdr/devel/sources.conf
Dec 26 14:20:57 vdr2 vdr: [3327] loading /etc/vdr/devel/channels.conf
Dec 26 14:20:57 vdr2 vdr: [3327] loading /etc/vdr/devel/timers.conf
Dec 26 14:20:57 vdr2 vdr: [3327] loading /etc/vdr/devel/svdrphosts.conf
Dec 26 14:20:57 vdr2 vdr: [3327] loading /etc/vdr/devel/keymacros.conf
Dec 26 14:20:57 vdr2 vdr: [3327] registered source parameters for 'A - ATSC'
Dec 26 14:20:57 vdr2 vdr: [3327] registered source parameters for 'C - DVB-C'
Dec 26 14:20:57 vdr2 vdr: [3327] registered source parameters for 'S - DVB-S'
Dec 26 14:20:57 vdr2 vdr: [3327] registered source parameters for 'T - DVB-T'
Dec 26 14:20:57 vdr2 vdr: [3327] probing /dev/dvb/adapter0/frontend0
Dec 26 14:20:57 vdr2 vdr: [3327] creating cDvbHdFfDevice
Dec 26 14:20:57 vdr2 vdr: [3327] new device number 1
Dec 26 14:20:57 vdr2 vdr: [3329] video directory scanner thread started (pid=3327, tid=3329, prio=high)
Dec 26 14:20:57 vdr2 vdr: [3329] video directory scanner thread ended (pid=3327, tid=3329)
Dec 26 14:20:57 vdr2 vdr: [3330] epg data reader thread started (pid=3327, tid=3330, prio=high)
Dec 26 14:20:57 vdr2 vdr: [3330] reading EPG data from /etc/vdr/devel/epg.data
Dec 26 14:20:57 vdr2 vdr: [3328] video directory scanner thread started (pid=3327, tid=3328, prio=high)
Dec 26 14:20:57 vdr2 vdr: [3328] video directory scanner thread ended (pid=3327, tid=3328)
Dec 26 14:20:57 vdr2 vdr: [3327] frontend 0/0 provides DVB-S,DVB-S2,DSS with QPSK ("STV090x Multistandard")
Dec 26 14:20:57 vdr2 vdr: [3332] tuner on frontend 0/0 thread started (pid=3327, tid=3332, prio=high)
Dec 26 14:20:57 vdr2 vdr: [3332] cTimeMs: using monotonic clock (resolution is 1 ns)
Dec 26 14:20:57 vdr2 vdr: [3327] found 1 DVB device
Dec 26 14:20:57 vdr2 vdr: [3327] initializing plugin: dvbhddevice (0.0.4): HD Full Featured DVB device
Dec 26 14:20:57 vdr2 vdr: [3327] initializing plugin: remote (0.5.0): Fernbedienung
Dec 26 14:20:57 vdr2 vdr: [3327] setting primary device to 1
Dec 26 14:20:57 vdr2 vdr: [3327] assuming manual start of VDR
Dec 26 14:20:57 vdr2 vdr: [3327] SVDRP listening on port 6419
Dec 26 14:20:57 vdr2 vdr: [3327] setting current skin to "lcars"
Dec 26 14:20:57 vdr2 vdr: [3327] loading /etc/vdr/devel/themes/lcars-default.theme
Dec 26 14:20:57 vdr2 vdr: [3327] starting plugin: dvbhddevice
Dec 26 14:20:57 vdr2 vdr: [3327] starting plugin: remote
Dec 26 14:20:57 vdr2 vdr: [3327] remote: using '/dev/input/ir'
Dec 26 14:20:57 vdr2 vdr: [3327] remote-ir: autorepeat supported
Dec 26 14:20:57 vdr2 vdr: [3327] remote-ir: exclusive access granted
Dec 26 14:20:57 vdr2 vdr: [3327] remote control remote-ir - learning keys
Dec 26 14:20:57 vdr2 vdr: [3333] section handler thread started (pid=3327, tid=3333, prio=low)
Dec 26 14:20:57 vdr2 vdr: [3335] KBD remote control thread started (pid=3327, tid=3335, prio=high)
Dec 26 14:20:57 vdr2 vdr: [3330] epg data reader thread ended (pid=3327, tid=3330)
Dec 26 14:20:57 vdr2 vdr: [3327] ERROR (hdffcmd.c,270): Error creating font face: Ungültige Adresse
Dec 26 14:20:57 vdr2 vdr: last message repeated 6 times
Dec 26 14:20:57 vdr2 vdr: [3327] device /dev/input/ir: TT6400 DVB IR receiver
Dec 26 14:20:57 vdr2 vdr: [3327] ERROR (hdffcmd.c,270): Error creating font face: Ungültige Adresse
Dec 26 14:22:00 vdr2 vdr: last message repeated 7 times
Dec 26 14:22:31 vdr2 vdr: [3327] new remote-ir code: 000000010001000E = Up
Dec 26 14:22:31 vdr2 vdr: [3327] ERROR (hdffcmd.c,270): Error creating font face: Ungültige Adresse
Dec 26 14:22:32 vdr2 vdr: last message repeated 9 times
Dec 26 14:22:32 vdr2 vdr: [3327] new remote-ir code: 0000000100010011 = Up
Dec 26 14:22:32 vdr2 vdr: [3327] ERROR (hdffcmd.c,270): Error creating font face: Ungültige Adresse
Dec 26 14:22:33 vdr2 vdr: last message repeated 3 times
Dec 26 14:22:33 vdr2 vdr: [3327] new remote-ir code: 0000000100010012 = Down
Dec 26 14:22:33 vdr2 vdr: [3327] ERROR (hdffcmd.c,270): Error creating font face: Ungültige Adresse
Dec 26 14:22:33 vdr2 vdr: last message repeated 3 times
Dec 26 14:22:33 vdr2 vdr: [3327] new remote-ir code: 000000010001000F = Menu
Dec 26 14:22:33 vdr2 vdr: [3327] ERROR (hdffcmd.c,270): Error creating font face: Ungültige Adresse
Dec 26 14:22:36 vdr2 vdr: last message repeated 3 times
Dec 26 14:22:36 vdr2 vdr: [3327] new remote-ir code: 000000010001000E = Ok
Dec 26 14:22:36 vdr2 vdr: [3327] ERROR (hdffcmd.c,270): Error creating font face: Ungültige Adresse
Dec 26 14:23:13 vdr2 vdr: last message repeated 8 times

hallo,

Danke für die neue X-Mas version

ich hab die Make.config.template nach Make.config kopiert und in dieser dann das DVBDIR explizit angegeben (DVBDIR = /usr/local/src/dvb/linux). sonst gibt es meldungen in dieser art:

error: #error VDR requires Linux DVB driver API version 5.3 or higher!

dann ein "make" - der console-output liefert dann zum schluß:

.
.
*** Plugin dvbhddevice:
[: 14: /opt/src/vdr/vdr-1.7.34/PLUGINS/lib: unexpected operator
g++ -g -O3 -Wall -fPIC -Werror=overloaded-virtual -Wno-parentheses -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -I/opt/src/vdr/vdr-1.7.34/include -c -DPLUGIN_NAME_I18N='"dvbhddevice"'  dvbhddevice.c
In file included from /opt/src/vdr/vdr-1.7.34/include/vdr/menuitems.h:14,
             	from /opt/src/vdr/vdr-1.7.34/include/vdr/plugin.h:14,
             	from dvbhddevice.c:9:
/opt/src/vdr/vdr-1.7.34/include/vdr/dvbdevice.h:18:2: error: #error VDR requires Linux DVB driver API version 5.3 or higher!
make[1]: *** [dvbhddevice.o] Error 1
*** Plugin dvbsddevice:
[: 14: /opt/src/vdr/vdr-1.7.34/PLUGINS/lib: unexpected operator
g++ -g -O3 -Wall -fPIC -Werror=overloaded-virtual -Wno-parentheses -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -I/opt/src/vdr/vdr-1.7.34/include -c -DPLUGIN_NAME_I18N='"dvbsddevice"'  dvbsddevice.c
In file included from /opt/src/vdr/vdr-1.7.34/include/vdr/menuitems.h:14,
             	from /opt/src/vdr/vdr-1.7.34/include/vdr/plugin.h:14,
             	from dvbsddevice.c:10:
/opt/src/vdr/vdr-1.7.34/include/vdr/dvbdevice.h:18:2: error: #error VDR requires Linux DVB driver API version 5.3 or higher!
make[1]: *** [dvbsddevice.o] Error 1
*** Plugin epgtableid0:
.
.
.

passiert beim plain-vdr ohne patches. das vdr-binary wird aber compiliert. wieso findet vdr-core zu den DVB-treibern, die vdr-internen plugins aber nicht mehr? was kann ich da machen - oder hab ich wieder was überlesen (die änderungen bzgl. "Makefile" habe ich schon überflogen)?

gruß, ciax

Ist nen Bug im Makefile "-I$(DVBDIR)/include" müsste eigentlich in vdr.pc landen. Tuts aber nicht.
Du kannst es aber auch erstmal unter "INCLUDES +=" im Plugin Makefile eintragen. Dann sollte es bauen.

BTW, wenn wir gerade dabei sind: "mandir" sollte auch noch in vdr.pc für das install Target der Plugin Makefiles. Manche Plugins bringen ja auch Manpages mit.

cu

danke - du bist immer schnell!

ich versteh's ja nicht wirklich - aus dem Make.config (nicht Makefile):

ifdef DVBDIR
INCLUDES += -I$(DVBDIR)/include
endif

den part meinst du? bzgl. DVBDIR ist in vdr.pc nichts zu sehen.

also jedes plugin Makefile separat "anfassen" ?

@ Klaus

Danke fuer die neue Version,

aber...

Schade das Du es versäumt hast nach den massiven Makefile Änderungen in den beigelegten Plugins, diese nicht um eine Version hochzuzählen

Das macht natürlich jetzt Probleme in meinem Paketmanager, ihm zu sagen welche Version er nehmen soll
i.e
dvbsddevice-0.0.6 oder dvbsddevice-0.0.6
( unterschiedliche checksums in beiden gleich versionierten Versionen)

Bitte das in der nächsten VDR Version fixen

Klaus,
da die beigelegent plugins unter Gentoo outsourced sind,
bist Du damit einverstanden, das ich die plugin pakete
bei uns um einen zähler hochzähle?

i.E dvbsddevice-0.0.6(vdr-1.7.34) --> dvbsddevice-0.0.6.1
eigentlich will ich solchen wildwucher im www vermeiden

Frohe Weihnachten

Zitat von ciax

danke - du bist immer schnell!

ich versteh's ja nicht wirklich - aus dem Make.config (nicht Makefile):

Code

ifdef DVBDIR
INCLUDES += -I$(DVBDIR)/include
endif

den part meinst du? bzgl. DVBDIR ist in vdr.pc nichts zu sehen.

Genau, ich denke das ist einfach ein Bug (es wurde übersehen) das es nicht in den cflags/cxxflags von vdr.pc landet.
Oder es ist nicht gewollt das diese VDR Konfiguration zu den Plugins durchkommt, hängt halt von der Sichtweise ab obs nen Bug ist oder nicht

Zitat von ciax

also jedes plugin Makefile separat "anfassen" ?

Naja, das DVB Dir brauchen ja nur wenige Plugins in den Includes.

cu