#13 Statusermittlung projectX

[Kai Engels]

Laut ud_daemon Konsole
und usgui wurde alles korrekt verarbeitet, allerdings
fand ich trotz
gegenteiliger Meldung im usgui kein TS-File im
entsprechenden Ordner.
Den Grund fand ich dann im Log-File:
------------------------------------
Creating
/dvr/udrec_suite/movies/ts/KiKa_Mama_ist_unmöglich_151202_040929.ts:
/usr/bin/ud_mpg2ts.pl -o=/dvr/udrec_suite/movies/ts
-i=/dvr/udrec_suite/movies/mpg/KiKa_Mama_ist_unmöglich_151202_040929.tc_mpg
--java=/usr/lib/java/bin/java --jar=/usr/lib/jar/pX.jar
--ini=/usr/lib/jar/pX_ts.ini
found Xvfb running on display :1
Exception in thread "main" java.lang.InternalError:
Can't connect to X11 window server using 'localhost:1'
as the value of the DISPLAY variable.
------------------------------------
Angeblich findet er einen Xvfb, aber project X kann
sich nicht damit
verbinden. Die Wahrheit ist: Es ist gar kein Xvfb aktiv
gewesen. Hier
scheint mir die Statusermittlung, ob ein Xvfb läuft
oder nicht, nicht
richtig zu arbeiten.

[Kai Engels]

Logged In: YES
user_id=925471

Kommentar von Patrick:
----------------------------------

das sind die entscheidenden Zeilen, mit der ich das Display
meines Xvfb
herausfinde. Ich hatte das, glaub ich, auch mit anderen
Display-Variablen
getestet.

my $xvfb_display = `ps -ef | egrep ".*vfb :" | head -1`;
chomp $xvfb_display;
$xvfb_display =~ s/.*://g;
die "Xvfb not running"
unless $xvfb_display =~ /^\d$/;
print "Found Xvfb running on display :$xvfb_display\n";

Gestartet wird Xvfb im Startskript und zwar auf dem naechsten
freien Display. Das war mal eine Anregung von Wolfgang, damit
es keine Probleme mit bereits belegten Displays gibt.

Vielleicht koennte ihr das manuell debuggen und schauen, wo
es bei euch klemmt ?

XLOCK=`basename `ls /tmp/.X?-lock | sort | tail -1 \``
DISP=`echo $XLOCK | sed -e 's/^\.X\([0-9]\)-lock/\1/g'`
[ -z "$DISP" ] && DISP=0
NEXT_DISP=`echo "$DISP+1" | bc`
echo -n "Starting Xvfb on display $NEXT_DISP: "

Die Pruefung, ob pX das File korrekt in ein TS-file
konvertiert hat findet
in ud_suite.pl statt. In usgui muesste man das eigentlich
abfangen koennen.

# erst mit tcmplex muxen:
print "Creating $ts_mpg: $ud_mux -o=$ts_mpg -v=$vid_es_file
-a=\"$aud_es_files\" -tcmplex\n";
$rc = system ("$ud_mux -o=$ts_mpg -v=$vid_es_file
-a=\"$aud_es_files\" -tcmplex");
die "tcmplex failed: $!" unless $rc == 0;

# pX -> TS
print "Creating $ts_file: $ud_mpg2ts -o=$ts_dir -i=$ts_mpg
--java=$java --jar=$px --ini=$ini_ts\n";
$rc = system ("$ud_mpg2ts -o=$ts_dir -i=$ts_mpg --java=$java
--jar=$px --ini=$ini_ts");
die "Failed to convert $ts_mpg: $!" unless $rc == 0;

Gruss,
Patrick

[Kai Engels]

Logged In: YES
user_id=925471

Das Problem scheint mir, das pX nicht unbedingt einen $rc /=
0 setzt,
wenn es z.B. in den TS-Streams aus dem NFS-Streaming keine
Video-Spur
erkennen konnte. Das Demuxen wird als erfolgreich angesehen,
auch wenn
das Ergebnis nicht wirklich weiterhilft.
Ich denke, wir sollten hier sicherheitshalber prfen, ob die
erwarteten
Dateien auch tatschlich erzeugt wurden und nur
weitermachen, wenn aus
dem pX-Aufruf mindestens eine .mpv und eine .mp2-Datei
rausgekommen
sind. Vielleicht knnte man auch die Anzahl der Tonspuren
anhand der
xml-Datei ermitteln und diese Angaben mit den von pX
erzeugten Tracks
vergleichen.