Beiträge von Zoolook

Hi,

freut mich, daß sich da wieder was tut!
Ralf, ich hatte mal in der english-sprachigen VDR-ML vorgeschlagen, ich würde da auch mitmachen (hast ja bislang mal rumänische Übersetzung und den "AuthorOnly"-mode von mir freundlicherweise mit eingepflegt). Habe leider bis jetzt nichts mehr gemacht. Ich werde nun paar Übersetzungen wieder aktualisieren, und ev. diese Variablen in vdrburn.sh aus einer Konfigurationsdatei lesen.
Dieser UTF-8 Patch von Oleg, was ist nun mit dem, wieso scheint das bei ihm zu funktionieren und bei uns anderen nicht, Du hast ihn ja auch bloß deaktiviert mit aufgenommen, wird sich da jemand um die Sache in naher Zukunft kümmern?

Gruß,
Lucian

Zitat

Original von Zzam
Zoolook:

Es gibt jetzt ein vdr-skincurses ebuild im cvs.

Zzam

Sauber! Danke, ich hatte das alte vdrplugin-skincurses auch nicht bemerkt.

Zoo

Hi,

wäre schön, wenn in einem nächsten ebuild optional (USE-flag) auch das skincurses plugin gebaut würde (manch einer braucht es manchmal via SSH oder so). Im Anhang ein diff zum vdr-1.3.36.ebuild in welchem ich das mal probiert habe, bei mir geht's.

Lucian

Zitat

Original von Zzam
Zoolook:
Ein nptl-only check ist in Arbeit.
Kannst du bitte mal testen was folgender Befehl auf deinem System ausgibt.

Code

LD_ASSUME_KERNEL=2.4.1 /bin/true 2>/dev/null && echo yes

Auf meinem NPTL-only System rein gar nichts, und wenn ich die Umleitung der Ausgabe weglasse dann eben die Fehlermeldung mit libc.so.6. Ich habe den gleichen Befehl aber auch auf meinem Server getestet (gar kein NPTL) und da echo-et er "yes", viellecht hilft das ja auch da nun wenigstens "yes" anstatt gar nichts kommt, wenn auf einem NPTL mit kompatiblen linuxhreads das gleiche passiert.
Willst Du den dafür vorgesehen USE-flag kompett außen vor lassen, oder eher einen ewarn bringen, je nach - durch den Befehl vorhin - tatsächlich vorgefundenem System, was die Optionen wären die der User hat, wenn er z.B. nur für den einen ebuild den flag konkret ein- oder ausschaltet?

Zoo

Hi, ich hätte da ein paar Vorschläge:
1. Auf einem "Nur-NPTL Gentoo", funktioniert LD_ASSUME_KERNEL=2.4.1 ganz und gar nicht. Wenn nun jemand die neuen Scripts gentoo-vdr-scripts benuntzt, auf so 'nem System, macht /etc/init.d/vdr beim Starten nur Murks, und zwar bei start-stop-daemon und bei logger, nicht einmal beim VDR selber, so daß mir die Fehlersuche einiges an Kopfzerbrechen bereitete:

* Starting vdr-1.3.34 ...
start-stop-daemon: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
 * Failed to start vdr.
/usr/bin/logger: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory

Die Lösung ist einfach, im gentoo-vdr-scripts ebuild (der ansonsten ganz gut aussieht) den USE-flag nptlonly der ja auf son einem Gentoo auch gesetzt ist (glibc hat also gar keine linuxthreads-Unterstützung, deshalb geht LD_ASSUME_KERNEL ja nicht), einfach beachten und das Setzen dieser Umgebungsvariablen aus dem Startskript herausnehmen mit sed oder so, oder diese Sache konfigurierbar in /etc/conf.d/vdr machen (aber eine automatische Konfiguration durch den USE-flag fände ich einfach nur gentoo-konsequent).

2. Ich denke bei softdevice reicht die Abhängigkeit von DFB++ bei gesetzem directfb USE flag, da ja DirectFB dann eh' "mitgezogen" wird, von DFB++

Ansonsten viel Erfolg weiterhin!
Zoo

Zitat

Original von Mikith
...
iregendeine Weise testen? Ich würde softdevice gern benutzen, um TV über das DVI-Interface auszugeben. Gibt es jemanden, der das softdevice-Plugin zusammen mit einer Gentoo-Installation benutzt?

Hi, ich benutze auch Gentoo und den gensync repository von gentoo.de, und hatte auch immer das gleiche Problem, der ebuild erzeugt bei mir subplugins, die er dann aber nicht nach /usr/lib/vdr kopiert. Meine Lösung war es, den ebuild nicht über "emerge", sondern "ebuild /pfad_zum_gentoo_de_overlay/..ebuild install", dann das gleiche mit "... qmerge" auszuführen, dann bleibt nämlich unter /var/tmp/portage/.... der komplette build liegen, und ich kopiere dann immer mein DFB-subplugin (dabei nicht das Anhängen der VDR-Version and die *.so-Datei vergessen) von Hand nach /usr/lib/vdr.
Das kommentarlose Verabschieden des softdevice Plugins hinterläßt jedoch im Log eine Spur, es beklagt sich auch nach dem manuellen Kopieren des subplugins, es würde die Datei nicht finden. Abhilfe schaft der neue Kommandozeillenparameter des softdevice für die Angabe des Lib-Pfades, genau wie der globale von VDR (und muß leider selbst dann verwendet werden, wenn der globale mit dabei ist), also "vdr -c /etc/vdr -L /usr/lib/vdr -P'softdevice -L /usr/lib/vdr -vo:mgatv' in meinem Fall...

Hope that helps,
Lucian

P.S. Ist nun in neueren ebuilds des softdevice die Sache mit dem manuellen Kopieren der subplugins wirklich und endlich überflüssig?

Hallo Leute,

hoffentlich weiß da jemand Rat, vielleicht ließ auch der softdevice-Autor mit:

Ich habe softdevice-0.0.7pre3 in ein bisschen gändert, und habe nun zum ersten Mal ein Bild am TV-out meiner Matrox G400.
Wie schon einmal in der VDR-ML besprochen, ist die Auswahl und die Konfigurierung der Layer noch nicht ganz auf crtc2 abgestimmt, deswegen erzwinge ich nun probeweise, in video-dfb.c für den videoLayer meinen primary layer zu nehmen (0) , und der ist als "Matrox CRTC2 Layer" in /etc/directfbrc konfiguriert, und für den osdLayer den "Matrox CRTC2 Sub-Picture" (3) der ja normalerweise für sowas auch zuständig sein sollte. Nur bekomme ich in diesem Fall, wenn das Pixelformat von softdevice YUY2 konfiguriert ist, nur ein komplett Weißes Vollbild am TV, also keine Transparenz, kein Video sichtbar. Wenn ich es mit I420 oder YV12 versuche, sehe ich zwar am Anfang ein weißes OSD (nicht mehr Vollbild, sondern nur bis zu den normalen Außmaßen des OSD, aber innen komplett weiß, also nicht erkennbares, und außenrum kein Video, sondern schwarz) und softdevice stürzt samt VDR ab.

Wenn ich aber auch für osdLayer den gleichen Layer, "0" (also den "Matrox CRTC2 Layer") nehme, geht alles, das OSD wird glaube ich software-seitig mit dem Bild gemischt, funktioniert auch nur im YUY2-Format, mit alpha-blending, aber während der Anzeige des OSD wird die CPU stark beansprucht. Die normalere Auswahl wäre die vorherige, dann würde die Grafikkarte das OSD-layer selber mit alpha-blending einblenden, oder sehe ich das falsch?

Da wäre noch ein anderes Problem: da ich das Bild an einem normalen interlaced-Fernseher angucke, brauche ich ja kein deinterlacing (unterstütz am crtc2 die Hardware auch sinvoller weise nicht), aber ich habe trotzdem bei schnelleren Bewegungen im Bild, oder bei Newsticker ein Schmieren, ich denke daß sollte man durch Ändern der FIELD_PARITY, die ja der "Matrox CRTC2 Layer" hardwareseitig untrestützt, beheben, oder?

Ansonsten bin ich ja nun nachdem ich softdevice zum ersten mal am TV sehen kann, wirklich begeistert, kein X mit Xmc, kein xine-plugin welcher immer noch nicht mit DirectFB läuft...

Schönen Gruß,
Lucian