Wie bekomme ich ein lauffähiges System mit dem vdr-xine-plugin mit vdpau?

gerald

Ich habe unter mc in der Suchmaske *libxcb* eingegeben.

Ferner habe ich manuelle die Verzeichnisse /usr/lib und /usr/local/lib durchsucht.

jupp: gui.panel_visible:0 ist hier auch so auskommentiert - sorry!

wolfgang

Wenn ich nur die von Dir angegebenen Werte nehme und dann die Sache starte, ist die config anschließend mit weiteren Werten gefüllt.

Zitat

Original von rkp
gerald

Ich habe unter mc in der Suchmaske *libxcb* eingegeben.

Ferner habe ich manuelle die Verzeichnisse /usr/lib und /usr/local/lib durchsucht.

Ich kenne die Suchmaske von mc nicht, ich kenne mc nicht. So such man:

find /usr/lib -name "libxcb*"

Ich kann mir ehrlich gesagt nicht vorstellen, dass du libxcb nicht auf dem System hast.
Wirf mc weg.

Gerald

Kann schon sein, dass easyvdr eine libX11 ohne libxcb Support mitbringt. Ist doch eine ziemlich alte Distri. Umso besser, weil dann wohl der Multithreading Bug nicht auftritt.

Matthias

Zitat

Original von Rincewind99
Ist doch eine ziemlich alte Distri.

Ich vergesse das immer wieder.

Gerald

Zitat

Original von rkp

Thomas
Danke, versuche ich. Habe immer gedacht, dass ich eine schnelles System habe ...

dass es bei dir länger dauert liegt dann wohl an der Karte oder den Treibern....

damit das xine-panel nicht angezeigt wird, habe ich folgende Einstellungen (sicherheitshalber mal alle ;))

~/.xine$ grep visib config
#gui.auto_panel_visibility:0
#gui.auto_video_output_visibility:0
#gui.tips_visible:1
gui.panel_visible:0

alternativ beim xine-Aufruf *-g* oder *-I* (großes i) mitgeben.

nach libxcb bzw libx11 würde ich mit dpkg suchen lassen, dann hast du auch gleich eine Versionsangabe:

dpkg -l|grep libxcb
dpkg -l|grep  libx11

wobei du libxcb - wie ja schon geschrieben wurde - bei easyvdr (basierend auf etch?) sowieso vergessen kannst......

Gruß, tomas

gerald
mc macht nichts anderes als "find /usr/lib -name "libxcb*"
Manuelle Eingabe hat das gleiche Ergebnis produziert: nichts gefunden

Thomas
Danke, ist jetzt mit meinen Einstellungen identisch

wolfgang
Habe mein Vorgehen jetzt diesbezüglich angepasst

Damit sind alle meine Fragen beantwortet. Danke Euch allen!

rkp

rkp
ich wollte nochmal eben erwähnen das ich die Umschaltzeiten meiner TT-S2 1600 nach neuem Treiber aus Powarmans HG noch erheblich verbessert habe. Habe danach den Background von xine noch auf 'black' geändert und kann da jetzt gut mit leben.

Hallo,

ich habe ein Problem mit dem vdr-plugin-xine/xine-ui und dem vdr. Wenn ich z.b. das VDR Menü aufrufe, also eine OSD-Ausgabe aktiv ist und dann das Fronend z.B. per Tastatur mit Taste "q" beende, dann bekomme ich beim nächsten Start des xine-ui nach einer Pause von 1-2 Minuten keinen Stream mehr angezeigt. Es wird nur das Menü angezeigt. Der VDR lässt sich auch nicht mehr steuern und nach ca. 60 Sekunden beendet der Watchdog des VDR den VDR Prozess.
Kann das jemand nachvollziehen???

Gruss
durchflieger

Zitat

Original von durchflieger
Hallo,

ich habe ein Problem mit dem vdr-plugin-xine/xine-ui und dem vdr. Wenn ich z.b. das VDR Menü aufrufe, also eine OSD-Ausgabe aktiv ist und dann das Fronend z.B. per Tastatur mit Taste "q" beende, dann bekomme ich beim nächsten Start des xine-ui nach einer Pause von 1-2 Minuten keinen Stream mehr angezeigt. Es wird nur das Menü angezeigt. Der VDR lässt sich auch nicht mehr steuern und nach ca. 60 Sekunden beendet der Watchdog des VDR den VDR Prozess.
Kann das jemand nachvollziehen???

Gruss
durchflieger

Hallo,

das von dir beschriebene Verhalten kann ich hier nicht reproduzieren.

Es kommt öfters vor, dass ich xine-ui beende, den VDR weiterlaufen lasse und zu einem späteren Zeitpunkt xine-ui wieder starte. Da läuft alles ganz normal weiter, ob jetzt das OSD aktiv war/ist oder nicht.
Habs sicherheitshalber gerade mehrmals mit aktivem OSD getestet!

Beim Desktoprechner läuft ständig X, beim Wohnzimmer-VDR wird xine-ui über xinit gestartet, funktioniert jeweils anstandslos.

vdr-xine: Client disconnected!
vdr-xine: Client connecting ...
vdr-xine: Client connected!

....und weiter gehts

du findest da keine Anhaltspunkte im log vom VDR oder xine?

Gruß, tomas

Zitat

sorry, aber da kann ich dir nicht weiterhelfen, denn mein System insbesondere Kernel und notwendiges Zeugs ist zu weit vom Debian-Standard weg.

so, nach mehrstündigem make menuconfig / bauen / testen hab ich jetzt auch mein eigenes kernel
wers will (2.6.31.6 für karmic als *.deb dateien) pm zu mir !

Zitat

Mach doch bitte für deine Fragen hier einen eigenen Thread auf.

äh, war doch eine frage zu deinem ersten post
zu einem lauffähigen vdr-rechner gehört doch auch das os, oder ?
aber ich habs ja jetzt selfmade und werde deinen (sehr brauchbaren) thread in ruhe lassen

schon klar, da steht auch "vdr 1.7.9"
wie gesagt, schon erledigt

Zitat

Original von tomas
...
das von dir beschriebene Verhalten kann ich hier nicht reproduzieren.

Es kommt öfters vor, dass ich xine-ui beende, den VDR weiterlaufen lasse und zu einem späteren Zeitpunkt xine-ui wieder starte. Da läuft alles ganz normal weiter, ob jetzt das OSD aktiv war/ist oder nicht.
Habs sicherheitshalber gerade mehrmals mit aktivem OSD getestet!

Beim Desktoprechner läuft ständig X, beim Wohnzimmer-VDR wird xine-ui über xinit gestartet, funktioniert jeweils anstandslos.

Code

vdr-xine: Client disconnected!
vdr-xine: Client connecting ...
vdr-xine: Client connected!

....und weiter gehts

du findest da keine Anhaltspunkte im log vom VDR oder xine?

Gruß, tomas

Alles anzeigen

Deine Log-Ausgabe sehe ich weder im vdr noch im xine Log.
Im vdr-Log gibt es ausser der Watchdog-Panic Meldung keinen besonderen Hinweis.
Im xine-Log wird eine Fehlermeldung ausgeben:

vdr: osdflush: n: 8, 40,8, timeout: 0, result: 0
input_vdr: execution of rpc command 25 () failed, exiting ...
input_vdr: rpc thread done.
PlaybackFinished

Wenn du den xine dass zweite mal startest siehst du dann noch das geöffnete OSD Menü des vdr, das beim beenden des ersten xine aktiv war? Das ist bei mir so.

Gruss
durchflieger

Zitat

Original von durchflieger

Deine Log-Ausgabe sehe ich weder im vdr noch im xine Log.

Die Log-Ausgabe bekomme ich am Desktop: Da starte ich den VDR bei Bedarf händisch über ein Startskript, wobei der VDR über ein separates xterm gestartet wird

xterm -e ./vdr .......

in diesem xterm kann ich dann direkt die Log-Ausgaben des VDR verfolgen.

MakePrimaryDevice: 1
=========================
SetVideoFormat: 1
SetVolumeDevice: 220
frame: (0, 0)-(-1, -1), zoom: (1.00, 1.00)
SetVolumeDevice: 220
frame: (0, 0)-(-1, -1), zoom: (1.00, 1.00)
vdr-xine: Client connecting ...
vdr-xine: Client connected!
frame: (0, 0)-(720, 576), zoom: (1.00, 1.00)
read(4) returned 0, error 0: Erfolg
vdr-xine: Client disconnected!

Zitat

Original von durchflieger
Im vdr-Log gibt es ausser der Watchdog-Panic Meldung keinen besonderen Hinweis.
Im xine-Log wird eine Fehlermeldung ausgeben:

Code

vdr: osdflush: n: 8, 40,8, timeout: 0, result: 0
input_vdr: execution of rpc command 25 () failed, exiting ...
input_vdr: rpc thread done.
PlaybackFinished

hier sieht das so aus:

Ende xine-log nach quit:

vdr: osdflush: n: 4, 20,3, timeout: 0, result: 0
vdr: osdflush: n: 1, 5,1, timeout: 0, result: 0
vdr: osdflush: n: 2, 10,1, timeout: 0, result: 0
ao_flush (loop running: 1)
input_cache: read calls: 0, main input read calls: 0
input_cache: seek_calls: 0, main input seek calls: 0
input_vdr: shutting down rpc thread (timeout: 10000 ms) ...
input_vdr: rpc thread done.
input_vdr: joining rpc thread ...
input_vdr: rpc thread joined.
input_vdr: joining metronom thread ...
input_vdr: metronom thread joined.
xine_dispose
shutdown audio
shutdown video
xine_exit: bye!

nach xine-ui-Neustart:

............
ao_flush (loop running: 1)
audio discontinuity #5, type is 0, disc_off 0
waiting for in_discontinuity update #5
video discontinuity #5, type is 0, disc_off 0
vpts adjusted with prebuffer to 114514
vdr: osdflush: n: 1, 13,0, timeout: 0, result: 0
vdr: osdflush: n: 3, 15,2, timeout: 0, result: 0
vdr: osdflush: n: 3, 15,2, timeout: 0, result: 0
vdr: osdflush: n: 5, 25,4, timeout: 0, result: 0

Zitat

Original von durchflieger
Wenn du den xine dass zweite mal startest siehst du dann noch das geöffnete OSD Menü des vdr, das beim beenden des ersten xine aktiv war? Das ist bei mir so.

Siehe zweiter Log-Auszug, das OSD ist noch aktiv und bedienbar und der VDR gibt ein Bild aus.

Dieses *input_vdr: execution of rpc command 25 () failed, exiting ...* aus deinem Log kommt mir aber, wenn ich mich nicht täusche, irgendwie bekannt vor, kann sein dass ich das bei früheren Problemen mit dem *VT-Switching* auch schon hatte. Ich suche später mal den thread raus....

Gruß, tomas

Der Teufel steckt mal wieder im Detail:

Wenn ich diesen Patch anwende:

diff -NaurwB xine/xine.c xine_autostart/xine.c
--- xine/xine.c 2009-06-14 14:39:15.000000000 +0200
+++ xine_autostart/xine.c 2009-11-01 22:58:20.000000000 +0100
@@ -229,6 +229,10 @@
if (!PluginXine::cXineDevice::Open())
return false;

+ pid_t cpid;
+ switch (cpid = fork()){
+ case 0: SystemExec("xine -f -V vdpau -A alsa --post vdr --post vdr_video --post vdr_audio --post autocrop:enable_autodetect=0,enable_subs_detect=1,soft_start=1,stabilize=1 --aspect-ratio=anamorphic --verbose=2 --no-logo --no-splash vdr:/tmp/vdr-xine/stream#demux:mpeg_pes");
+ }

return true;
}

bekomme ich schon beim -make clean- immer ein

xine.c:342: error: expected unqualified-id before 'switch'
make: *** [xine.o] Fehler 1

Ich sehe den Fehler einfach nicht!

Zitat

Original von rkp

bekomme ich schon beim -make clean- immer ein

xine.c:342: error: expected unqualified-id before 'switch'
make: *** [xine.o] Fehler 1

Ich sehe den Fehler einfach nicht!

Alles anzeigen

Moin,

sieht so aus, als hättest du das am Ende der xine.c eingefügt.

Die vier Zeilen, die mit einem *+* beginnen müssen (ohne *+*) nach Zeile 230 eingefügt werden.

Hab den Patch jetzt mal als Datei angehängt.

durchflieger: hatte bei mir doch nichts mit dem *VT-Switching* zu tun. Weiß jetzt auch nicht mehr, in welchem Zusammenhang ich dieses *input_vdr: execution of rpc command 25 () failed, exiting ...* hatte....

Gruß, tomas