udrec_suite 0.4.1 erstellt keine Filmdateien.

Hallo ,

habe udrec_suite 0.4.1 erfolgreich auf ein SuSE 9.1 System installiert und mit udconfig konfiguriert.
Mit dem Befehl udrec_suite start wird mir angezeigt , dass der Server anscheinend erfolgreich gestartet wird. Als Ziel-Verzeichnis habe ich test kreiert. Zu Testzwecken bin ich als root unterwegs.

Bei Aufnahmestart werden in /test/tmp drei Dateien erstellt.
.*xml ; .*epg und fmt. Die eigentlichen Filmdateien existieren nicht.

Ach ja , als DBox verwende ich die Dreambox 7000 S mit dem aktuellen DBF 2.0 Reloaded Image.

Hoffe Ihr könnt mir helfen.

/enthobrite

Beitrag von **t.b.** » Mittwoch 24. November 2004, 12:09

Hallo,

was sagt denn ein rcudrec_suite status

Hmm, bei einer dreambox kenne ich michn nicht aus. Zeigen die dasselbe Verhalten wie dboxen?

Hast du mit udrec gestreamt oder direkt per NFS?
Was sagen die logdateien /var/log/ud_suite.log bzw. /var/log/ud_daemon.log?

Gruss
Kai

Hallo ,

danke für Eure rasche Meldung. Folgende Meldungen werden abgesetzt.

office:~ # udrec_suite status
Checking for service udrec_suite running
Checking ud_daemon.pl running
Checking Xvfb running

Habe nicht per nfs gestreamt.

office:~ # tail -f /var/log/ud_suite.log
channelname : EinsFestival
epgtitle : Vier Frauen in der Nacht - Spielfilm Italien / Frankreich 1954
command : unknown
onidsid : 123456
epgid : 123456
languages :
lang_short :
epgtext : Keine EPG-Informationen verfuegbar.
aspect-ratio: 4:3
Invalid mode, bailing out ... at /usr/local/bin/ud_suite.pl line 341.

office:~ # tail -f /var/log/ud_daemon.log
Writing Aspect-Ratio: 041124_171658.fmt
Writing Network-Stats: 041124_171658.stat
Calling "ud_suite.pl -i /test/tmp/041124_171658.xml"
Option es requires an argument
#########################
# ud_deamon.pl finished #
#########################

Starting "/usr/bin/mono /usr/local/bin/udrec.exe -es -sso -xmlf -vsplit -mplex -o /test/tmp/"
17:17:02 listening to any host on port 4000

Bedanke mich schon einmal im voraus für Eure Bemühungen.

MfG.
/enthobrite

enthobrite hat geschrieben:
Starting "/usr/bin/mono /usr/local/bin/udrec.exe -es -sso -xmlf -vsplit -mplex -o /test/tmp/"

Nicht wirklich neues von mir : Den Fehler kenne ich schon: "bailing out" blabla....
Der tritt auf wenn die Filmdateien nicht geschrieben wurden, hmmm

Beende mal die udrec_suite, starte udrec mal von Hand auf der Console und schau dir den output an (Befehl so wie oben ausgegeben). Werden dann Dateien geschrieben? Wenn ja würds mich wundern.

Hi ,

wenn ich mit udrec_suite start starte wird das Programm ordnungsgemaess gestartet. Filmdateien werden jedoch nicht geschrieben.

Vielleicht ein Problem mit SuSE 9.1 ???

/enthobrite

enthobrite hat geschrieben:Hi ,

wenn ich mit udrec_suite start starte

/enthobrite

Missverstandniss: Du sollst das mono Programm udrec.exe von hand starten (als der user, der in udconfig eingetragen ist) und gucken was passiert:

Code: Alles auswählen

/usr/bin/mono /usr/local/bin/udrec.exe -es -sso -xmlf -vsplit -mplex -o /test/tmp/

Werden bei einer Aufnahme dann Filmdateien geschrieben?

Es gibt zwar ein paar Probleme mit suse usern, aber eher deshalb, weil es schwer ist alle benötigten Pakete zusammen zu kriegen

EDIT: Auch dir empfehle ich unsere testing mailing Liste, da warten Leidensgenossen

, http://sourceforge.net/mail/?group_id=96640

Gruss
Kai

Hallo ,

office:/ # /usr/bin/mono /usr/local/bin/udrec.exe -es -sso -xmlf -vsplit -mplex -o /test/tmp/

Unhandled Exception: System.Net.Sockets.SocketException: Address already in use
in (unmanaged) (wrapper managed-to-native) System.Net.Sockets.Socket:Bind_internal (intptr,System.Net.SocketAddress)
in <0x00004> (wrapper managed-to-native) System.Net.Sockets.Socket:Bind_internal (intptr,System.Net.SocketAddress)
in <0x000a4> System.Net.Sockets.Socket:Bind (System.Net.EndPoint)
in <0x000d1> .DBoxRecordControl:Start ()
in <0x01a86> .udrec:Main (string[])

Denke mal , da stimmt was nicht .

/enthobrite

Kann es sein dass bei dir was auf port 4000 horcht? Hattest du noch einen anderen udrec am laufen? Was sagt

Code: Alles auswählen

netstat --listening

?

Hallo ,

habe es anders versucht mit:

office:~ # lsof -i
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
portmap 3737 bin 3u IPv4 4758 UDP *:sunrpc
portmap 3737 bin 4u IPv4 4759 TCP *:sunrpc (LISTEN)
sshd 4772 root 3u IPv6 5904 TCP *:ssh (LISTEN)
cupsd 5030 lp 0u IPv4 6732 TCP *:ipp (LISTEN)
cupsd 5030 lp 2u IPv4 6733 UDP *:ipp
master 5257 root 12u IPv4 6943 TCP localhost:smtp (LISTEN)
master 5257 root 13u IPv6 6944 TCP localhost:smtp (LISTEN)
master 5257 root 70u IPv4 7021 TCP localhost:10025 (LISTEN)
master 5257 root 71u IPv6 7022 TCP localhost:10025 (LISTEN)
mono 5789 root 9u IPv4 20348 TCP *:terabase (LISTEN)
Xvfb 5807 root 0u IPv6 20368 TCP *:6002 (LISTEN)
Xvfb 5807 root 1u IPv4 20369 TCP *:6002 (LISTEN)
office:~ # netstat -p | grep 5789
unix 3 [ ] STREAM VERBUNDEN 20329 5789/mono

Evtl ein Problem mit der Firewall ??? Habe allerdings schon mit und ohne FW. ausprobiert.
Aufgrund der Zugriffszahlen scheine ich nicht der Einzigste mit diesem Problem zu sein.

/magnum

Hmmm, Interessant ist denke ich der port 4000, nicht 5789. 4000 ist der wo udrec auf die dbox horcht.

Den Befehl lsofs kenne ich zugegebenermassen nicht, die manpage hat mich da auch nicht weitergebracht.

Ich habe einfach mal versucht, zwei udrecprozesse zu starten und bumms, der zweite beendete sich mit exakt derselben Fehlermeldung wie bei dir. Wahrscheinlich hast du noch eine udrec Leiche am laufen. Checke den Port 4000 !

Ach ja: Ein "lsofs -i" liefert bei mir nur die Prozesse, die auch von mir gestartet wurden, das deckt nicht alles ab!

Gruss
Kai

EDIT: Juppiiiiiieee, heute werde ich 200

)))

EDIT: An ein Problem mit einer Firewall glaube ich nicht. EIne FIrewall belegt ja nicht die Ports so dass andere Prozesse nicht mehr drankönnen. Oder gibts solche?

Hallo ,

habe noch folgenden Befehl abgesetzt:

office:/myData # netstat -tupan
Aktive Internetverbindungen (Server und stehende Verbindungen)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:4000 0.0.0.0:* LISTEN 11978/mono
tcp 0 0 127.0.0.1:10025 0.0.0.0:* LISTEN 3752/master
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 2041/portmap
tcp 0 0 0.0.0.0:6002 0.0.0.0:* LISTEN 11869/Xvfb
tcp 0 0 0.0.0.0:631 0.0.0.0:* LISTEN 3516/cupsd
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 3752/master
tcp 0 0 192.168.1.3:4000 192.168.1.5:1032 TIME_WAIT -
tcp 0 0 192.168.1.3:4000 192.168.1.5:1031 TIME_WAIT -
tcp 0 0 ::1:10025 :::* LISTEN 3752/master
tcp 0 0 :::6002 :::* LISTEN 11869/Xvfb
tcp 0 0 :::22 :::* LISTEN 3254/sshd
tcp 0 0 ::1:25 :::* LISTEN 3752/master
udp 0 0 0.0.0.0:111 0.0.0.0:* 2041/portmap
udp 0 0 0.0.0.0:631 0.0.0.0:* 3516/cupsd

/enthobrite

enthobrite hat geschrieben:Hallo ,

habe noch folgenden Befehl abgesetzt:

office:/myData # netstat -tupan
Aktive Internetverbindungen (Server und stehende Verbindungen)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:4000 0.0.0.0:* LISTEN 11978/mono
tcp 0 0 192.168.1.3:4000 192.168.1.5:1032 TIME_WAIT -
tcp 0 0 192.168.1.3:4000 192.168.1.5:1031 TIME_WAIT -

Ohne dass du udrec gestartet hast? Warum läuft da ein mono? Hmm, ausserdem sind da einige Sockets im TIME_WAIT Status, d.h. ein Prozess hat sich oder wurde beendet (wahrscheinlich udrec), aber der socket ist noch nicht richtig freigegeben.
Ich weiss nicht wie man das in Griff kriegt (warten?), zur Not hilft ein reboot. Danach solltest du diesen Befehl nochmal absetzen und schauen ob der port 4000 immer noch besetzt ist. Wenn ja startest du irgendwas zur bootzeit. Das müsstest du eingrenzen. Startest du vielleicht die udrec_suite zur bootzeit?
Wenn der port 4000 nicht mehr auftaucht kannst du nochmal versuchen udrec von Hand zu starten. Das sollte dann eigentlich gehen. Probier das mal aus (auchd as aufnehmen)

Wenn das alles geklappt hat, beende udrec und schaue wieder ob der port 4000 noch irgendwo besetzt ist. Wenn starte die udrec_suite und versuche wieder aufzunehmen. Viellleicht war das ja nur ein temporaeres Problem.

Kann es sein dass du vielleicht auch ein aelteres mono einsetzt? Vielle4icht gibt es da ja Probleme mit der Socketfreigabe? Allerdings stochere ich jetzt im Nebel.

Gruss
Kai

Gruss
Kai