Posts by domml

algorithm zieht auch nichts nach, also kein vector/set/string o.ä.

Die erste Lösung ist doch lokal in tools.h. Und von "Benutzung" der STL kann man doch kaum sprechen, wenn nur min/max/swap geholt werden. sgn ist dort gar nicht implementiert, kann also so bleiben wie es ist.

Ich denke auch, dass dieses Macro ein Implementierungsdetail der STL ist, das keineswegs zur garantierten Schnittstelle gehört.

Es gibt m.E. folgende saubere Lösungen:
tools.h:

#include <algorithm>
using std::max;
using std::min;
using std::swap;
using std::sgn; // hier bin ich mir nicht sicher, ob das in std:: überhaupt definitert ist.

Oder

tools.h

namespace VDR {
template<class T> inline T min(T a, T b) { return a <= b ? a : b; }
template<class T> inline T max(T a, T b) { return a >= b ? a : b; }
template<class T> inline int sgn(T a) { return a < 0 ? -1 : a > 0 ? 1 : 0; }
template<class T> inline void swap(T &a, T &b) { T t = a; a = b; b = t; }
}

+ überall da, wo #include "tools.h" steht ein:

using namespace VDR;

Oder:
tools.h

namespace VDR {
template<class T> inline T min(T a, T b) { return a <= b ? a : b; }
template<class T> inline T max(T a, T b) { return a >= b ? a : b; }
template<class T> inline int sgn(T a) { return a < 0 ? -1 : a > 0 ? 1 : 0; }
template<class T> inline void swap(T &a, T &b) { T t = a; a = b; b = t; }
}
#ifdef VDR_COMPILATION
using namespace VDR;
#endif

Und im VDR-Makefile würde dieses #define gesetzt.

Für die 2. Lösung stelle ich gerne 2 Zeilen Script zur Verfügung, die das in alle VDR-Sourcen einfügt.

Nur mit diesen Lösungen kann man beim Plugin-programmieren beliebigen STL code an beliebiger Stelle verwenden und muß keine Header-Reihenfolge einhalten.

Bei den anderen skizzierten Lösungen gäbe es trotzdem Kollisionen mit der STL.

Oder: bei der Vdr-Compilation wird ein define gesetzt, z.B. VDR_COMPILATION und tools.h macht
#ifdef VDR_COMPILATION
using namespace vdr;
#endif

Wie wäre es mit 2 Sätzen von headers:
Include/tools.h
#include_next "tools.h"
using namespace vdr;

Include/plugins/tools.h
namespace vdr {
...
}

Und die Plugins includieren nur include/plugins.

Richtig, das using muß in die .c Files.

Klaus, könntest Du nicht die Funktionen aus vdr, die mit der STL kollidieren in einen namespace ( z. B. "vdr") legen, und dann diesen namespace in den vdr .c files mit "using namespace vdr" bekanntmachen. Dann sollte nix mehr kollidieren.

Wenn Du Interesse hast, könnte ich dafür einen Patch bauen.

Gruß

Dominik

Ok, der Wert scheint negativ zu sein, also Signal = - abs(Signal)

Sollte es in dem Patch von Klaus nicht "if (Signal < 0)" heißen. Oder gleich Signal = abs(Signal) ?

Hallo Kai,
Ich habe eine v7 unter yavdr 0.6.1 am Laufen. Die Treiber habe ich nach Anleitung von DD gebaut.

Hallo 3PO, Du müßtest wie folgt herausfinden, wer die falsche lib linkt:
ldd <vdr-binary>
das müßte alle libs ausgeben, gegen die vdr gelinkt ist

Wenn da die swresample.1 dabei ist, dann kannst Du jede einzelne .so mit ldd abchecken, welche libswresample.1 nachzieht.
Wenn bei vdr nix kommt, dann kannst Du alle plugin .so's der Reihe nach mit "ldd" überprüfen. Wahrscheinlich ist es eh die softhddev Library. Dann wieder alle .so's einzeln mit "ldd" überprüfen. Sehr wahrscheinlich ist softhddev doch nicht gegen ffmpeg.3 gelinkt. Hoffentlich habe ich mich verständlich ausgedrückt. Sonst auch gerne PM, das Ergebnis können wir ja dann hier posten

Den Roboto-Font habe ich gefunden, jetzt sieht es schon besser aus.

Aber welcher Font wird denn hier gesucht ?
Mar 6 17:17:21 vdrng vdr: [4398] skindesigner: font Sans Serif:Bold not available, skipping

Hat sich an der softhddevice Version etwas geändert ? Das Bild ist bei 1080i deutlich schlechter als vor dem Update. Anderer deinterlacer bringt keine große Änderungen.

Noch ein paar Details:
Das Problem besteht nur in den Skindesigner Skins. Ich habe den Eindruck, dass Fonts nicht gefunden werden, weil z.B. im glasslike das Layout in der Kanalanzeige nicht passt und die Fonts zu groß sind, sodass z.B. das Datum nicht vollständig angezeigt wird.

Hallo,
gerade habe ich den upgrade auf 0.6.1 gemacht. Seither ist der OSD-Font kaum noch lesbar. Tipps ?

Danke

Dominik

PS: Ich habe keine Konfiguration mit 2 Graphikkarten (onboard + GT220).
Für diese Kobination funktioniert die YaVDR-Monitor-Konfiguration nicht. Ich habe deshalb eine handgehäkelte xorg.conf. WIe kann ich verhindern, dass mir diese beim update/upgrade überschrieben wird ?

Was habe ich falschgemacht ?

SQL-Error in 'prepare(stmt_prepare)' - Unknown column 'fsk' in 'field list' (1054) 'Unknown column 'fsk' in 'field list''

Hat super funktoiniert, vielen Dank.

sudo dbset system.x11.dualhead.enabled=1
sudo dbset vdr.plugin.graphtft.enabled=1
sudo process-template /etc/init/openbox-second.conf
sudo process-template /etc/init/graphtft-fe.conf
sudo start openbox-second
sudo start graphtft-fe

Mini-Typo beim ersten Kommando. So wie oben geht's

Dann verkünstele ich mich lieber selber

Aber wie ?

Wie kann ich denn graphTFT von Hand aktivieren? Ansonsten müßte die Konfig eh passen.

Hallo,
meine Dualhead-Konfiguration scheint nicht richtig erkannt zu werden.
Ich habe in dem System aus der Signatur eine OnBoard NVidia 8200, an dem das kleine TFT im Gehäuse per VGA hängt und an der GT220 hängt der Receiver/Fernseher per HDMI. Beide werden laut Xorg.log erkannt.

In der YaVDR DB steht jedoch

x11 { 
dualhead { 
      enabled = 0     }     
display {       0 
{         
device = CRT-0
mode {           0 = nvidia-auto-select         }
 default = nvidia-auto-select       
}     }   }

In den Anzeigeeinstellungen (Einstellungen/Hardware/Anzeigeeinstellungen) steht nichts, "Erneut nach Bildschirmen suchen" ändert nichts.
DIe Konfiguration von GraphTFT wird nicht angeboten.

Den TV konnte ich aktivieren, indem ich eine xorg.conf von meinem alten System eingespielt habe, ansonsten war nur auf dem TFT ein Bild.

Ich fahre den 304-er NVidia Treiber und den 3.19 er Kernel weil ansonsten die Anstürze, die in den beiden anderen Threads gelöst wurden kamen.

Tipps ?

Danke

Dominik

hg pull -u macht pull + update.